Researchers Walk an AI Agent Out of Its Sandbox and Onto the Host Mac

The researchers named the chain SharedRoot. The findings went public on July 23, 2026.

What Happened?

The setup looked strong on paper. The agent ran inside a real virtual machine as an unprivileged user, wrapped in a syscall filter, with connected folders passed in by a root daemon. Most of that held up fine.

One detail did not. The entire host filesystem was mounted into the virtual machine read and write, visible only to the VM root user. That single mount became the exit door.

Getting to it took six steps. The agent created a user namespace, which Linux allows unprivileged users to do by default. Inside that namespace it held root capabilities, including CAP_NET_ADMIN. With those, it configured a traffic control rule that pulled in a kernel module called act_pedit. Merely naming the module made the kernel load it.

That module carried CVE-2026-46331, publicly known as pedit COW. It is an out of bounds write in the packet editing path where the kernel calculates its copy on write range before it knows the real write offset. Writes then land in the shared page cache. Red Hat rated it Important. A working exploit went public one day after the CVE was assigned on June 16, 2026. Affected kernels run from v5.18 through v7.1-rc6, with the fix landing in v7.1-rc7 and in vendor backports.

The agent used that primitive to poison the cached copy of a root owned helper binary it could read but not write. The on disk bytes never changed. The root daemon later re-executed that helper, ran the poisoned copy, and handed root inside the guest. From there, the shared host mount did the rest.

The chain was reported to the vendor and closed as informative. The CVE fell inside the program window for recently published bugs, and the remaining items were read as defense in depth. The product now runs agent work in the cloud by default, and this local path does not appear to apply there.

What’s the Impact?

The kernel bug is the least interesting part of this story.

The net/sched area of Linux produces this exact shape of flaw on a steady schedule. An autoloadable module, a config path an unprivileged user can touch, a memory bug waiting at the end. Patch this one and the chain simply waits for the next one. Everything above the kernel stays exactly as it was.

That matters more now because bug discovery has sped up. AI assisted vulnerability research has pushed kernel privilege escalation advisories to roughly 2.3 times the prior year by one count. The window between a fix landing upstream and a working public exploit has shrunk to hours.

So any guest kernel is quietly behind, most of the time. Building containment on the assumption that it is clean is a bet you keep losing in slow motion.

Then there is the blast radius question. Root inside a VM is a contained event or a full host compromise depending entirely on what you mounted into that VM. Here, it was everything.

How to Avoid This

Four fixes break this chain, and any one of them is enough.

Turn off unprivileged user namespaces. Set apparmor_restrict_unprivileged_userns=1 or kernel.unprivileged_userns_clone=0. Step one fails and the rest never happens.

Flip the syscall filter from default allow to default deny. Block unshare, setns, and clone3, reject namespace flags on clone, and restrict socket address families so AF_NETLINK is refused.

Stop unused modules from autoloading. Use install … /bin/false for act_pedit and every net/sched module the guest does not need. Also keep any helper binary a root daemon might execute outside the session user’s view.

Scope the host mount. Share only the folders that were actually connected, read only where possible. Then even full guest root has nowhere to land.

Patch the kernel too. Vendor fixes are out for RHEL 8, 9, and 10, AlmaLinux 8, Debian 13, and several CloudLinux streams.