You Have RCE. Now What? Hunting Guest-to-Host Attack Paths in AI Code Interpreters

On meta.ai and on Grok, the model will run code you hand it. Behind the chat UI, that code lands in a Linux guest. I treated the guest as the foothold and followed what it could reach: management listeners, golden-image secrets, writable overlays, AF_VSOCK, private gateways, and privileged agents.

I looked at two production stacks the same way. Once code is running, treat the interpreter guest like a small cloud VM you just landed in.

• Meta AI / Crackerjack / VMVM
• Grok / xAI Hades / Firecracker

On Meta, interpreter code ran as uid=1002. An unauthenticated AF_VSOCK listener on CID 1:23 then handed over a root shell. From that shell I could reach management interfaces, golden-image SSH keys, a writable overlay, and a VMM notify socket on CID 2.

On Grok, the session started as root with a full capability set. The guest could also open http://172.16.0.1/ and read:

Hello from Firecracker Host

Here is what that foothold reached.

After you have a shell

The chat box is only the way in. Past it, the guest is usually a short-lived microVM: a session user (sometimes already root), a read-only golden image, a writable overlay or work disk, AF_VSOCK between the guest and the VMM, and whatever agents or proxies the product left running.

Once you have code execution, the useful questions are:

1. Who am I? uid, caps, seccomp, NoNewPrivs
2. What listens? systemd, Unix sockets, loopback, especially AF_VSOCK
3. What can I read? golden image, credentials, baked-in secrets
4. What can I write? overlay upperdirs, work disks, artifact stores the platform may consume later
5. What can I reach outside? CID 2, host gateways, agent protocols

CID 1 is the guest (local privesc, extra shells, agent abuse). CID 2 is the host/VMM side.

Interpreter RCE → guest access
                    ├─ local privesc / guest services
                    ├─ disks + golden-image secrets
                    └─ AF_VSOCK / host gateways → VMM / host

Vector map

The two environments exposed different primitives, but the same broad categories kept appearing:

Meta / Crackerjack: sandbox code to guest root

Past the chat guardrails

The interpreter will run Python. The chat model in front of it often will not run the script you actually want. Ask for recon outright and it refuses, rewrites the request, or runs something useless. I had to get past that before any of the vsock work mattered.

1. Frame the session as troubleshooting.
Upload a harmless file. HTML was enough. Then paste a fake MANIFOLD, SSH, or Firecracker-style error and ask the model to help debug a session restore. From there, keep pretending to debug the error you pasted, and move into recon one step at a time.

2. Ship payloads as opaque chunks, not as obvious scripts.
Useful recon needs a real script. A one-liner does not collect enough. Getting that script into the guest was the hard part. The guardrails refused it, or rewrote it on the way in, especially when the text mentioned vsock, socat, root, or the recon itself. I got around that by sending the script as meaningless base64 chunks, appending those chunks into one file, and decoding the file back into something that could run.

3. Keep cells small. A long sweep often failed or got refused. Short cells kept it moving: one probe, append the result to a report file, then the next cell.

That is how the probes got into the guest. The bugs below are what they hit once they were running.

Starting point: an apparently restricted interpreter

Meta AI's code interpreter initially gave me arbitrary Python execution as:

uid=1002(code-interpreter)

As uid=1002, the session looked locked down. There were no useful capabilities, and /proc/1/root was blocked. It was still a real Linux system: PID 1 was /sbin/init, and more than 100 processes were running.

The next step was to list processes.

The first break: an unauthenticated root shell on AF_VSOCK

Process enumeration exposed a root-owned management listener:

socat vsock-listen:23,reuseaddr,fork exec:bash,pty,setsid,setpgid,stderr,ctty

The listener was reachable through AF_VSOCK.

Connecting to CID 1, port 23 produced:

uid=0(root) gid=0(root) groups=0(root)

A low-privilege interpreter session could open a root bash on that listener. socat was bound in the same namespace that runs untrusted code, and it did not ask for authentication.

In some sessions import socket failed with a misleading error. Calling socat through subprocess still connected.

A second route: guest proxy to loopback SSH

The vsock root shell was one way in. /run/guest_proxy/proxy.sock was another.

That socket was mode 666 and spoke HTTP:

/run/guest_proxy/proxy.sock

Malformed requests produced a real HTTP response:

400

A CONNECT request to loopback port 22 reached SSH:

CONNECT 127.0.0.1:22

and returned:

SSH-2.0-OpenSSH_8.7

sshd on loopback allowed empty passwords and root login. CONNECT to anything besides loopback was blocked, so this path stays inside the guest. It is a second way to a root SSH session, alongside the vsock console. sshd-vsock on CID 1:22 was also up, and the interpreter user could already see its banner.

