The page load was enough

On October 27, Anthropic's Frontier Red Team published a report on five exploit chains that an unreleased internal research model found and built "after initial prompting." An exploit chain links several bugs so that each one gets the attack past a defense the previous one couldn't. The targets were Chrome, Safari, Android, Windows and Linux. Anthropic reported all five to the vendors under coordinated disclosure, and The Hacker News, which covered the report yesterday, notes that none was seen in a real attack.

Anthropic's conclusion is one line: "Frontier models have the ability to discover and combine multiple vulnerabilities into a working exploit."

One page, four bugs

The Chrome chain is the one to read closely. Its proof of concept launched Calculator from a default-configuration Chrome on macOS "within seconds of the page loading." Calculator is the traditional proof: if an exploit can start an app on your Mac, it can start anything else.

It took four bugs:

1. A flaw in V8, Chrome's JavaScript engine, let the page corrupt the engine's memory.
2. A second V8 flaw broke out of V8's own memory sandbox and gave the attacker control of the renderer, the process that draws the page.
3. A race condition in CacheStorage let that renderer read memory outside its sandbox and map the more privileged browser process.
4. A use-after-free in FedCM, Chrome's federated sign-in feature, ran the attacker's code outside the sandbox altogether.

Chrome's sandbox assumes the renderer will fall at some point and keeps the damage inside it. Steps three and four undo that. Anthropic says it has reported 62 Chrome flaws that received CVEs and were fixed as of Chrome 156, all rated critical or high, including 13 sandbox escapes and 21 renderer-compromise bugs.

The Safari chain never runs code. It gains read and write access to the browser's memory and changes one value to switch off the same-origin policy, the rule that keeps one site from reading another. With the rule off, any page could read Safari's history, cookies and session data and send signed-in requests to other sites. Apple fixed it in iOS and iPadOS 26.5.2.

The Linux chain reached a root shell over the network, with no login, on any machine running a multipath TCP listener. Leaking a kernel address took about 48 minutes and the shell five more. The bug, CVE-2026-98432, was fixed upstream on October 15.

Your agent opens more pages than you do

These are browser bugs, and a coding agent is now one of the busiest browser users on a developer's machine. It reads documentation, follows a link from an issue, opens a package's homepage, checks a search result, loads the app it just built to take a screenshot. Browser MCP servers and browser extensions have made this routine: the agent drives a real Chromium, often the same Chrome profile the developer signs into every morning.

Most of those pages are ones the developer never chose. A link in a GitHub issue, a URL in a README, the third search result for an error message: any of them can serve a chain like Anthropic's, and with the Chrome chain the agent doesn't have to click anything. The page load runs all four steps.

On a laptop, the end of that chain is the developer's account on the Mac. The same account holds ~/.ssh, ~/.aws/credentials, the gh login, the agent's own API keys and every repository checked out. Swap Calculator for a script and it copies all of them. With the Safari chain, the browser's own contents are the prize: the cookies and sessions of every site the developer is signed into, available to one page.

The same page in Bromure Agentic Coding

Bromure Agentic Coding runs Claude Code, Codex, Grok, Kimi and omp in Ubuntu VMs on your Mac. Each machine also gets its own browser: a full Chromium that opens as a pane beside the chat, which you and the agent share. The agent drives it through a built-in browser MCP server with 23 tools for navigating, clicking, reading the DOM, taking screenshots and reading the console and network log. You don't configure anything.

The browser has a VM to itself

That Chromium doesn't run on your Mac, and it doesn't run in the agent's VM either. It runs in a separate sidecar VM. The agent's VM and the browser VM share a private network so the browser can load the dev server the agent started, and that is all they share. A file the agent writes isn't on the browser's disk. Even localhost in the browser points at the browser's own VM.

Run Anthropic's Chrome chain against that browser. Steps one through four work as designed: the renderer falls, the sandbox falls, and the attacker's code runs as the browser. That code is now inside a VM that holds a Chromium and nothing else. There is no ~/.ssh to copy and no ~/.aws to read. The repository, the agent's configuration and its tokens are all in another VM, and your Mac is behind a hypervisor boundary. The agent's browser tools don't share a process with Chromium either: they reach it through a small shim that talks to the host over vsock. In the manual's words, "a hostile page can never touch the agent's files or your Mac."

The browser forgets

By default the browser is disposable. Its disk is a copy-on-write clone of a shared image, deleted when the browser is torn down. A hidden browser suspends after about ten seconds and is torn down after five minutes, and the next one starts from a clean image. A payload that lands in the browser VM goes when the VM does.

That also covers the Safari kind of chain, the one that reads cookies and sessions instead of running code. A disposable browser has no sessions from yesterday. It holds whatever the agent signed into during this task, and nothing from your everyday browsing, because your everyday browser is a different program on a different machine.

When a project needs a login that lasts, Stay signed in to websites in the machine's Browser settings keeps a profile on an encrypted disk for that machine only. Turn it on for the staging site the agent tests against, and keep it off on any machine pointed at untrusted code.

The agent's own VM holds stand-ins

Suppose an attacker gets further and reaches the agent's VM some other way, for example a malicious package the agent installs while following the page's instructions. The keys there are stand-ins. The GitHub token in gh's configuration and in ~/.git-credentials is a fake that the proxy on your Mac swaps for the real one only on its way to github.com. A stand-in sent to any other host is blocked before it leaves the Mac, and the VM pauses with an alert that names the credential and where it was going.

Scan every pull request, on your Mac

Anthropic tells defenders that "scanning your own code is more important than ever." The report adds that the scan belongs at pull-request time, because clearing the backlog "only solves half the problem" while new code keeps landing.

Bromure Agentic Coding has this built in. A code review automation watches a GitHub repository with an agent on one of your machines and files what it finds as findings, deduplicated across every scan. A watch can run three kinds of scan:

• Every new pull request, reviewing what the pull request changes.
• Every new commit on the watched branch.
• A scheduled review, weekly, of the new commits since the last one or of the whole repository. The full baseline works directory by directory in order of risk, starting with request handlers, authentication and input parsing.

Any of the five agents can run it. Each review is pinned to the commit it covered, and the agent closes the run with findings_done and a summary. The scan runs on your Mac, on the machine's credentials, inside its VM. GitHub is polled from the Mac every three minutes with the machine's token, and that token never enters the VM. There are no webhooks and no open ports.

A pull-request scanner reads untrusted text written by whoever opened the pull request, and an unattended reviewer runs with its approval prompts skipped. Bromure passes every pull request's title, body, author and comments through a mandatory prompt-injection screen before the agent sees them. If the PromptGuard model isn't installed, event-triggered runs are blocked rather than waved through. The review itself runs in a VM full of stand-ins. Set the machine's GitHub write policy to Read-only in Guardrails and the reviewer can read everything its token allows, while any push or REST write is refused on the Mac. Findings go to Bromure, not to the repository.

Patch, scan, and give the browser its own machine

Every bug in the report is fixed, and the first step is the usual one: update Chrome to 156 or later, update Apple devices, and patch kernels that run multipath TCP listeners. Anthropic is right that defenders need the same models attackers will soon have, aimed at their own code first.

The report's broader point is about the next set of bugs. If models can turn a handful of flaws into a working chain this quickly, some of those chains will be live before the patch ships. A coding agent that browses all day will load one of those pages eventually. In Bromure Agentic Coding, that page loads in a VM built to be lost, and your code, your keys and your Mac are somewhere else.

For how the Bromure browser handles browser zero-days outside agentic coding, read Why browser zero-days are not going away. For a malicious instruction that reached an agent through a downloaded file, read The download gave the orders.