Can you trust your AI coding assistant? What the GhostApproval flaws mean for the software you ship

Last updated: 27 August 2026

Your engineers almost certainly let an AI coding assistant edit files on their machines this week. Claude Code, Cursor, Amazon Q Developer, Windsurf, Google Antigravity and Augment all work the same way: the assistant proposes a change, a dialog asks you to approve it, and someone clicks yes. That dialog is the security model. In July 2026 a piece of research called GhostApproval showed that, across all six of those tools, the dialog could be made to lie [1].

This is part of our AI code quality coverage, where the question is always the one a buyer asks us first: is the software safe to ship? GhostApproval is worth your attention not because it is exotic, but because it is ordinary. And because the argument one vendor made in response is, almost word for word, the argument for keeping a named senior engineer in the loop on what these tools actually do.

What GhostApproval is

GhostApproval is not a single bug in one product. Wiz Research, which disclosed it on 8 July 2026, calls it "a systematic vulnerability pattern" in which "a malicious repository can trick the agent into accessing arbitrary files outside the workspace sandbox" [1]. It combines two weaknesses that have been in the security literature for decades: following symbolic links (CWE-61) and misrepresenting security-critical information in the interface (CWE-451) [1].

The mechanism takes one sentence to describe. A repository your team clones contains a symbolic link, a file that is really a pointer to another location on disk. When the assistant offers to write to what looks like an ordinary file inside the project, the approval dialog shows you the ordinary name, but the write follows the link and lands on the real target, which can sit well outside the project, for example ~/.ssh/authorized_keys. Approve the innocent-looking edit and you have quietly added an attacker's key to the list of keys allowed to log into your machine [1]. SecurityWeek described the underlying move as a "decades-old technique", which is exactly right: symlink attacks are older than every tool on the list [4].

Wiz tested six assistants and found all six exposed in some form: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity and Windsurf [1]. Independent reporting from The Hacker News and Infosecurity Magazine confirmed the same set of tools and the same mechanism [2][3].

The approval dialog was the whole model, and it was not telling the truth

Every one of these tools leans on the same safety promise: the agent can do a great deal, but a human approves the actions that matter, so a human stays in control. GhostApproval breaks that promise at the exact point where it is made, the dialog itself.

The severity was not uniform, and the differences are instructive. On some tools the dialog simply named the wrong destination. On Windsurf it was worse. Wiz found that the agent "writes file modifications directly to disk before the Accept/Reject buttons appear in the UI", so, in their words, "the confirmation dialog isn't an authorization gate", it is "an undo mechanism" [1]. By the time a developer reads the prompt, the write has already happened. Augment was worse still: Wiz reported that it "followed symlinks for write operations", and did so "silently. No 'Allow/Deny' dialog, no 'Undo' button" [1].

Sit with what that means. A control most teams believe is protecting them was, on two of these tools, either after the fact or absent altogether. The approval step looked like governance. It was theatre.

Whose threat model is it?

The most revealing part of GhostApproval is not the flaw. It is one vendor's response.

Anthropic declined to treat the Claude Code case as a vulnerability. Its position, as published by Wiz, was that "this falls outside our current threat model. When the user first starts Claude Code in a directory, they must confirm that they trust the directory prior to starting the session", and that a user who then confirms a permission prompt inside a directory containing a malicious symlink is acting "outside of the Claude Code threat model" [1]. Anthropic also notes it had shipped symlink warnings earlier in 2026 as routine hardening, rather than as a fix for this [2].

There is a coherent argument in that. If you chose to trust the directory, and you clicked approve, you owned the decision. But read it again as a buyer, because it is an unusually honest statement of where the responsibility sits: the vendor is telling you, plainly, that the safety of what the tool writes to your systems is your problem, not theirs.

That is the whole case for named senior-engineer accountability in a single sentence. If the trust decision is yours, you want someone qualified making it, and checking what was actually done, rather than a dialog your team has learned to click through fifty times a day. No security scanner sells you that, because a scanner is a product and accountability is a person. It is why our engagements are signed off by a named senior engineer, and why a Vibe Code Audit looks at what an assistant left behind, not only at what it claimed to do.

