You Trusted the Folder. The File Changed.

In August 2026, a ransomware crew called Aur0ra broke into a Belgian chemical manufacturer, a German garage-door maker, a Scottish certification agency, and a Louisiana title insurer. They did it by asking Cursor to help.

Reuters and Gambit Security pieced the campaign together after Aur0ra left a server exposed to the internet. The agent had refused some of the requests. The attackers got around that by restarting the conversation and explaining, again, that this was just a simulation.

That story got the headlines, and it deserved them. But it is the loud version of a much quieter problem, one that has been sitting in your editor since the summer of 2025.

The interesting attacks aren't the ones that trick the agent, they're the ones that never need to ask.

---

Five CVEs, four vendors, one bug

Start with Cursor, July 2025. Check Point disclosed CVE-2025-54136, nicknamed MCPoison. A teammate approves an MCP server config in .cursor/rules/mcp.json. Later, someone swaps the contents for a different command. Cursor runs it. No second prompt, because the file was already trusted.

Then Claude Code. CVE-2025-59536, reported the same month: commands defined in .claude/settings.json hooks executed during startup, before the trust dialog appeared. Check Point followed it with CVE-2026-21852 in February 2026, where a repository could set ANTHROPIC_BASE_URL and intercept API requests, again before the user decided whether to trust the directory. Your API key, in a plaintext authorization header, on the way to someone else's server.

Windsurf, CVE-2026-30615, CVSS 8.0. Attacker-controlled HTML rewrites the local MCP configuration and registers a malicious server. OX Security noted it was the only IDE in that disclosure chain requiring zero user interaction.

Amazon Q, April through May 2026. Wiz found CVE-2026-12957 and CVE-2026-12958: the extension auto-loaded .amazonq/mcp.json from the workspace with no prompt, no consent, and no trust check. Their proof of concept exfiltrated AWS session credentials from opening a repository. No clicks.

Four vendors. Thirteen months. Every one of them shipped, patched, and moved on as though it were their own isolated bug.

We know that pattern first-hand, because we tested one of them. When CVE-2026-21852 landed in February we ran it against our own headless deployment rather than reading the advisory and moving on. The upstream fix protected interactive users and missed headless mode entirely, and we watched eighteen API requests redirect to a server we controlled inside thirty seconds. The patch was real. The coverage was not.

That is worth holding onto, because it is the same shape one layer up. Each vendor fixed their instance. Nobody fixed the assumption.

When five teams independently build the same vulnerability, it isn't a bug, it's a design assumption nobody wrote down.

---

The assumption underneath

Here is the shape they all share, and it is worth saying slowly.

These tools ask you to trust a directory. What they then execute is a file. Those are not the same thing, and the gap between them is the entire vulnerability class.

A directory is a stable idea. You opened a repo, you know roughly what it is, you clicked yes. A file is not stable. It changes on every git pull. It changes when a collaborator pushes. It changes when a dependency updates a template. The trust decision happened once, in the past, about a thing that keeps moving.

Worse, the file in question is not code you review. It is configuration, and configuration gets a pass. Nobody reads .cursor/rules/mcp.json in a pull request with the care they give a function. It looks like plumbing.

Your reviewer reads the diff, your agent reads the config, and only one of those is being watched.

The second assumption is quieter and it is the one that actually stings. Every tool in that list treated the contents of the repository as instructions rather than as content. A settings file said run this, so it ran it. HTML said register this server, so it registered it. The repository was allowed to configure the thing that was supposed to be examining the repository.

That is the same inversion behind prompt injection. We just did not recognize it, because it arrived wearing a filename instead of a paragraph.

---

What Anthropic shipped, and why the small print matters

In August 2026, Claude Code added a --restricted mode (also CLAUDE_CODE_RESTRICTED=1). It removes the tools that run commands or code, drops WebFetch unless you name it explicitly, confines file tools to the working directory, and refuses bypassPermissions.

All useful. But the line that matters most is the least dramatic one:

It ignores user, project, and local settings files.

Read that against the CVE list and it is not a general hardening feature. It is a direct answer to this exact class. The fix for "the repository can configure the agent" is "the agent stops reading configuration from the repository." Everything else in restricted mode is defense in depth. That one line is the actual patch.

The most important security feature in a release is usually the boring line in the changelog.

---

What we run, and what it caught

We run our own automation on Claude Code, with a validator sitting in front of every tool call. It is not clever. It matches intent against a policy and refuses what falls outside it, before the call executes rather than after.

Yesterday it stopped me twice. I was mid-deploy, reached for a force-push to tidy up a branch, and got refused both times. The policy treats history rewrites as something a human decides, not something an agent does on its own initiative.

I was annoyed for about four seconds. Then I took the longer route, which was two extra commits and no lost history.

That is the honest experience of running these controls. They are not exciting. They cost you a few seconds and occasionally a little dignity. What you get back is that the interesting failure never happens, which means you never find out how interesting it would have been.

A control you never notice working is indistinguishable from one you didn't need, right up until it isn't.

---

What to actually do about it

If your team uses any agentic coding tool, three things are worth doing this week.

Treat agent config files as executable. .claude/settings.json, .cursor/rules/mcp.json, .amazonq/mcp.json, .mcp.json. Put them behind CODEOWNERS. Require review from someone who knows what they do. They are not plumbing, they are a shell script with a different extension.

Check what your tools do on untrusted repos, today. Not what the docs claim. Open a scratch repository with a config file in it and watch what happens. Every vendor above believed their trust model worked until someone tested it.

Turn on the restrictive mode where one exists. --restricted in Claude Code, workspace trust in the JetBrains and VS Code families, explicit MCP approval in Amazon Q since 1.69.0. Defaults are set for onboarding, not for you.

And if you already have a validator or a policy layer in front of your agents, go look at what it actually blocked in the last month. Not what it could block. What it did. That list tells you more about your real exposure than any threat model you will write.

The uncomfortable part of the Aur0ra story was never that an agent could be talked into causing harm. It was that four separate vendors had already built tools that would do it without being asked, and shipped them to everyone.