GHSA-M8F5-RH7H-VGG3
Vulnerability from github – Published: 2026-09-22 19:43 – Updated: 2026-09-22 19:43Summary
When the SDK spawns a sandbox, the msb sandbox child process receives the full network configuration as an inline --network-config <json> command-line argument, and any per-sandbox environment as repeated --env KEY=VALUE arguments. On Linux a process's arguments are world-readable via /proc/<pid>/cmdline, and on both Linux and macOS they are visible to other local processes via ps. Because the network configuration carries the real secret values used for host-side secret substitution, any unprivileged local user (or any process running as a different user on the same host) can read those secrets directly out of the process listing for as long as the sandbox is running. This defeats the "secrets that can't leak" guarantee for the host side of the boundary.
Details
The SDK serializes the entire NetworkConfig, including the real (non-placeholder) secret values, and pushes it onto the child argv, in sdk/rust/lib/runtime/spawn.rs near line 1241:
let net_json = serde_json::to_string(&config.network)
.expect("failed to serialize network config");
args.push(OsString::from("--network-config"));
args.push(OsString::from(net_json)); // secrets land in argv here
The CLI accepts it only as an inline string and parses it with serde_json::from_str, so there is no off-argv channel today. The field is declared at crates/cli/lib/sandbox_cmd.rs line 152 and parsed near line 234:
/// Network configuration as JSON.
pub network_config: Option<String>,
// parsed near line 234
.map(|json| serde_json::from_str::<NetworkConfig>(json).expect(...))
The same exposure applies to environment values, which are passed one per argument (spawn.rs ~lines 1249-1251):
for (key, value) in &config.env {
args.push(OsString::from("--env"));
args.push(OsString::from(format!("{key}={value}")));
}
Any secret a user places in env or in the network config (e.g. upstream API keys used for the host-side proxy substitution) is therefore present in the process command line.
The fix and reusable in-repo patterns are tracked, from a readability angle, in issue #997: passing bulky config over an inherited file descriptor (--network-config-fd <n>) the way --parent-watch-fd already does (spawn.rs lines 207-233, vm::PARENT_WATCH_FD) removes the values from argv entirely. An env-var alternative does not fully fix this as /proc/<pid>/environ is still readable by the same uid and root and is inherited by children, so an fd or reference handoff is the appropriate channel for secret material.
PoC
- Launch any sandbox that includes a secret, e.g. a network config with an upstream credential to be substituted, or an
--envcarrying a token. - From a separate, unprivileged shell on the same host (no root, different local user is sufficient):
- The output contains the full
--network-config {...}JSON with the real secret values, and any--env KEY=VALUEsecrets, in cleartext.
No special privileges, no debugger, and no access to the spawning user's session are required. The window of exposure is the entire lifetime of the sandbox process.
Impact
Local information disclosure of secrets (CWE-214: invocation of process using visible sensitive information / CWE-200). Any local user or co-resident process on the host running a microsandbox can read credentials that were meant to stay host-side and never reach untrusted code. This is most serious on shared or multi-tenant hosts, CI runners, and developer machines running other untrusted tooling, where the threat model explicitly assumes the secret never leaves the trusted host boundary. The vulnerability does not require code execution inside the sandbox; it is exploitable purely from the host's process table.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "microsandbox"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61670"
],
"database_specific": {
"cwe_ids": [
"CWE-214"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T19:43:04Z",
"nvd_published_at": "2026-09-18T21:17:01Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen the SDK spawns a sandbox, the `msb sandbox` child process receives the full network configuration as an inline `--network-config \u003cjson\u003e` command-line argument, and any per-sandbox environment as repeated `--env KEY=VALUE` arguments. On Linux a process\u0027s arguments are world-readable via `/proc/\u003cpid\u003e/cmdline`, and on both Linux and macOS they are visible to other local processes via `ps`. Because the network configuration carries the real secret values used for host-side secret substitution, any unprivileged local user (or any process running as a different user on the same host) can read those secrets directly out of the process listing for as long as the sandbox is running. This defeats the \"secrets that can\u0027t leak\" guarantee for the host side of the boundary.\n\n## Details\n\nThe SDK serializes the entire `NetworkConfig`, including the real (non-placeholder) secret values, and pushes it onto the child argv, in `sdk/rust/lib/runtime/spawn.rs` near line 1241:\n\n```rust\nlet net_json = serde_json::to_string(\u0026config.network)\n .expect(\"failed to serialize network config\");\nargs.push(OsString::from(\"--network-config\"));\nargs.push(OsString::from(net_json)); // secrets land in argv here\n```\n\nThe CLI accepts it only as an inline string and parses it with `serde_json::from_str`, so there is no off-argv channel today. The field is declared at `crates/cli/lib/sandbox_cmd.rs` line 152 and parsed near line 234:\n\n```rust\n/// Network configuration as JSON.\npub network_config: Option\u003cString\u003e,\n\n// parsed near line 234\n.map(|json| serde_json::from_str::\u003cNetworkConfig\u003e(json).expect(...))\n```\n\nThe same exposure applies to environment values, which are passed one per argument (`spawn.rs` ~lines 1249-1251):\n\n```rust\nfor (key, value) in \u0026config.env {\n args.push(OsString::from(\"--env\"));\n args.push(OsString::from(format!(\"{key}={value}\")));\n}\n```\n\nAny secret a user places in `env` or in the network config (e.g. upstream API keys used for the host-side proxy substitution) is therefore present in the process command line.\n\nThe fix and reusable in-repo patterns are tracked, from a readability angle, in issue #997: passing bulky config over an inherited file descriptor (`--network-config-fd \u003cn\u003e`) the way `--parent-watch-fd` already does (`spawn.rs` lines 207-233, `vm::PARENT_WATCH_FD`) removes the values from argv entirely. An env-var alternative does not fully fix this as `/proc/\u003cpid\u003e/environ` is still readable by the same uid and root and is inherited by children, so an fd or reference handoff is the appropriate channel for secret material.\n\n## PoC\n\n1. Launch any sandbox that includes a secret, e.g. a network config with an upstream credential to be substituted, or an `--env` carrying a token.\n2. From a separate, unprivileged shell on the same host (no root, different local user is sufficient):\n3. The output contains the full `--network-config {...}` JSON with the real secret values, and any `--env KEY=VALUE` secrets, in cleartext.\n\nNo special privileges, no debugger, and no access to the spawning user\u0027s session are required. The window of exposure is the entire lifetime of the sandbox process.\n\n## Impact\n\nLocal information disclosure of secrets (CWE-214: invocation of process using visible sensitive information / CWE-200). Any local user or co-resident process on the host running a microsandbox can read credentials that were meant to stay host-side and never reach untrusted code. This is most serious on shared or multi-tenant hosts, CI runners, and developer machines running other untrusted tooling, where the threat model explicitly assumes the secret never leaves the trusted host boundary. The vulnerability does not require code execution inside the sandbox; it is exploitable purely from the host\u0027s process table.",
"id": "GHSA-m8f5-rh7h-vgg3",
"modified": "2026-09-22T19:43:04Z",
"published": "2026-09-22T19:43:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/security/advisories/GHSA-m8f5-rh7h-vgg3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61670"
},
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/issues/997"
},
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/pull/1006"
},
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/commit/2ac6a177b11212d392bf1e7dc77aaf14e4768aa8"
},
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/commit/fbfb2366bfafad5e6df8778183f95fd8ca3c00a4"
},
{
"type": "PACKAGE",
"url": "https://github.com/superradcompany/microsandbox"
},
{
"type": "WEB",
"url": "https://github.com/superradcompany/microsandbox/releases/tag/v0.5.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "microsandbox: Secret values exposed in world-readable process arguments"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.