An old problem wearing new clothes

Strip away the fact that an AI agent is holding the pen and GhostApproval is a chain any security reviewer would recognise: untrusted input from a cloned repository, a symlink that is not resolved before use, a write that escapes its intended directory, and an interface that misreports what is about to happen. We find links from that same chain when we audit software no AI has ever touched.

This is the point that gets lost in the noise about AI risk. The dangerous exposures in AI-assisted development are usually not new classes of attack. They are old classes of attack, reintroduced at speed, because the tool moves faster than the person reviewing it and because a plausible-looking dialog lowers the reader's guard. The NCSC put the principle well in its June 2026 guidance on AI-assisted development: "the risk isn't in using AI. The risk is not applying the right safeguards when the stakes are high" [7].

Where the six tools landed

Vendor responses ranged from a prompt fix to a flat rejection. The table below is the state as reported at the July 2026 disclosure. Treat any "in progress" status as a prompt to check the vendor's current release notes before you rely on it.

Tool	Vendor response	Fix status at disclosure
Amazon Q Developer	Patched	Fixed in Language Servers for AWS v1.69.0, CVE-2026-12958 [1][5]
Cursor	Patched	Fixed in Cursor 3.0, CVE-2026-50549 [1]
Google Antigravity	Patched	Fixed [1]
Claude Code	Rejected as outside its threat model	No fix; symlink warnings shipped earlier as hardening [1][2]
Augment	Acknowledged	Fix in progress at disclosure [1]
Windsurf	Acknowledged	Fix in progress at disclosure [1]

Amazon's fix is documented in the AWS security bulletin, which describes "a missing symlink-validation issue in Language Servers for AWS before version 1.69.0" that triggers when "a local user opens a workspace with a maliciously crafted symlink that resolves to a file path outside the workspace trust boundary" [5]. The Cursor record, CVE-2026-50549, covers the underlying symlink and path-canonicalisation escape and was addressed in Cursor 3.0 [1].

The tools still cannot be trusted unsupervised, and the numbers say so

GhostApproval is a sharp example of a duller, larger truth: AI coding assistants produce insecure output often enough that unreviewed acceptance is not a defensible position.

Veracode's July 2026 GenAI Code Security Report found the security pass rate of AI-generated code essentially flat year on year, at 56%, up from 55% a year earlier, despite rapid gains in everything else the models do. Its summary is blunt: "Syntax is effectively solved. But secure coding is not following the same curve" [8]. Its October 2025 analysis, across more than a hundred models and four languages, had already found AI-generated code introducing an OWASP Top 10 flaw in 45% of tests [9]. Two years of model progress, and the security line barely moved.

The standards bodies have named the underlying design problem. OWASP's Top 10 for LLM Applications files it under Excessive Agency, which it traces to excessive functionality, excessive permissions, and excessive autonomy, where "systems fail to independently verify and approve high-impact actions" [6]. Its recommended control is exactly the one GhostApproval defeated, and it is worth quoting because it is the bar these tools should be held to: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken" [6]. An approval dialog that fires after the write, or that names the wrong file, is not that control. It is the shape of the control without the substance.

In our own audits of AI-built software, file-access and credential-exposure findings of this kind are a recurring theme, not a rare one. The tools are a genuine accelerant for good engineers. They are not a substitute for the review step, and GhostApproval is a precise illustration of why.

What to check this week

None of the following requires you to stop using AI coding assistants. Each is a control that GhostApproval, or the pattern behind it, defeated.

1. Update every assistant to its patched release. For the tools that fixed this, the fix is only in the current version. Amazon Q users need Language Servers for AWS 1.69.0 or later [5], and Cursor users need 3.0 or later [1]. Check the others against their release notes rather than assuming.
2. Treat a cloned repository as untrusted input. Do not point an assistant at an unfamiliar repository on a machine that holds real credentials. The attack begins with a symlink in code you did not write.
3. Read the diff, not the dialog. The approval prompt can be wrong about what it is approving. What actually changed on disk cannot be. Review the real diff, and be suspicious of any write to a path outside the project.
4. Reduce what a mistaken write can reach. Keep SSH keys, cloud credentials and tokens off the machines where assistants run with broad file access, or scope the assistant's access so a stray write cannot touch them.
5. Rotate anything that could have been exposed. If an assistant has been running against unknown repositories on a developer machine, treat the keys on that machine as potentially touched and rotate them.

