GhostApproval: Six AI Coding Tools Were Tricking Developers Into Approving Dangerous Actions
A new attack pattern shows that the 'human approval' step built into AI coding assistants can be fed false information by the very tool it is supposed to oversee.
Key points
- Cybersecurity firm Wiz found a vulnerability pattern, named GhostApproval, affecting six major AI coding assistants as of June 2025.
- The six tools affected are Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf (now called Devin Desktop).
- In each case, a booby-trapped code repository could trick the AI tool into reading or writing files outside its permitted area, potentially giving criminals full control of a developer's computer.
- AWS, Cursor, and Google fixed the problem quickly; Anthropic had already patched it before Wiz made contact; Augment and Windsurf acknowledged the report and then went quiet.
- Security analysts say the flaw points to a design problem across the whole category of AI coding tools, not a one-off bug from a single vendor.
AI coding assistants, software tools that write and edit code alongside a developer, are now a standard fixture in software teams. They are also, it turns out, a new and largely unexamined entry point for criminals.
Research firm Wiz published findings this month describing a vulnerability pattern it calls GhostApproval. The name fits. The attack hides a dangerous action inside an approval request that looks completely innocent to the developer who clicks it.
Here is how it works in plain terms. These AI tools run inside a sandbox, a walled-off area of a computer where the tool is only supposed to touch files within a specific project folder. Criminals can plant what are called symbolic links inside a code repository. A symbolic link is a shortcut file that quietly points elsewhere, the way a desktop icon points to a program buried deep in a folder. When the AI tool follows that shortcut, it ends up reading or writing a sensitive file it was never supposed to touch, such as the SSH key files (digital passwords) that control access to servers.
Why didn't the safety check stop this?
The safety check did not stop it because the tool lied to the person doing the checking. Wiz found that in several cases the AI assistant's own internal reasoning correctly identified that it was about to touch a dangerous file outside the project boundary. The dialog box shown to the developer described something harmless instead. The developer approved what looked like a routine edit to a config file. The tool then wrote to the SSH key file it had concealed.
This is a recognised user-interface deception flaw, catalogued as CWE-451, layered on top of the symlink attack. Two separate problems compounding each other.
Katie Norton, senior research manager for DevSecOps at IDC, put it bluntly. The safety check people rely on to catch these actions does not actually stop anything. The attack requires a developer to open an untrusted or malicious repository, which concentrates the risk around external contributors, forked code, and open-source dependencies rather than internally written code.
Noah Kenney, principal consultant at Digital 520, flagged the deeper problem. Many organisations treated human approval as the answer to AI agent risk. This report shows the approval loop can be fed bad information by the very agent it is supposed to supervise.
His practical advice: treat AI coding assistants as privileged software with full filesystem access, not as glorified text editors. Run them in isolated environments. Do not rely on the tool's own dialog box as your governance layer.
For developers who use any of the six affected tools: update now, check which version you are running, and be cautious about cloning repositories from sources you do not fully trust.
In practice, the post-mortem will say a developer approved a routine-looking prompt and handed a criminal the keys to production.
