GhostApproval Vulnerability Lets Malicious Repositories Bypass AI Agent Approval Prompts

A new vulnerability pattern called GhostApproval shows how malicious repositories can trick AI coding assistants into writing outside a trusted workspace, potentially leading to remote code execution on a developer’s machine.

Wiz researchers found the issue across six AI coding tools: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The GhostApproval research says the flaw abuses symbolic links and misleading approval prompts to make risky writes look harmless.

The core risk is simple. A developer clones a malicious repository, asks an AI agent to set up or modify the project, and the agent writes to what appears to be a local project file. In reality, that file can point to a sensitive location such as an SSH authorization file or shell startup script.

How GhostApproval Works

GhostApproval relies on symbolic links, also known as symlinks. A symlink is a filesystem pointer that makes one file path silently resolve to another file path.

MITRE documents this class as CWE-61, which covers unsafe following of Unix symbolic links. In this case, the old filesystem issue becomes more dangerous because an AI agent may follow project instructions and write files on the developer’s behalf.

In Wiz’s proof-of-concept, a malicious repository contains a file named project_settings.json that is actually a symlink to a sensitive file outside the workspace. When the user asks the agent to follow the README, the agent writes through the symlink and modifies the real target.

Attack step	What happens
Malicious repo created	The attacker adds a symlink disguised as a normal project file
Developer opens the repo	The user asks an AI coding agent to set up or edit the project
Agent follows instructions	The agent writes to the apparent project file
Symlink redirects the write	The actual write lands outside the workspace
Attacker gains leverage	The write can create persistence or enable remote access

Why the Approval Prompt Fails

Many AI coding assistants depend on human approval prompts as a safety layer. The assistant proposes an edit, the user sees a dialog, and the user decides whether to approve it.

GhostApproval breaks that model when the prompt shows the symlink path but hides the real destination. The user thinks they are approving a change to a local project file, while the agent writes to a sensitive file outside the project.

Wiz connects this to CWE-451, which covers user interface misrepresentation of critical information. The problem is not only that the symlink gets followed. The problem is that the approval dialog does not give the user enough information to make a safe decision.

• The agent may know the true destination internally.
• The user may only see the harmless-looking symlink name.
• The write may land outside the workspace.
• Some tools may write before a real approval decision happens.
• The safety prompt becomes an inaccurate confirmation step.

Which AI Coding Tools Were Affected

Wiz reported variations of GhostApproval to six vendors. AWS, Cursor, and Google fixed their issues before public disclosure. Augment and Windsurf acknowledged the reports but had not provided further updates by the time Wiz published its findings.

The AWS security bulletin confirms CVE-2026-12958, a missing symlink-validation issue in Language Servers for AWS before version 1.69.0. AWS says the issue affects Amazon Q Developer IDE plugins because they bundle the affected language server.

Cursor also published a separate advisory for its symlink issue. The Cursor security advisory tracks the flaw as CVE-2026-50549 and says Cursor versions before 3.0 were affected.

Vendor or tool	Severity listed by Wiz	CVE	Fixed version or status
Amazon Q Developer	High	CVE-2026-12958	Language server 1.69.0
Cursor	Critical	CVE-2026-50549	Version 3.0
Google Antigravity	Critical	Pending	Fixed in version 1.19.6
Augment	Critical	Not listed	In progress at publication
Windsurf	Critical	Not listed	In progress at publication
Claude Code	Disputed	Not listed	Anthropic disputed the report and added symlink warnings

Amazon Q and Cursor Fixes

AWS says Language Servers for AWS before 1.69.0 could follow a malicious symlink that resolves outside the workspace trust boundary. The same bulletin says both relevant AWS language-server issues are remediated in version 1.69.0.

The Amazon Q Developer bulletin says most customers receive the language-server update automatically, but users can reload the IDE to trigger the update. If auto-update is blocked, AWS recommends upgrading the Amazon Q Developer plugin for the user’s IDE.

The Cursor advisory says the flaw could allow arbitrary file writes outside the workspace under the user’s privileges. Cursor fixed the issue in version 3.0 by blocking writes when the target path cannot be resolved safely.

