GhostApproval: A 40-Year-Old Unix Trick Just Broke the Security Model of Every AI Coding Assistant

On July 8, 2026, Wiz Research published GhostApproval — a vulnerability that breaks the security model of AI coding assistants using a technique first documented in 1983. The attack: symlinks. The result: an AI assistant asks permission to edit one harmless-looking file, but the write lands on a sensitive configuration file, an SSH key, or a production credential instead.

The exploit affects six AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. Amazon, Google, and Cursor have shipped fixes. Anthropic noted that Claude Code’s symlink protections shipped in February (Wiz).

The HN thread has one point and zero comments. The vulnerability affecting every major AI coding assistant — disclosed by one of the largest security companies in the world — is invisible to the developer community it affects most.

How It Works

The attack exploits a fundamental gap between what the AI assistant thinks it’s writing to and what it’s actually writing to. Here’s the mechanism:

1. An attacker crafts a repository with a symlink. The symlink appears to point to a harmless file in the project directory — say, docs/README.md.
2. The symlink actually resolves to a sensitive file outside the project — say, ~/.ssh/config or ~/.aws/credentials.
3. When the AI assistant prompts the developer: “Can I edit docs/README.md?” — the developer sees a harmless filename and approves.
4. The assistant writes to the symlink target, not the apparent path. The write lands on the sensitive file.

The AI assistant never knew it was being tricked. The developer never saw the real target. The confirmation dialog — the “human in the loop” that’s supposed to prevent exactly this kind of attack — was bypassed by a 40-year-old filesystem feature.

The Severity Breakdown

Wiz tested six AI coding assistants. The results varied, but none escaped:

Assistant	Read Across Symlink	Write Across Symlink	Confirmation Before Write	Status
Augment	✅ Allowed silently	✅ Allowed silently	❌ None	Worst case (Wiz)
Windsurf	⚠️ Partial	✅ Allowed	❌ After write	Wrote before dialog (Wiz)
Amazon Q	⚠️ Partial	✅ With confirmation	⚠️ Dialog bypassable	Fixed (CVE-2026-12958)
Cursor	⚠️ Partial	✅ With confirmation	⚠️ Dialog bypassable	Fixed (CVE-2026-50549)
Claude Code	❌ Blocked	✅ With confirmation	✅ Symlink warning	Protected (v2.1.32+)
Google Antigravity	⚠️ Partial	✅ With confirmation	⚠️ Dialog bypassable	Fixed

Augment was the worst case. It allowed both read and write operations across symlinks without any user confirmation. An attacker could silently exfiltrate sensitive files and modify system configuration. The assistant never asked. The developer never knew.

Windsurf had a novel failure mode. It performed file writes before presenting the approval dialog. By the time the developer saw “Can I edit this file?” — the file had already been modified. The approval dialog was retroactive.

Cursor issued CVE-2026-50549 for the flaw. Amazon Q and Google Antigravity treated it as a vulnerability and shipped fixes.

Claude Code shipped symlink warnings in version 2.1.32 on February 5, 2026 — nine days before Wiz submitted their initial report to Anthropic (The Register). When Wiz retested, Claude Code showed a clear warning dialog indicating that a symlink was being followed and the file was outside the workspace. This is the correct behavior.

Why Symlinks Are Particularly Dangerous in AI Contexts

Symlinks have been a security concern since they were introduced in 4.2BSD in 1983. The TOCTOU (time-of-check-time-of-use) vulnerability class that symlinks enable is one of the oldest in software security. So why did it take until July 2026 for someone to test this against AI coding assistants?

The answer reveals something about how AI assistants change the security model:

1. AI assistants have filesystem access that developers don’t see. When you run Claude Code or Cursor, the assistant is reading and writing files constantly — indexing the codebase, generating diffs, applying edits. The developer sees a chat interface, not a syscall trace. The assistant’s filesystem operations are invisible.

2. Confirmation dialogs create a false sense of security. The industry has converged on “human in the loop” as the primary safety mechanism for AI coding agents. The idea is that the agent asks permission before taking potentially dangerous actions, and the developer — who knows the codebase — makes the judgment call. GhostApproval shows that this model breaks when the information presented to the human is incorrect.

