microsandbox

Version	Released
`0.7.11` patch	Oct 24, 2026
`0.7.10` patch	Oct 23, 2026
`0.7.9` patch	Oct 22, 2026
`0.7.8` patch	Oct 09, 2026
`0.7.7` patch	Oct 05, 2026
`0.7.6` patch	Oct 01, 2026
`0.7.5` patch	Sep 30, 2026
`0.7.4` patch	Sep 29, 2026
`0.7.3` patch	Sep 24, 2026
`0.7.2` patch	Sep 17, 2026
`0.7.1` patch	Sep 17, 2026
`0.7.0` minor	Sep 16, 2026
`0.6.18` patch	Sep 09, 2026
`0.6.17` patch	Sep 04, 2026
`0.6.16` patch	Aug 29, 2026
`0.6.15` patch	Aug 24, 2026
`0.6.14` patch	Aug 22, 2026
`0.6.13` patch	Aug 21, 2026
`0.6.12` patch	Aug 19, 2026
`0.6.11` patch	Aug 19, 2026
`0.6.10` patch	Aug 18, 2026
`0.6.9` patch	Aug 15, 2026
`0.6.8` unknown	Jul 29, 2026
`0.6.7` unknown	Jul 25, 2026
`0.6.6` unknown	Jul 07, 2026
`0.6.5` unknown yanked	Jul 07, 2026
`0.6.4` unknown	Jul 05, 2026
`0.6.3` unknown	Jul 04, 2026
`0.6.2` unknown	Jul 01, 2026
`0.6.1` unknown	Jun 28, 2026
`0.6.0` unknown	Jun 27, 2026
`0.5.10` unknown	Jun 24, 2026
`0.5.8` unknown 1 CVE	Jun 22, 2026
`0.5.7` unknown 1 CVE	Jun 14, 2026
`0.5.6` unknown 1 CVE	Jun 10, 2026
`0.5.5` unknown 1 CVE	Jun 05, 2026
`0.5.4` unknown 1 CVE	Jun 01, 2026
`0.5.3` unknown 1 CVE	May 30, 2026
`0.5.2` unknown 1 CVE	May 28, 2026
`0.5.1` unknown 1 CVE	May 27, 2026
`0.5.0` unknown yanked 1 CVE	May 27, 2026
`0.4.6` unknown 1 CVE	May 13, 2026
`0.4.5` unknown 1 CVE	May 07, 2026
`0.4.4` unknown 1 CVE	May 03, 2026
`0.4.2` unknown 1 CVE	Apr 29, 2026
`0.4.1` unknown 1 CVE	Apr 29, 2026
`0.4.0` unknown 1 CVE	Apr 28, 2026
`0.3.14` unknown 1 CVE	Apr 18, 2026
`0.3.13` unknown 1 CVE	Apr 15, 2026
`0.3.12` unknown 1 CVE	Apr 05, 2026

0.7.11 patch

Oct 24, 2026

0.7.10 patch

Oct 23, 2026

0.7.9 patch

Oct 22, 2026

0.7.8 patch

Oct 09, 2026

0.7.7 patch

Oct 05, 2026

0.7.6 patch

Oct 01, 2026

0.7.5 patch

Sep 30, 2026

0.7.4 patch

Sep 29, 2026

0.7.3 patch

Sep 24, 2026

0.7.2 patch

Sep 17, 2026

0.7.1 patch

Sep 17, 2026

0.7.0 minor

Sep 16, 2026

0.6.18 patch

Sep 09, 2026

0.6.17 patch

Sep 04, 2026

0.6.16 patch

Aug 29, 2026

0.6.15 patch

Aug 24, 2026

0.6.14 patch

Aug 22, 2026

0.6.13 patch

Aug 21, 2026

0.6.12 patch

Aug 19, 2026

0.6.11 patch

Aug 19, 2026

0.6.10 patch

Aug 18, 2026

0.6.9 patch

Aug 15, 2026

0.6.8 unknown

Jul 29, 2026

0.6.7 unknown

Jul 25, 2026

0.6.6 unknown

Jul 07, 2026

0.6.5 unknown yanked

Jul 07, 2026

0.6.4 unknown

Jul 05, 2026

0.6.3 unknown

Jul 04, 2026

0.6.2 unknown

Jul 01, 2026

0.6.1 unknown

Jun 28, 2026

0.6.0 unknown

Jun 27, 2026

0.5.10 unknown

Jun 24, 2026

0.5.8 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Jun 22, 2026

0.5.7 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Jun 14, 2026

0.5.6 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Jun 10, 2026

0.5.5 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Jun 05, 2026

0.5.4 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Jun 01, 2026

0.5.3 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 30, 2026

0.5.2 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 28, 2026

0.5.1 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 27, 2026

0.5.0 unknown yanked

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 27, 2026

0.4.6 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 13, 2026

0.4.5 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 07, 2026

0.4.4 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

May 03, 2026

0.4.2 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 29, 2026

0.4.1 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 29, 2026

0.4.0 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 28, 2026

0.3.14 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 18, 2026

0.3.13 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 15, 2026

0.3.12 unknown

1 CVE

CVE-2026-61670 GHSA-m8f5-rh7h-vgg3 Sep 22, 2026

microsandbox: Secret values exposed in world-readable process arguments

6.5 / 10

Medium

Local Low Low None Changed High None None

Summary

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 --env carrying 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=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.

Fixed in


          0.5.10

References

Updated Sep 22, 2026 · Source: OSV.dev

Apr 05, 2026

Activity

Reach

Details