Claude Code, Augment, Google Antigravity, and Windsurf

Wiz says Claude Code provided the clearest example of approval-prompt misrepresentation. In testing, the agent recognized the sensitive target internally, but the user-facing dialog still showed only the apparent project file.

Anthropic disputed the report as outside its threat model, according to Wiz. Anthropic later told Wiz that a symlink warning in the Edit and Write permission dialog shipped in Claude Code v2.1.32 on February 5, 2026, before Wiz submitted its report.

Wiz says Google fixed Antigravity on May 22, 2026 and was assessing whether to issue a CVE. Augment and Windsurf acknowledged the reports, but Wiz said they had not provided further updates by public disclosure.

• Claude Code: disputed by Anthropic, with symlink warning behavior present in later versions.
• Google Antigravity: fixed before disclosure, CVE assessment pending.
• Augment: acknowledged report, no further update at publication.
• Windsurf: acknowledged report, no further update at publication.

Why This Can Lead to Remote Code Execution

The most direct proof-of-concept writes an attacker’s SSH public key to the victim’s authorized_keys file. If the victim’s machine exposes SSH in a reachable way, the attacker could gain passwordless access.

Another variant writes to a shell startup file, such as a zsh configuration file. That can cause attacker-controlled commands to run when the developer opens a terminal, even if SSH is not exposed.

MITRE’s symbolic link weakness shows why canonical path checks matter. A tool must verify where a path really points before it reads, writes, or displays that path in a security decision.

Target file	Potential impact
~/.ssh/authorized_keys	Can allow attacker-controlled SSH login if the system is reachable
~/.zshrc	Can run commands when the user opens a new shell
Agent configuration files	Can alter how future AI agent sessions behave
Credential or cloud config files	Can expose secrets or change trusted settings

What Vendors Should Change

GhostApproval shows that human-in-the-loop controls need accurate file path information. A prompt that asks users to approve a misleading path does not provide real consent.

The fix should start with canonical path resolution. Before showing a prompt, the tool should resolve symlinks and display the real target path, especially when the target exits the workspace.

Vendors should also prevent pre-authorization writes. Wiz found that some tools treated the prompt as an undo mechanism rather than a gate, which means the file had already changed before the user could reject the action.

1. Resolve symlinks before showing approval prompts.
2. Display the real target path, not only the symlink name.
3. Warn clearly when a write exits the project workspace.
4. Block writes when canonical path resolution fails.
5. Never write to disk before explicit user approval.
6. Log sensitive file access by AI agent processes.

What Developers Should Do Now

Developers should update Amazon Q Developer, Cursor, Google Antigravity, Claude Code, and other AI coding tools to the latest available versions. Teams should also restrict agent access when reviewing unfamiliar or third-party repositories.

The Wiz disclosure recommends treating this as a category-level trust-boundary issue rather than a one-off bug. That means organizations should review how every coding assistant handles symlinks, workspace boundaries, approval prompts, and pre-approval file writes.

The practical rule is to avoid giving AI agents broad write access to untrusted repositories. If an agent must inspect an unknown project, run it in a disposable container or virtual machine without SSH keys, cloud credentials, production tokens, or sensitive dotfiles.

• Update affected AI coding assistants immediately.
• Run unfamiliar repositories in isolated environments.
• Do not expose personal SSH keys or cloud credentials to agent workspaces.
• Check sensitive files after running an AI agent on an unknown repo.
• Watch for changes to SSH, shell, and AI tool configuration files.
• Disable automatic file writes where the tool allows it.

Why GhostApproval Matters for AI Security

GhostApproval highlights a larger problem with AI agents. These tools do not just read code. They interpret documentation, follow setup instructions, modify files, run commands, and sometimes act before a human fully understands the action.

That changes the security model for software development. Repository files can now serve as both project data and instructions for an autonomous tool, which gives attackers a new way to influence developer machines.

The lesson from UI misrepresentation of critical information applies directly here: approval prompts only protect users when they show the real security-relevant facts. As AI coding agents gain more autonomy, vendors need to treat filesystem trust boundaries and honest prompts as core product security features.

FAQ