3. Workspace isolation is not filesystem isolation. AI coding assistants operate within a “workspace” — typically the project directory. But symlinks create paths that appear to be in the workspace while resolving outside it. The assistant’s workspace model doesn’t account for filesystem indirection.

4. AI agents trust path strings, not inode numbers. The assistant sees a path like docs/README.md and treats it as a project file. It doesn’t check whether the path is a symlink, where the symlink points, or whether the target is within the workspace boundary. This is the same class of bug that leads to path traversal vulnerabilities in web applications — applied to a desktop agent with filesystem access.

The Bigger Pattern: Trust Boundary Gaps

GhostApproval is the third major AI coding assistant vulnerability disclosed in a single week, and they all share a common theme: trust boundary gaps.

• GitLost (Jul 6): Trust boundary between public issues and private repos. The agent processes untrusted input with trusted credentials.
• Friendly Fire (Jul 8): Trust boundary between code review and code execution. The agent executes attacker code during a security review designed to prevent code execution.
• GhostApproval (Jul 8): Trust boundary between workspace model and filesystem reality. The agent trusts path strings without verifying filesystem state.

In each case, the AI agent operates across a boundary that isn’t properly enforced. The agent has credentials, filesystem access, or execution capabilities on one side of the boundary, and processes untrusted input from the other side. The boundary exists in the developer’s mental model — “the agent can only edit files in the workspace” — but not in the agent’s actual behavior.

What to Do

If you use any of the affected AI coding assistants:

1. Update immediately. Amazon Q, Cursor, and Google Antigravity have shipped fixes. Augment and Windsurf should be updated as their patches become available.

2. Verify Claude Code symlink warnings are enabled. Check that you’re running Claude Code v2.1.32 or later. When the assistant attempts to write to a symlink target outside the workspace, you should see an explicit warning.

3. Don’t open untrusted repositories with AI assistants. This was always good advice, but GhostApproval makes it urgent. A malicious repo can exploit symlinks without triggering any obvious warning in vulnerable assistants.

4. Audit your workspace for existing symlinks. If you’ve cloned repositories that other people have worked on, check for symlinks pointing outside the project directory. Attackers don’t need to be present at the time of exploitation — a symlink planted weeks ago activates the moment it’s resolved.

5. Consider filesystem-level isolation. Running AI coding assistants in containers, VMs, or with filesystem-level access controls (Landlock, seccomp, AppArmor) reduces the blast radius of symlink attacks. If the assistant can only write within a container, a symlink to /etc/passwd resolves to the container’s /etc/passwd, not the host’s.

What This Means for the Industry

GhostApproval is not a bug. It’s the consequence of a design philosophy that treats AI coding assistants as trusted actors within a workspace. Symlinks violate that trust model in a way that’s been known for 40 years but was never tested against this new class of tools.

The “human in the loop” safety model that the industry has converged on assumes the human is making informed decisions. GhostApproval shows that the information the human receives can be systematically wrong. The assistant says it’s editing README.md — the developer approves — and the actual write goes to ~/.ssh/authorized_keys.

Until AI coding assistants verify filesystem state at the inode level for every operation — not just at the path string level — this class of vulnerability will persist. And until the developer community treats untrusted repositories with the same caution they treat untrusted executables, the attack surface will remain wide open.

Wiz found the vulnerability and disclosed it responsibly. The affected vendors are shipping fixes. But the structural problem — AI agents operating across trust boundaries without verifying the ground truth — is not solved by patching symlink handling in six products. It requires rethinking what “workspace isolation” actually means when an AI agent has filesystem access.

---

If you’re running AI coding assistants in production workflows and need a security review — checking for symlink exposure, workspace isolation gaps, and credential leakage — we do that. Get in touch.

Sources: Wiz Research (Jul 8, 2026), The Register, SecurityWeek, Infosecurity Magazine, CSO Online. Vendor responses verified against Wiz’s updated disclosure.