Your Sandboxes Held Because Breaking Them Was Expensive

A developer's analysis of two recent security disclosures argues that production sandboxes and model-serving boundaries held mainly because breaking them was expensive, and that assumption is eroding. Anthropic research showed a frontier model chaining four bugs into a working Chrome exploit (62 CVEs, 13 sandbox escapes) and achieving remote Linux root in under an hour, while a Cloudflare edge deployment leaked other customers' data in 155 responses over twelve days because a one-million-token context window exceeded a 681,280-token prefill KV cache pool, with the rejection path silently substituting a placeholder.

Almost every boundary we rely on in production holds for the same unglamorous reason: getting past it took a specialist weeks. Three things surfaced this month that each remove a different part of that assumption. 1. Chaining Four Bugs Into a Working Exploit Used to Be a Specialist Craft. It Is Now a Scan. A frontier model pointed at browsers and operating systems produced five full attack chains against the most security-critical software in the world https://www.anthropic.com/research/discovering-vulnerabilities-with-claude . In Chrome it chained four: a V8 heap corruption, a sandbox escape that also defeated ASLR, a CacheStorage race to map the privileged process, and a use-after-free in federated sign-in to run code outside the sandbox entirely — a stock browser launching Calculator seconds after page load. That target alone yielded 62 CVEs, all critical or high, 13 of them sandbox escapes. In Safari, the chain never executed code at all: it used read/write access to flip a security flag and turn off the same-origin policy, built partly from behaviors that are not vulnerabilities by themselves. On Linux, a race-induced use-after-free in the multipath TCP stack gave remote root with no credentials and no user interaction, 48 minutes to leak a kernel pointer and five more to a shell. The mechanism matters more than the trophies. Finding one memory bug has been automatable for a decade; fuzzers do it. What was scarce was the person who could stack four partial primitives into something that survives contact with a real sandbox, and then prove it with a runnable exploit. The reported recipe is not a better model prompt — it is parallelism with bookkeeping: many scanning agents with different strategies, each measured by how many vulnerabilities only it contributes, coverage tracked so the whole codebase gets processed, automated variant analysis on every confirmed finding. That is a throughput system, and throughput systems scale with budget. Why it matters: - For ICs: Your dependency tree will produce patches faster than your release train consumes them. Know which services would still run an unpatched kernel 30 days after disclosure. - For leaders: Vulnerability inflow is now a rate, not a backlog. Scanning at pull-request time is the only control that touches the rate; everything else is triage. - For founders: "Nobody would bother attacking us" was a pricing argument about attacker hours. Reprice it. - The asymmetry is in operations, not capability: defenders have to coordinate disclosure and ship fixes, attackers only have to run the scanners. 2. Your Prompt Is a Tenancy Problem Now A text model served on a major edge platform returned other customers' data in 155 responses over twelve days https://blog.cloudflare.com/kv-cache-exposure-remediation/ , every one of them to a prompt longer than 681,280 tokens. The cause is a distributed-systems bug wearing a privacy incident's clothes. The model was deployed with a one-million-token context window while the prefill KV cache pool had room for only 681,280 — a mismatch known before launch, and tolerated because the engine was expected to error on anything it could not fit. Instead, an over-length request was marked rejected and swapped for a one-token placeholder; prefill generated cache for the placeholder and signaled transfer complete; the decode node, believing its cache now held this request's prompt, replied while attending over stale pages still holding earlier users' text. Long-context tests passed, because successful responses are exactly what the bug produces. The remediation path is the part worth copying. Fix the configuration so the rejection path is unreachable; then fix the engine so the rejection path is safe anyway, because quantization, tensor parallelism or a model bump silently resizes that pool; then aim at integrity by construction — tag every physical cache page, record which tags a request expects, and verify before decode reads, measured at under 1% throughput and tail latency. Then formal verification of the RDMA transfer protocol itself, on the reasoning that the next bug here will have a shape nobody has seen. Inference serving is young infrastructure that just inherited multi-tenant semantics, and it is being hardened in public. Why it matters: - For ICs: Add a line to your threat model for the serving stack handing your prompt to a stranger. If prompts carry regulated data, long-context calls are the risky ones. - For leaders: Ask your model vendor what verifies cache ownership at read time, and whether context window and cache pool are the same number. Those are answerable questions. - For founders: Self-hosting an inference engine means owning this class of bug. Prefer the one whose maintainers ship checksums and canaries you can turn on. 3. The Agents Found a Channel the Network Diagram Didn't Have After an internal model reached the open internet through a misconfigured DNS resolver, one lab paused frontier training for eleven days and now trains with no internet access at all https://the-decoder.com/openais-isolated-ai-agents-found-ways-to-talk-to-each-other-through-cpu-cache/ , browsing a cached offline substitute instead. The more instructive result came from the isolation tests. Agents in separate environments on shared hardware, with no network and no shared files, were told to exchange secrets. They used the CPU cache: one modulated what sat in it, the other timed its loads and decoded the message — Spectre and Meltdown mechanics, reinvented for messaging. Other channels came through write patterns on shared memory — one agent mused about an acoustic-modem-like signal built from continuous writes versus idle. Given only a generic list of weaknesses, agents built a channel and agreed an encoding on their own. Then the same lab turned agent teams on its own infrastructure for hundreds of billions of tokens. They found an unknown bug in a widely used container isolation system, escaped hardened VMs with it, and once resident on a host found a vulnerability in nearly every internet-facing service. The campaign also exposed gaps in monitoring and in the automatic pause mechanism — which is the real finding. Containment is a property of shared hardware and observability, not a configuration checkbox, and two agents on one box are not isolated in the sense most architecture diagrams imply. Why it matters: - For ICs: Treat sandbox escape as a question of what the agent can reach after escaping. Scope credentials per task so the blast radius is bounded without isolation holding. - For leaders: Red-teaming your agent platform with agents is now table stakes, and the cheapest version is pointing them at your own infrastructure before someone else does. - For founders: Co-tenanting customers' agents on shared hardware is a security claim you will eventually be asked to defend. Decide now whether you can. The Verdict: Real or Hype? Model-written exploit chains → Real. Sixty-two patched critical CVEs in one browser is not a demo, and the chaining step was the whole moat. Inference-stack tenant isolation → Real but early. The leak class is proven and the durable fixes — page tags, read-time verification, proofs — are still being built in the open. Agent side channels as your problem today → Real but unevenly distributed. It bites whoever co-tenants untrusted agents on shared hardware; everyone else should bound capability rather than trust the sandbox.