GhostApproval: symlink flaw lets AI coding agents write outside the sandbox — six tools affected

TL;DR — 90 seconds

Affected?

Six AI coding agents: Amazon Q Developer (<1.69.0), Cursor (<3.0), Google Antigravity (up to 1.19.6), Anthropic Claude Code (v2.1.42, report rejected as "outside threat model"), Augment (0.754.3), and Windsurf (V1.9566).

Risk?

A malicious repository contains a symlink with an innocuous-looking name (e.g. project_settings.json) that actually points to sensitive files such as ~/.ssh/authorized_keys or ~/.zshrc. The agent appears to write to the harmless file — the content actually lands at the symlink target. Approval dialogs in many tools still show the apparent path, not the actual resolved target.

Immediate action?

Update affected tools to the patched versions (Amazon Q ≥1.69.0, Cursor ≥3.0). For tools without a fix (Augment, Windsurf) or with a rejected finding (Claude Code): run agents with restricted filesystem access or in sandboxes, and scan repositories for symlinks before letting an agent touch them.

Recommendation?

No official CVSS score has been published — only qualitative ratings (Critical/High) per vendor. No confirmed active exploitation in the wild, though related patterns have already been observed in the Miasma worm.

Criticality?

high (hero badge) — affects six market-leading tools, documented credential exfiltration at at least one vendor (Augment), inconsistent patch status.

What is the problem?

On July 8, 2026, security researchers at Wiz published a vulnerability class called "GhostApproval" affecting six widely used AI coding agents: Amazon Q Developer, Cursor, Google Antigravity, Anthropic Claude Code, Augment, and Windsurf. At its core is a combination of symlink following (CWE-61) and misleading UI representation (CWE-451) — Wiz describes it as a "trust boundary gap."

The attack: a repository contains a symlink whose name looks innocuous (e.g. project_settings.json) but whose actual target is a sensitive file outside the project directory — such as ~/.ssh/authorized_keys or a shell startup file like ~/.zshrc. If the user asks the agent to edit that file (for instance, guided by a crafted README), the agent actually writes to the symlink target. Many tools' approval dialogs still display the harmless, apparent path — not the resolved, actual target path. Wiz sums up the core issue: when the confirmation dialog displays one path while the actual target lies elsewhere, user authorization no longer carries substantive meaning.

Who is affected?

In principle, anyone running one of these agents in auto-approve or reduced-approval mode against not-fully-trusted repositories is affected — for instance when cloning open-source projects, candidate take-home assignments, or external contributor branches. Severity differs markedly by vendor: at Windsurf, writes reportedly happen before an approval dialog is even shown; at Augment, symlinks are followed silently for both reads and writes, including documented credential exfiltration; at Cursor, the diff UI displayed the symlink path while the backend resolved the target without warning; at Amazon Q, writes happen before authorization with only a post-facto undo option.

Impact

The most severe documented scenario is at Augment: complete credential exfiltration through silent symlink following with no user consent at all. Across the other affected tools, impact ranges from manipulating SSH authorized_keys (a persistence mechanism for attackers) to altering shell startup files (arbitrary code execution on next login). Because the approval dialogs show the wrong path, an informed user decision is effectively impossible in the affected versions — the security promise that "the user confirms every file change" is undermined.

One caveat: per Wiz, there's no evidence of active exploitation in the wild. This disclosure is the result of targeted security research, not a response to an ongoing incident. Related patterns — malicious repository content tricking AI coding agents into unwanted actions — have, however, already been observed in the Miasma worm, which this blog covered in June 2026.

Mitigation / immediate steps

Operational decision block

• Act now if … you run Amazon Q Developer below 1.69.0 or Cursor below 3.0 — a fix exists and should be applied.
• Check with priority if … you run Augment or Windsurf (no fix available) or use Claude Code in auto-approve mode against untrusted repositories (finding rejected, only warnings since v2.1.32).
• Monitor only if … you run your coding agents exclusively against internally curated, trusted repositories with manual approval per file change.

Step 1 — update affected tools

# check Amazon Q Developer Language Server version
q --version
# check Cursor version
cursor --version

Step 2 — scan repositories for symlinks before agent use

# look for symlinks in a freshly cloned repository
find . -type l -exec ls -la {} \;
# specifically for symlinks with innocuous names pointing at home-directory files
find . -type l -exec readlink -f {} \; | grep -E "\.ssh|\.zshrc|\.bashrc|authorized_keys"

Step 3 — restrict agents instead of trusting them

# example: run the coding agent in a container without access to the host home directory
docker run --rm -it \
  -v "$(pwd)":/workspace:rw \
  --read-only --tmpfs /tmp \
  my-agent-sandbox-image

Step 4 — disable auto-approve for untrusted sources

# principle: only enable auto-approve/auto-edit modes for repositories
# whose origin and content are fully trusted.
# for external repos (contributor branches, coding challenges, third-party projects):
# review every file change manually, especially files with an
# innocuous name but an unusual diff target.

Detection / verification

Find symlinks in existing cloned repositories

find ~/projects -type l -exec readlink -f {} \; 2>/dev/null | \
  grep -E "\.ssh|authorized_keys|\.zshrc|\.bashrc|\.profile"

Check SSH authorized_keys and shell startup files for unexpected changes

# reconcile timestamps and content against a known-good state
stat ~/.ssh/authorized_keys ~/.zshrc ~/.bashrc
diff <(git show HEAD:.zshrc 2>/dev/null) ~/.zshrc

Runtime indicators

- new, unrecognized public keys in ~/.ssh/authorized_keys
- unexpected additions to shell startup files (especially execution or network calls)
- coding agent sessions with file access outside the expected project directory
- approval dialogs whose displayed path doesn't match the actual diff target

Operator guidance

Act now: Amazon Q and Cursor users update to the patched versions (1.69.0 / 3.0). Augment and Windsurf users restrict their agents' filesystem access until a fix is available.

Priority: teams running AI coding agents in auto-approve mode against external or contributor repositories — regardless of tool — set up a symlink check before every agent run and scale back automatic approval to curated, internal repositories.

Monitor: anyone running coding agents exclusively with manual approval of every file change, on internal repositories, is structurally less exposed, but should still keep an eye on their tool version, since patch status shifts quickly across all six vendors.

Conclusion

GhostApproval points to a structural problem that isn't limited to a single vendor: approval dialogs that show one path while the filesystem resolves another aren't an effective security boundary — no matter how carefully an agent otherwise handles permissions. The inconsistent patch status (two real fixes, two in progress, one rejected finding) means teams can't delegate responsibility to the tool vendor alone: repository hygiene before using coding agents, and restricted filesystem access, remain the more reliable controls.

Sources

• Wiz — GhostApproval: A Trust Boundary Gap in AI Coding Assistants (Jul 8, 2026)
• The Hacker News — GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents
• The Register — Bug in top AI coding agents shows that Unix-era security headaches never really die