Agent Workspace Boundary Escape via Host-Root Mount and Unprivileged Namespace Escalation (CVE-2026-46331)
Some AI agent desktop apps run the agent inside a Linux VM for isolation, but a bug exposed the entire host filesystem read-write inside that VM. Combined with a Linux kernel privilege-escalation flaw (CVE-2026-46331), an agent that gets tricked or exploited can jump from its sandbox into full control of the host machine.
How the attack works
The agent runtime is meant to be confined to a VM with no visibility into the host. A flawed mount published the host's root filesystem read-write into the guest, accessible only to a privileged user inside the guest. An attacker gets the agent to escalate privileges inside the guest — for example via an unprivileged user namespace that still grants CAP_NET_ADMIN, then loads a vulnerable traffic-control kernel module (act_pedit) that has a copy-on-write bug (CVE-2026-46331) letting it corrupt kernel memory. Once privileged in the guest, the attacker uses the exposed host-root mount to read or write anything on the host, including credentials, SSH keys, and startup files. The whole chain can be triggered by instructions the agent was fed, not just direct human commands.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 9b34f0bb-355b-447a-9ab1-16a92628e833
- Severity
- Critical
- CVEs
- CVE-2026-46331
Why it matters
An attacker who compromises the agent, or who feeds it malicious instructions, can escape its intended sandbox and gain full read-write access to the host machine, including credentials and persistence locations — turning what should be a contained agent workspace into a full host compromise.
What you can do
- →Check whether your agent runtime bind-mounts the host filesystem into its VM or container, and remove or restrict any such mount, especially write access.
- →Disable unprivileged user namespace creation or restrict the capabilities it grants (particularly CAP_NET_ADMIN) if not required.
- →Block autoloading of unnecessary kernel modules, including act_pedit / traffic-control modules, inside agent sandboxes.
- →Monitor agent tool calls and file paths for access to host-root bridge locations (e.g. /proc/1/root, /run/host, /mnt/.virtiofs-root) and for attempts to read credential files or disable sandbox hardening settings.
Known benign look-alikes
- RESIDUAL, NARROWED: container and VM diagnostic agents inspecting /proc/1/root or /run/host. Configuration reads under those bridges (/run/host/etc/os-release, /run/host/etc/resolv.conf, /proc/1/root/etc/apt/..., readlink /proc/1/root) were verified NOT to fire after the Layer 1 dual-use split. What still fires is a read of host CREDENTIALS (/etc/shadow, /etc/sudoers, /etc/ssh/, keychains) or a descent into a host user home through those bridges — which is the boundary crossing itself, so it is reported deliberately.
- RESIDUAL, NARROWED: Flatpak, toolbox and distrobox tooling reading configuration under /run/host no longer fires. The remaining exposure is toolbox/distrobox home passthrough — /run/host/home/<user>/... is a legitimate mount for those tools but is indistinguishable, in the tool argument alone, from an agent reading the host user's home. Kept as a detection because host home access from inside the guest is the reconnaissance step of this escape.
- Network-engineering agents in a lab that legitimately configure tc pedit actions for packet header rewriting.
- Kernel or distribution CI that intentionally loads act_pedit to regression-test the CVE-2026-46331 fix.
- Backup, migration or provisioning agents writing to ~/Library/LaunchAgents or /Library/LaunchDaemons because the operator explicitly asked for a launch item to be installed.
- Rootless container builds that run unshare followed by ip link add or modprobe for legitimate CNI setup.
- Incident-response runbooks quoted verbatim into a tool argument, where an example command and the /mnt/.virtiofs-root path appear on the same line.