CVE-2026-61670

CVE-2026-61670 is a medium-severity security vulnerability in microsandbox (rust), affecting versions < 0.5.10. It is fixed in 0.5.10.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

microsandbox: Secret values exposed in world-readable process arguments

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

  1. 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.
  2. From a separate, unprivileged shell on the same host (no root, different local user is sufficient):
  3. The output contains the full --network-config {...} JSON with the real secret values, and any --env KEY=VALUE secrets, 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.

CVE-2026-61670 has a CVSS score of 6.5 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.5.10); upgrading removes the vulnerable code path.

Affected versions

microsandbox (< 0.5.10)

Security releases

microsandbox → 0.5.10 (rust)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade microsandbox to 0.5.10 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-61670? CVE-2026-61670 is a medium-severity security vulnerability in microsandbox (rust), affecting versions < 0.5.10. It is fixed in 0.5.10.
  2. How severe is CVE-2026-61670? CVE-2026-61670 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of microsandbox are affected by CVE-2026-61670? microsandbox (rust) versions < 0.5.10 is affected.
  4. Is there a fix for CVE-2026-61670? Yes. CVE-2026-61670 is fixed in 0.5.10. Upgrade to this version or later.
  5. Is CVE-2026-61670 exploitable, and should I be worried? Whether CVE-2026-61670 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-61670 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-61670? Upgrade microsandbox to 0.5.10 or later.

Stop the waste.
Protect your environment with Kodem.