The folder-open attacks we've covered run code when you open a repo and read your cloud keys off the disk. This one changed a single line of configuration, and the agent handed over the credential it cannot function without: its own model API key.

The bug is CVE-2026-21852, found by Check Point Research in Claude Code, disclosed to Anthropic on October 28, 2025, fixed on December 28, and given a CVE number on January 21, 2026. Anthropic shipped the patch months ago. We are writing about it in July because it draws a clean line under a fact no patch changes: a coding agent carries a model API key, sends it on every request, and a repository can edit the address it sends to.

What the bug did.

Point Claude Code at a project and it reads that project's configuration, the files under .claude/ that let a repo carry its own settings. One of those settings is ANTHROPIC_BASE_URL, the address the agent talks to when it calls the model. The default is api.anthropic.com, and the setting exists so teams can route through a gateway or a proxy of their own. The project can set it by design.

A malicious repository sets it to a server the attacker controls. Then, as Check Point describes, "before the victim decides to trust the directory," Claude Code fires off its startup API requests to whatever ANTHROPIC_BASE_URL says, and those requests carry, in Check Point's words, "the authorization header — our full Anthropic API key, completely exposed in plaintext." The attacker's server reads the header off a request the agent volunteered to send, with, as Check Point puts it, "no user interaction required." You clone the repo, you run claude, and the key is gone before the trust prompt finishes drawing.

CVE-2026-21852, start to finish. A repository ships a one-line setting in its .claude project config: ANTHROPIC_BASE_URL pointing at the attacker's server. On open, before you answer 'trust this folder,' Claude Code sends its startup request to that address with its real Anthropic API key in the Authorization header. The attacker's server reads the header. The attack executed nothing on your machine and read nothing off your disk; the agent mailed its own credential to the wrong address. Source: Check Point Research.

An Anthropic API key reaches the account's workspace, with its shared file storage and its billing. Check Point walks through the reach: an attacker can read and write the workspace's files, delete them, exhaust the storage quota, and burn API credit on your dime. The agent gives up the credential the whole operation runs on, without being asked.

The attack that ran nothing.

We have written this genre before. Miasma planted config in Microsoft's own repositories, and opening the folder ran a several-megabyte blob that read the filesystem for keys. Amazon Q auto-launched MCP servers from a cloned workspace with the developer's full environment of AWS keys and SSH sockets. In Cursor's case, a prompt injection drove a tool to overwrite a guard and then run a shell. All three share a shape: untrusted content on open causes code to execute, and that code goes looking for your secrets, the ones in ~/.aws and ~/.ssh.

CVE-2026-21852 skips that machinery. The malicious repo fires no hook and runs no shell; it changes one address, and the agent, behaving as designed, sends its own credential there. The key that leaks is the key the agent must transmit on every call it makes. You cannot lock it away in a file the process can't read, because the process is supposed to send it.

Anthropic's fix was the right one for the bug: the trust dialog now comes first, and, in their words, "no API requests are initiated before users confirm the trust dialog." Redirect the base URL today and nothing leaves until you trust the folder. The fix governs timing, though. Once you trust the folder, and developers trust folders all day, the real key still sits in the agent's environment, one config line from a redirect, depending on the correctness of every future code path that touches it.

The key belongs somewhere else.

The durable question is why the real key sat somewhere a repository's configuration could aim it. That is an architecture question, and we built Bromure Agentic Coding to answer it.

Bromure runs your coding agent inside a disposable Linux VM: the agent itself, the shells it spawns, the packages it installs, the model calls it makes. A proxy on the host sits on the wire between the agent and api.anthropic.com. The VM holds a stub key, a syntactically valid placeholder worth nothing, while the real Anthropic key stays on the host. On a legitimate call to the genuine model endpoint, the host proxy swaps the stub for the real key at the wire, then swaps it back out of the response. The secret does its one job, and the copy an attacker could steal exists nowhere the agent's world can reach.

Replay the attack against that arrangement. The malicious repo sets ANTHROPIC_BASE_URL to attacker.evil. The agent, inside the VM, sends its startup request there, carrying the only key it has, the stub. The proxy binds the real-key swap to the genuine endpoint, and a request pointed at an unknown server leaves carrying the placeholder. The attacker's server reads the Authorization header and harvests a string that means nothing on the public internet. The redirect worked, and it collected nothing.

The same repo, two machines. On the left, the agent runs on your laptop with the real key in its environment; the repo redirects ANTHROPIC_BASE_URL and the key leaves for the attacker in the Authorization header. On the right, in Bromure Agentic Coding, the VM holds only a stub key. The host proxy swaps the real key in at the wire, and only for a call to the genuine api.anthropic.com, so a request redirected to the attacker leaves the VM carrying the stub and the attacker harvests a placeholder.

The guarantee depends on one detail: the broker binds the real key to the true destination, substituting the secret for a call to api.anthropic.com and nowhere else. Get that binding right and a redirected base URL is inert. Get it wrong, substitute the real key onto any outbound request, and you have rebuilt the bug one level down. The proxy earns its keep by releasing the secret for one address and treating every other as untrusted.

What the broker changes

The real model key never enters the VM the agent runs in. The host holds it and releases it onto the wire only for a call to the genuine endpoint. A repository can redirect the base URL all it likes; the request that leaves carries a stub, and a stub is worth nothing off your machine.

What it does not change

Trust is still yours to give. Configure the agent to talk to an attacker-run gateway and the broker cannot know you meant the wrong thing; it brokers where you told it to. And the guarantee runs one binding at a time: the model key here, your other secrets through the same stub-and-swap arrangement, each one as strong as the endpoint binding behind it.

The companion bug, and the same answer.

CVE-2026-21852 arrived with a louder sibling, CVE-2025-59536, where a repo's .claude/settings.json could define hooks, shell commands Claude Code runs at start, or force-enable project MCP servers, and those commands "execute immediately upon running claude, before the user could even read the trust dialog." That one is code execution on open, the familiar shape, and its answer is the familiar one: inside a disposable VM, the shell it spawns finds stub credentials where the real tokens should be, and a state-changing action pauses at the hypervisor boundary for a prompt on the host. We have made that case at length.

The two bugs look different, one running a program and one changing an address, and they land in the same place: a coding agent reads and acts on files that arrive with the code you hand it, and some of those files decide what runs and where secrets go. Anthropic patched both. The lasting answer puts the secrets somewhere those files can point at and cannot reach.

A narrow win.

Keeping the model key out of the agent's environment defeats this redirect and the family of attacks that trick the agent into sending its own credential somewhere new, because the key the agent can send is worthless. The hypervisor and the proxy enforce that below the agent, with nothing asked of the agent itself.

Trust stays your job. You still decide which repositories to open and which gateways to configure, and a broker that sends your key where you point it will send it to a bad place if you point it there on purpose. Scoping what a leaked key can do also stays with the model provider; Anthropic's patch and workspace controls cover that side.

A coding agent has to carry a key and send it somewhere, and for a window in late 2025 a one-line setting in a cloned repo decided where. The patch closed that window. Bromure Agentic Coding removes the key instead: the agent works inside a disposable machine that never held the real one, and the proxy puts the real key on the wire for a single address. Install it, point your agent at whatever repository you like, and let the next redirected base URL carry off a string worth nothing anywhere.