GhostApproval symlink bug hits six AI coding assistants
Wiz research: Amazon Q, Cursor, Claude Code, Augment, Antigravity, Windsurf all approved one file path in the dialog while writing to another via symlinks.
Wiz disclosed a class of bug it calls GhostApproval on Tuesday, spanning six AI coding assistants: Amazon Q Developer, Anthropic’s Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The mechanic in every case is the same. The assistant asks the developer for permission to write a specific file. The path shown in the dialog looks harmless — some local project artifact. The write itself, after symbolic-link resolution, lands somewhere else entirely: a shell rc file, an SSH authorized_keys entry, a tool config. The consent covered a name; the write followed a link the dialog never surfaced.
Two CVE IDs are already assigned. CVE-2026-12958 covers Amazon Q Developer (CVSS 7.8, high) and is fixed in Language Server 1.69.0 and later. CVE-2026-50549 covers Cursor (CVSS 9.8, critical) and is fixed in v3.0. Google has patched Antigravity with a CVE still pending. Augment and Windsurf remain unpatched at time of publication. Anthropic disputes that Claude Code is vulnerable in the same sense; the company shipped a symlink warning in February 2026 and takes the position that the resulting prompt is the fix. Wiz classifies it as affected. The Hacker News writeup carries the vendor tally in more detail.
The class
There is a specific pattern in security that we keep re-shipping, roughly once a decade, in whatever framework happens to be new. It goes: a system asks the user a yes-or-no question about one operation, and then, between the question and the answer, quietly changes what “the operation” refers to. The classic version is a filesystem race — a check-then-use window where the file being checked is not the file being used. UAC prompts spoofed with the wrong window title were another version. Antivirus quarantine dialogs that displayed one path and acted on another, in the days when antivirus was still the interesting attack surface, were a third. The bug is not really in any of those specific dialogs. The bug is that any consent UI which shows a name instead of a resolved handle can be pointed at something the user did not consent to. Symbolic links are only the most convenient way to do it.
What GhostApproval demonstrates is that AI coding assistants have quietly re-implemented the same load-bearing consent pattern — the file-write approval dialog is the last line between a booby-trapped repository and the developer’s home directory — without inheriting the twenty-plus years of lessons about what that pattern gets wrong. Six assistants, six independent codebases, one class of bug. That is not a coincidence and it is not a hard problem to explain: the assistants are being written by teams solving the “how do we prompt the user before touching a file” problem for what feels, to them, like the first time. It isn’t the first time. It is at least the fourth.
No in-wild exploitation, and the reason it matters anyway
Wiz reports no observed exploitation. The disclosure is research, not incident response, and there is no CISA KEV entry for any of the three assigned CVEs at time of writing. That gives shops a window — small, but real — to patch before the technique migrates out of the writeup and into the compromised-npm-package pipeline it will very obviously fit into next. The HalluSquatting work out of Tel Aviv last week already showed how comfortably AI-adjacent supply-chain attacks translate research into wild packages. GhostApproval-flavored payloads dropped into an AI-hallucinated dependency have every ingredient they need.
What to actually do
- Update Amazon Q Developer to Language Server 1.69.0 or later. Update Cursor to v3.0 or later. Update Google Antigravity to the current release.
- For Augment and Windsurf, treat the assistant as untrusted with respect to files it did not create. Run it in a sandbox, a VM, or under a user account that cannot reach
~/.ssh,~/.zshrc, or the assistant’s own configuration. Wiz’s own guidance goes further — restrict file access at the process level rather than trusting the approval dialog. - Review the READMEs of repositories before pointing an agent at them. A booby-trapped repo needs the symlinks in place before the agent runs; the setup shows up in the tree.
- After a session, check timestamps on the files GhostApproval targets in Wiz’s writeup — shell rc files, SSH keys, tool configs. A modified timestamp on a file the assistant should never have touched is the signal.
For Anthropic’s dispute, the practical read is this: the warning shipped in February is a mitigation with the same failure mode as every other consent dialog in the history of computing, which is that users click through warnings and always have. Whether that meets the bar for “not vulnerable” is a question about vendor policy, not a question about what an attacker can do to the endpoint. The endpoint is the endpoint either way.
Sources
Found this useful? Share it.


