Analysis · DiggingBeagle record

A sandbox can hide the files and still hand an AI agent the keys

Two October 2026 disclosures expose different inherited powers: mini-swe-agent passed parent environment variables to its experimental Bubblewrap shell, while Zotero MCP could fetch agent-selected internal URLs. The demonstrated and hypothetical consequences are not equivalent.

Published
Oct 11, 2026
By
DiggingBeagle

Overview

A restricted shell can still receive credentials from the process that launched it. In mini-swe-agent v2.4.6, that was visible in the experimental Bubblewrap backend; in a separate Zotero MCP disclosure, the question was which internal hosts a bibliographic tool could contact. Neither finding establishes a widespread breach, and the two failures should not be collapsed into a generic "sandbox escape."

An agent does not have to escape its container to exercise authority already handed to one of its tools. The authority can arrive as an inherited environment variable or as a network request executed by a trusted MCP server. The two October 10 CVEs expose different implementation errors and require different prerequisites, which is exactly why a single "runs in a sandbox" assurance gives an operator too little information.

The two handoffs

Property mini-swe-agent Bubblewrap zotero-mcp add-by-URL
Starting material Lower-trust repository or task content that could influence an agent command A bibliographic URL chosen by a user or influenced by retrieved content
Trusted executor An optional, experimental Linux Bubblewrap shell launched by the agent runner The host-side zotero_add_by_url tool and its generic webpage metadata fetch
Authority crossed Parent-process environment variables remain available to the restricted child The MCP host makes a request using its own network reachability
Strongest observed evidence Pinned launcher code plus a reported synthetic-variable reproduction and --clearenv negative control Reported source-level unsafe request path, CVE record and a local example, without end-to-end private-network exploitation
Necessary limits Affected backend must be enabled; a secret must be inherited; malicious agent behavior and disclosure are additional steps The writable Zotero tool must be available; destination must be reachable; readback is constrained to citation metadata or errors

The table is a comparison of mechanisms, not relative prevalence or incident severity. The first defect is classified in CVE-2026-108592, the second in CVE-2026-108583. They use different CVSS vectors, and the existing Cases preserve their qualifications.

1. The shell did not need to see the host filesystem to see a host secret

The tagged mini-swe-agent implementation supplies Bubblewrap with filesystem mounts and a replacement PATH, but its default wrapper omits --clearenv. Its subprocess.run call does not provide a sanitized env mapping. The same default arguments do not include --unshare-net. These are properties of the optional backend as written in v2.4.6, not a finding that all mini-swe-agent modes or Linux sandboxes are unsafe.

Nguyen Dinh Hai's report describes a controlled check in which a synthetic parent-process marker appeared inside the Bubblewrap shell, while adding --clearenv removed it. That test isolates the environment-inheritance error. It does not show an agent obeying a hostile README, discovering a real provider key, or transmitting the key to an external service. The distinction is recorded in the existing Case's experimental limit.

The attack would need several events after this observed weakness: an operator runs the optional backend with sensitive values in the parent environment; hostile content convinces the agent to run a command that inspects them; and the resulting output or permitted network path discloses the values. These conditions are individually testable. A sandbox need not expose a file called .env when the secret was already copied into the process environment before confinement began.

2. The reference importer could borrow the MCP host's network position

The zotero-mcp report traces a different handoff: zotero_add_by_url uses _fetch_embedded_metadata for generic webpages. The researcher's account and the VulnCheck-assigned CVE describe URL fetching without the necessary destination and redirect checks. If a URL or one of its redirects points into a private network that the MCP server can reach, the resulting request is made by the server, not by the remote text that suggested it.

The output boundary is narrower than an unrestricted HTTP proxy. The researcher describes recognized citation metadata and related errors as potential readback, with a writable Zotero backend and subsequent item retrieval part of the contemplated chain. The study is explicitly source-level and does not establish a full hostile-agent execution, a production victim or arbitrary internal-response extraction. The Zotero Case records those limits.

There is a useful remediation chronology here. June issue 326 concerned an earlier open-access PDF downloader, and a maintainer reported a fix involving private-destination and per-redirect checks. The October report concerns a different generic metadata fetch sink. It does not show the June fix was rolled back; it shows why guarding one HTTP helper does not guard every place an agent can ask the host to fetch a URL.

What a container policy can and cannot certify

Microsoft's October 7 MXC announcement is relevant because it proposes enforcement outside the model. It is not a demonstrated repair for either of these products, and its different backends cannot be treated as equivalent without testing. In its Windows-specific documentation, Learning denies and logs ungranted access, while Permissive logs and allows it; the MXC repository's audit-mode guidance also warns that --audit disables the sandbox protection for that run. A log of forbidden behavior is not proof that the behavior was prevented.

An operational acceptance test should use a named binary version and policy, and deliberately check both permitted and denied behavior. For a coding-agent runner, put a harmless marker in the parent environment and verify it is unavailable to the restricted child unless explicitly allowlisted; then test a denied outbound destination separately. For an MCP citation importer, check direct loopback, private and link-local destinations, as well as a public URL that redirects to a denied address. These are suggested defensive regression tests, not experiments performed by this publication or guarantees that a particular fix ships in a named release.

The broader AgentCorruption demonstration adds a third question: if an agent can reach a metadata endpoint, what will the resulting execution identity be allowed to do? Zenity's historical cross-agent escalation required both metadata reachability and then-broad IAM permissions; Zenity later reported narrower AgentCore defaults, while AWS characterized access to one's own execution-role credentials as expected. That is a separate system with a different impact and vendor position. It reinforces the need to test network access and downstream authorization independently.

The boundary worth certifying

A meaningful "isolated agent" claim needs at least three answers: what authority enters a child process, what destinations its tools can reach, and what actions its resulting identity can perform. Checking a filesystem mount or a model refusal is not enough. In these October records, one inheritance weakness was reproduced with a synthetic marker, while one SSRF path remained a conservatively bounded source-level finding. There is no basis here for adding their scores, claiming common exploitation, or announcing that later releases fixed both. The useful result is a concrete review checklist that can be run on each configuration before the agent receives real credentials or network authority.

Research behind this