GhostApproval: Symlink Flaw Exposes AI Coding Agents to Workspace Escape and Remote Access

A vulnerability pattern affecting six major AI coding assistants lets attackers use decades-old symlink tricks to bypass sandboxes and write to sensitive files outside the project workspace.

AI-generated illustration depicting vulnerability for the story: GhostApproval: Symlink Flaw Exposes AI Coding Agents to Workspace Escape and Remote Access

A vulnerability pattern affecting six major AI coding assistants lets attackers use decades-old symlink tricks to bypass sandboxes and write to sensitive files outside the project workspace.

Summary

  • Wiz discovered a systematic vulnerability, dubbed GhostApproval, affecting Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf.
  • An attacker plants a symlink disguised as a config file in a repository; when a developer asks the AI agent to set up the workspace, the agent writes attacker-controlled content to sensitive files such as ~/.ssh/authorized_keys.
  • Confirmation dialogs shown to users hid the true file target, rendering the human-in-the-loop safeguard ineffective.
  • Amazon, Cursor, and Google patched the flaw and issued or are pursuing CVEs; Augment and Windsurf had not patched at time of publication.
  • There is no evidence of active exploitation in the wild, but unpatched tools remain a risk for any team running AI coding agents against untrusted repositories.

An old attack surface, a new delivery mechanism

Symbolic links — files that point to another location on the filesystem rather than holding data themselves — have been a source of security headaches since the Unix era. GhostApproval, as Wiz has named this vulnerability pattern, applies that same primitive to AI coding agents. The result is a straightforward attack: an adversary creates a repository containing a symlink disguised as an ordinary config file, adds instructions in the README telling the agent to edit that file, and waits for a developer to clone the repo and ask the agent to get started.

What the attack looks like in practice

Wiz published a proof-of-concept. The attacker creates a symlink named something like project_settings.json that actually points to ~/.ssh/authorized_keys. The README instructs the agent to update that file with specific content — in the example, an attacker-controlled SSH public key. When the developer asks the agent to set up the workspace, the agent follows the instruction, writes the attacker’s key to the authorized_keys file, and the attacker gains persistent, password-less SSH access to the developer’s machine. The attack does not require the developer to do anything unusual; asking an AI agent to “set up the workspace” or “follow the README” is entirely routine behaviour.

The human-in-the-loop problem

Many of these tools display a confirmation prompt before writing to files — the idea being that a developer can review and approve each action. Wiz found that the agents recognised the symlink was pointing outside the workspace, yet the confirmation dialog showed only the apparent filename, not the actual target. The user was approving what appeared to be an edit to a local config file while the agent was about to modify a sensitive system file. As Wiz threat researcher Maor Dokhanian put it, the consent was “formally present but substantively empty.” The safety net held the form of oversight without the substance.

Claude Code’s response and the trust-boundary debate

Anthropic’s Claude Code presented the starkest example: its internal reasoning acknowledged the symlink was pointing to a sensitive file, but the prompt shown to the user asked simply whether to edit the apparent config file. Anthropic initially closed Wiz’s report as outside its threat model, reasoning that the user had confirmed they trusted the directory at session start. Following publication of the Wiz research, an Anthropic spokesperson clarified that a symlink warning in the edit and write permission dialog had shipped in version 2.1.32 on 5 February 2026, nine days before Wiz submitted its report, as part of internal security hardening. Anthropic did not confirm whether that change was related to the Wiz submission. The broader question this surfaces — whether AI tools should protect users from deceptive workspaces or whether that responsibility sits with the developer — remains genuinely contested.

Vendor responses vary considerably

Amazon classified the flaw as high-severity, issued CVE-2026-12958, and fixed it in Q Developer. Cursor issued CVE-2026-50549 and addressed the issue in its v3.0 release. Google deemed the bug critical in its Antigravity product and deployed a fix on 22 May, with CVE issuance still in progress at time of publication. Augment acknowledged the report and credited Wiz for disclosure but had not issued a patch, with a spokesperson describing the issue as a shared responsibility between developers and AI providers. Windsurf acknowledged the report but had not patched the issue and did not respond to press inquiries.

No active exploitation, but the risk is real

Wiz found no evidence that GhostApproval is being actively exploited. That said, the conditions for exploitation are not exotic: a public or shared repository, a developer using one of the affected tools, and an instruction to act on the workspace. AI coding agents are, by design, granted broad access to codebases and often to cloud credentials and environment variables. Dokhanian noted that “classic security principles — like resolving symlinks before acting on paths — cannot be overlooked as we embrace new AI architectures.”

Why it matters

AI coding agents are being integrated into developer workflows at pace, and they routinely operate with access to source code, cloud credentials, and local filesystems. GhostApproval demonstrates that the trust boundaries governing what these agents can read and write are not consistently enforced, and that the confirmation dialogs meant to give developers oversight can be subverted by design rather than by exploitation of a complex flaw. For CISOs, the immediate concern is whether development teams are running affected, unpatched versions of these tools against repositories sourced from outside the organisation. The longer-term concern is architectural: as agentic AI takes on more autonomous tasks, the security controls governing those agents need to be verified rather than assumed.

What to do now

  • Identify which AI coding agents are in use across your development teams and confirm whether they are running patched versions — specifically Q Developer, Cursor v3.0+, and current Claude Code (v2.1.173+) for the vendors that have addressed the issue.
  • Treat Augment and Windsurf as unpatched at this time and consider whether their use against untrusted or external repositories should be restricted until fixes are available.
  • Remind developers that cloning a repository and asking an AI agent to act on its instructions is not a safe operation if the repository source is untrusted — the same principle that applies to running untrusted code applies to directing an agent to act on it.
  • Review the permissions and filesystem access granted to AI coding agents in your environment; agents should operate with the minimum access necessary for the task.
  • Monitor for CVE issuance from Google regarding Antigravity and establish a process to track disclosures from AI tooling vendors, which do not always follow conventional CVE-based disclosure practices.

Sources