GhostApproval and the Coding-Agent Supply Chain
A category level flaw in six major AI coding tools landed unceremoniously in July. The story the existing write ups are missing...
The write you approved without seeing
Here’s the GhostApproval attack in a nutshell: A developer clones a repository and asks Claude Code to set up the workspace. The agent reads the README, gets to work, and reaches for a file called project_settings.json. In its internal reasoning, captured in Wiz’s screenshots, the agent notes: “I can see that project_settings.json is actually a zsh configuration file.” This is the important bit: The agent knows that the filename is a costume. The file is a symlink, and the write is going somewhere else.
Then the agent turns to the human and asks: “Make this edit to project_settings.json?”
The developer clicks yes and the agent writes an attacker’s SSH public key into ~/.ssh/authorized_keys, and someone on the other side of the internet now has persistent, password-less access to the machine. (Wiz Research)
I build security programs for AI-native startups for a living, so I sit on both sides of this dialog box: helping teams decide what their agents should be allowed to touch, and running the same agents myself all day and this is the sharpest example I’ve seen of a control that triggered exactly as designed and protected nothing. The human-in-the-loop was in the loop. The loop just lied to them. The agent knew the real target, the HITL check showed a fake one, and the approval was informed consent in form and a rubber stamp in fact.
Hold on to that image. The rest of this piece pulls back from it, because the bug has already been covered and I think the bigger story is worth more attention.
What GhostApproval actually is
So, the mechanics, quickly:
GhostApproval is Wiz’s name for a pattern they found across six of the most used AI coding assistants: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. It stacks two primitives into a novel target. The first is symlink following, which has been a security sore spot since the early days of Unix. The second is UI misrepresentation of critical information: the confirmation dialog fail to show the true destination, instead showing only the alias. (CWE-61, CWE-451)
Exploitation is straightforward: A malicious repo ships a symlink, say project_settings.json pointing at ~/.ssh/authorized_keys, plus a README telling the assistant what to “configure.” The victim clones the repo and asks their agent to set up the workspace. The agent follows the link and writes attacker controlled content outside the workspace. <bad guy mic drop noises>
Symlink abuse is decades old. It’s the trick behind the runc container escape, an npm tar traversal, and more /tmp race conditions than anyone has counted. What’s new is the target class: coding agents with autonomous filesystem write access, wrapped in an approval UI that’s standing in for judgment. This is not an exotic exploit. It’s an old trick that works because a new category of tool put a confirmation dialog where a security boundary needed to be. Six vendors, one design gap, and about a one-week news life. (CVE-2024-21626, CVE-2021-32803)
Agent-written code is supply chain
Now rewind about twenty years.
In the early 2000s, developers went from writing most of their own code to composing applications out of open-source dependencies they didn’t write and mostly didn’t read. That delegation of authorship is what created the software supply chain as we understand it today, and every npm and PyPI compromise since has been the bill for that trust default coming due. We didn’t call it a supply chain at the time. We called it productivity.
2026 rhymes. “I don’t write code anymore” is a sentence said with pride in a lot of developer conversations right now, and I’ve said versions of it myself. But listen to it as a security statement instead of a productivity statement: code authored by an external entity is being introduced into your codebase, continuously, and trusted by default. The provenance changed. In 2005 it was a maintainer you’d never met; in 2026 it’s an agent run by a vendor. The structure is identical. A business relationship, a DPA, or an EULA doesn’t change the trust topology, it just changes who you can sue.
To be clear about what I’m not claiming: I don’t think agent-written code is more dangerous than code your own team writes. Human beings introduce vulnerabilities with great enthusiasm and always have. The point is narrower and, I think, more useful: this is the same class of trust delegation we already learned to manage for open source, showing up again with the lesson un-applied.
And GhostApproval sharpens the frame one level further. It’s not just the agent’s output that’s a supply-chain input. The tool itself is a privileged, externally-controlled, auto-updating node with write access to the developer’s machine, sitting inside the perimeter... which is a dependency in the fullest sense of the word. The provenance changed, an agent instead of a maintainer, but the bargain is the one we made with open source in 2005: trust code we didn’t write, by default, and hope the tooling has our back.
Why bother with the reframe? Because once you see the coding agent as a supply-chain component, the right questions fall out on their own. Where did this come from? What can it touch? Who changes it, and when? What’s the blast radius when it misbehaves? Those are the exact questions that matured around OSS dependencies over twenty years of pain. We don’t have to rediscover them from scratch.
What the timeline says
Here’s the disclosure record. I’d encourage you to read it as a supply-chain artifact rather than as drama.
Wiz discovered the pattern on February 10, 2026, and notified all six vendors between February 12 and March 5. Public disclosure came on July 8, after a coordinated-disclosure window of 90-plus days. At that point: three vendors had fixed it, two were listed as “In Progress,” and one had rejected the report. (Wiz Research)
The statuses kept moving while I was writing this, which is sort of the point. At disclosure, Augment was “In Progress.” By the time SC Media followed up, an Augment spokesperson said the company had reproduced the findings but considers the behavior expected product behavior rather than a vulnerability, and is not issuing a patch. Windsurf, as of this writing, has shipped nothing and didn’t respond to press inquiries. If you run either tool, your patch status is not a settled fact. It’s a feed you need to be subscribed to. (SC Media)
One detail deserves its own paragraph, and it’s Windsurf’s variant. The agent wrote the modification to disk before the Accept/Reject buttons appeared in the UI. By the time you saw the prompt, the attacker’s key was already in your authorized_keys file. A confirmation dialog that appears after the write has already happened isn’t a gate. It’s an apology. (Wiz Research)
Five months from discovery to disclosure, with two Critical-rated tools still unpatched at go-public and one of them silent since. That’s the supply-chain story told in one row of dates.
Ship first, harden later, and the infrastructure bar
Now the part I’ll editorialize on, carefully, because I think the vendor response is more revealing than the vulnerability.
Anthropic’s first response to Wiz was to close the report as outside their threat model: the user confirmed they trusted the directory, the user approved the edit prompt, therefore the user owns the outcome. That’s a coherent position, and Wiz presents it fairly as a real design-philosophy question. But notice the reflex. The first institutional move was to dispute the framing and route responsibility to the user, and it took a public writeup and press questions to surface the fuller story. (Wiz Research)
And here’s the part that makes this interesting rather than a pile-on: Anthropic had already done the work. A symlink warning shipped in Claude Code v2.1.32 on February 5, nine days before Wiz’s report arrived, as proactive hardening out of internal review. Current versions resolve symlinks and warn before writing to sensitive files. They weren’t caught flat-footed. The engineering organization was ahead of the researchers, and the disclosure-handling posture still defaulted to “not our problem.” That gap, between what the engineers built and what the institution said, is the tell worth staring at. (Wiz Research, SC Media)
Because it’s not an isolated gap. The cadence across the agent-tooling wave looks like this: ship a powerful capability fast, then discover and patch the sharp edges under external pressure, with governance and enterprise controls trailing behind. Anthropic’s Cowork, the agent environment that runs untrusted code in an isolated sandbox, had a full sandbox-escape chain to root disclosed and patched within months of launch. Meanwhile the admin side of agentic coding, visibility, policy, org-level controls, is still routinely described as nascent relative to how deep adoption already runs, with meaningful admin tooling landing well after the capabilities did. (Threat-Modeling.com, Airia)
Let me say the fair thing plainly: ship-first-harden-later is a virtue at startup scale. It’s how product-market fit gets found, it beats analysis paralysis, and the fast iteration loop is a big part of why these tools got good enough to matter. Coordinated disclosure also worked as intended for three of the six vendors here, which is what the process succeeding looks like.
But the bar moves with scale. A company whose tool can write to millions of developers’ filesystems and CI systems isn’t a scrappy startup shipping an editor plugin anymore. It’s infrastructure. And infrastructure is graded differently: the threat model, the enterprise controls, and the “own it” posture have to ship with the capability, not trail it by two quarters and a headline. The strongest counter-argument is that no vendor can anticipate every abuse of a general-purpose agent, and that’s true. I’m not asking for clairvoyance. I’m asking for the posture to scale as fast as the install base does.
What human-in-the-loop has to mean
Wiz’s guidance to vendors is three items long: resolve symlinks before displaying the prompt and show the canonical target; flag loudly when the resolved path leaves the workspace, because a write to ~/.ssh/authorized_keys should look categorically different from a write to ./config.json; and never touch disk before explicit authorization, because a dialog is a gate, not an undo button. (Wiz Research)
Good list. Here’s the generalization I’d want every team building or buying agents to internalize: an approval UI is a trust boundary, and a trust boundary is only real if the human is shown ground truth at decision time. “Human-in-the-loop” is not a control by virtue of existing. It’s a control when the loop can’t be lied to. An approval prompt is a security control the way a lock is a security control, only if it’s actually between the attacker and the thing.
And this is the same lesson the open-source supply chain spent twenty years learning. Provenance and integrity have to be shown, not assumed. That’s what signed packages are, and lockfiles, and provenance attestations. The coding-agent layer is now re-learning it, on a compressed timeline, with write access to your home directory.
What to do Monday
None of this requires panic, and none of it requires waiting for vendors. If your team runs these tools, a few moves are available right now:
Inventory the agents your engineers actually use, and treat that list like the dependency manifest it is. You can’t reason about a supply chain you haven’t enumerated.
Pin and watch versions. These tools auto-update, which means “we’re patched” is a moving target to monitor, not a fact to assume. Two of the six tools in this story still have no fix.
Treat clone-and-setup as untrusted input. The “set up the workspace” step is an execution surface, not a convenience.
Scope the agent’s filesystem and tool access. Blast radius is an authorization choice you get to make, not a property of the tool you have to accept.
Ask your agent vendors the questions you already ask about OSS: what’s your disclosure process, what’s your patch SLA, where are the trust boundaries, what do the enterprise controls actually cover.
None of this slows anyone down. It’s the same suspicion you eventually learned to apply to the code these tools write, extended to the tools themselves.
The durable point
GhostApproval will be patched nearly everywhere before long, and in a year it’ll be a footnote. The durable fact is the one underneath it: a new class of external code-author walked into the software supply chain, sat down next to the open-source maintainers, and most teams haven’t updated their mental model or their controls to notice. The suppliers are still working out what their own posture is; the disclosure record above shows them working it out in public. You don’t have to wait for them to finish. The questions are twenty years old, and they still work.
I’m Chris. I run ClineSec, a security consultancy that helps AI-native startups stand up their first security program: the supply-chain thinking in this post, plus the SDLC and pipeline foundations underneath it. If your team ships with coding agents and nobody owns this problem yet, that’s the problem I solve.