This is the same discipline as securing software you built or inherited, and it sits alongside the wider question of whether AI-generated code is safe to ship. The novelty in GhostApproval is only the tool. The failure is one senior engineers have been catching for thirty years.

Frequently asked questions

What is GhostApproval?

GhostApproval is a security flaw pattern, disclosed by Wiz Research on 8 July 2026, affecting six major AI coding assistants. A malicious repository can use a symbolic link to make the assistant write to a file outside the project, such as your SSH keys, while the approval dialog shows a harmless-looking filename. It combines symlink following and interface misrepresentation [1].

Are AI coding assistants safe to use?

They are useful and widely used, but not safe to run unsupervised. Independent testing shows AI-generated code introduces security flaws in a large share of cases [9], and GhostApproval showed the approval prompts you rely on can be misleading [1]. Use them with a senior engineer reviewing what they produce and what they change on disk.

Can Cursor or Claude Code write to files outside the project?

Under GhostApproval, yes. A crafted symbolic link could redirect a write outside the workspace while the approval dialog named an in-project file [1]. Cursor patched this in version 3.0 [1]. Anthropic declined to treat the Claude Code case as a vulnerability, arguing that a user who trusts the directory and approves the prompt is acting outside its threat model [1].

Do AI coding tools introduce security vulnerabilities?

Frequently. Veracode's testing found AI-generated code introducing an OWASP Top 10 vulnerability in 45% of tests in 2025, and a security pass rate still near 56% in 2026 [8][9]. The tools accelerate delivery, but they do not reliably produce secure code, which is why unreviewed acceptance is a risk rather than a shortcut.

Should we stop letting our team use AI coding assistants?

No, but you should stop treating the approval dialog as sufficient oversight. Update to patched versions, keep credentials off machines where assistants have broad file access, and put a senior review step in front of anything these tools produce for software you ship. The goal is supervised use, not a ban.

Get a senior read on what your tools are actually doing

GhostApproval is uncomfortable because the control it defeated is one most teams believe they already have. If AI coding assistants are writing code that reaches your customers, the safe position is neither blind trust in an approval prompt nor a blanket ban. It is a named senior engineer checking what was built and what it touches. Our Vibe Code Audit is a bounded, fixed-price review that does exactly that, and our ongoing support keeps senior engineers on the systems you depend on. Book an audit.

Sources

1. Wiz Research, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 8 July 2026. https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
2. The Hacker News, "GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents", 9 July 2026. https://thehackernews.com/2026/07/ghostapproval-symlink-flaws-could-let.html
3. Infosecurity Magazine, "GhostApproval Flaw Hits Six Major AI Coding Assistants", 9 July 2026. https://www.infosecurity-magazine.com/news/ghostapproval-flaw-ai-coding/
4. SecurityWeek, "AI Coding Tools Tricked Into Hacking Developer Machine via Decades-Old Technique", 9 July 2026. https://www.securityweek.com/ai-coding-tools-tricked-into-hacking-developer-machine-via-decades-old-technique/
5. Amazon Web Services, "CVE-2026-12957 and CVE-2026-12958: Issues in Language Servers for AWS and Amazon Q Developer plugins", AWS Security Bulletin, accessed 27 August 2026. https://aws.amazon.com/security/security-bulletins/2026-047-aws/
6. OWASP GenAI Security Project, "LLM06 Excessive Agency", OWASP Top 10 for LLM Applications, accessed 27 August 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
7. National Cyber Security Centre, "The 'vibe coding spectrum' approach to AI-assisted software development", 18 June 2026. https://www.ncsc.gov.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development
8. Veracode, "2026 GenAI Code Security Report", 28 July 2026. https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/
9. Veracode, "2025 GenAI Code Security Report", October 2025. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/