What happened
In the controlled vulnerability case, code executed from an agent container workspace resolved absolute paths on the host and could read or modify host files because nsenter attached without a separate root.
2026-10-12
HighPrimaryAgent-Run Code in sandboxed.sh Could Escape the Workspace and Read or Modify Host Files
CVE-2026-109569 showed that agent-run code in sandboxed.sh could resolve absolute paths against the host filesystem and read or modify host files.
sandboxed.shTool execution / MCPControlled demonstration of agent-workspace container isolation failing at the host-filesystem boundaryLinux hosts running sandboxed.sh through version 1.3.0 with agent code executing inside a container workspace
Why it matters
Potential disclosure, modification, or destruction of files outside the agent workspace on the host. The reviewed sources do not report exploitation against a production victim.
Missing authorization check
A runtime-enforced boundary that resolves and authorizes the actual host resource affected by an agent action instead of trusting the nominal container workspace.
Would PP block it?
External authorization can bind an agent run to an approved workspace, host-resource class, and expiry and refuse separately mediated effects outside that grant. Direct filesystem access obtained through the namespace flaw may bypass application-level enforcement, so operating-system isolation remains required.
Incident analysis
Timeline and technical read
Timeline
2026-10-12
VulnCheck and the CVE Program publish CVE-2026-109569 for the sandboxed.sh host-filesystem boundary failure.
2026-10-12
The public record identifies sandboxed.sh through version 1.3.0 as affected and links the repository change introducing an opt-in nsenter root setting.
Technical breakdown
- sandboxed.sh used nsenter to attach agent workspace processes to host namespaces without changing the process root.
- Without a separate root, absolute paths resolved against the host filesystem rather than remaining confined to the container workspace.
- Code run by an agent in the workspace could therefore read or modify host files outside the documented isolation boundary.
- The CVE assigns high confidentiality, integrity, and availability impact; the reviewed sources do not claim in-the-wild exploitation.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- The runtime boundary before an agent run receives host filesystem access or commits an effect outside its approved workspace
- Still needs
- Permission Protocol does not configure namespaces, patch sandboxed.sh, monitor arbitrary syscalls, or replace container and operating-system hardening. Direct host access that bypasses an integrated gate remains outside its coverage.
- Receipt required for
- Starting an agent run with host-access capability or committing a file read, write, or deletion outside the approved workspace
A Runtime Gate could deny effects outside an approved workspace when the file operation reaches an instrumented authority boundary, but Permission Protocol does not repair Linux namespace setup or contain arbitrary code by itself.
Start small
Put the relevant gate at this action boundary.
This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.