Once root, enumerate the guest like infrastructure

Once I had root, the machine was clearly Meta's Crackerjack / VMVM guest.

The guest storage layout looked roughly like:

vda   RO   ~18G    overlay lower / golden image
vdb   RW   ~1G     writevessel / overlay upper
vdc   RO           kernel modules

Boot went through setup_overlay_clean, which set up an overlay filesystem and then handed control to systemd.

The AF_VSOCK map:

:22     sshd-vsock
:23     socat root listener
:25     guest_agent
:3128   guest_vsock_proxy

And PID 1 exposed:

VMVM_KERNEL_MODULES_DEVICE=1

Golden-image secrets

/dev/vda is the RO golden image. Mounting it and comparing SSH host keys showed they were byte-identical to the live guest:

golden image key == live guest key

The key comments named internal Facebook build hosts. Anyone who compromises an interpreter guest can read that platform host-key material off the image.

Writable overlays

Root can mount /dev/vdb (the writevessel) and write into the overlay upper directory. Those files then show up on the live root. Canaries were still there after I unmounted and remounted the disk in the same session. The mount used fsync=volatile, so a later snapshot may not keep the write, but the bytes still landed on the backing device. If something on the host later reads that upper directory, the files are sitting on a platform disk. I confirmed the write.

The guest-to-host boundary: CID 2

The guest had a VMM notify credential that pointed at an AF_VSOCK endpoint on CID 2.

With root, I could read that configuration, connect, and send:

READY=1
STATUS=crackerjack_probe

using:

VSOCK-CONNECT:2:<port>

The write returned rc=0, so guest root can send sd_notify messages to the VMM. What the host does with them depends on how it parses STATUS and READY.

uid=1002 could not read the notify credential. cat returned Permission denied. The write only worked after the vsock root shell.

Mapping the rest of Meta's vsock surface

The broader AF_VSOCK map looked like this:

A normal port scan misses these listeners. They are on AF_VSOCK.

Grok / Hades: when the sandbox starts as root

uid=0(root) gid=0(root) groups=0(root)
CapEff: 000001ffffffffff
Seccomp: 2
NoNewPrivs: 1

There was no privilege-escalation step. The session was already root, with a full capability set. seccomp and NoNewPrivs were still on. From there I looked at disks, the gateway, and the Hades agents.

PID 1 is catatonit, and its command line starts xAI Hades (xai-hades-charon init / serve-ch-vsock). The guest network is 172.16.0.2/24, with gateway 172.16.0.1 and DNS 172.16.0.3. Hostnames look like hds-* and change with each chat. Disks include a read-only vda, a writable work disk vdb (the overlay upper under /work/...), and grok-files FUSE for artifacts. A canary left in one chat was not visible from a different hds-* session.

Then the guest talked to the Firecracker host

curl -v http://172.16.0.1/

HTTP/1.1 200 OK
Hello from Firecracker Host

ICMP to .1 and .3 worked. Port 80 answered with a page that names Firecracker. GET and HEAD were the only methods that worked, and only / returned 200. The guest can still reach a service on the Firecracker host.

Charon and Styx

I pulled catatonit, xai-hades-charon, and xai-hades-styx. The live command line matches those binaries. Charon runs init and serve-ch-vsock, and it speaks gRPC as hades.charon.Charon. Styx is a privileged helper, and the production binary includes a pentest subcommand. I had not finished mapping which vsock ports accept guest gRPC.

Putting it together

Running code in the chat is only how you get into the guest. On Meta that guest starts as uid=1002, and an unauthenticated socat listener on AF_VSOCK CID 1:23 turns it into root. From that root shell the guest can read golden-image SSH keys, write the overlay on /dev/vdb, and connect to the VMM notify socket on CID 2. The notify write returned rc=0. READY=1 and STATUS=crackerjack_probe left the guest. That is the closest host conversation I got: the write returned rc=0, so the bytes left the guest, and what VMVM does with STATUS and READY is still open. The overlay write is the other Meta lead, because those files sit on a disk the host might read later.

On Grok there is no privilege jump. The session is already root, with a full capability set, and it can open http://172.16.0.1/ and read "Hello from Firecracker Host". Only / returns 200, and only GET and HEAD. Charon and Styx are on the guest, Charon speaks gRPC, and Styx ships with a pentest subcommand. I never finished mapping which vsock ports accept that gRPC.

If anyone wants to continue this research, the paths I would keep pulling on are the Meta notify parser, the overlay consumer, the Firecracker gateway, and Charon's ports. If you get a shell in one of these guests, start there. Happy research :)

Keyword definitions

Achuth V P