This is the kind of attack that works precisely because it looks like a normal workflow.
A developer clones a new open-source project to check it out. They fire up Cursor — or Windsurf, or another AI coding tool — and ask it to "set up the workspace." The README says that will install dependencies and configure the dev environment. The AI agent shows an approval dialog: Edit project_settings.json? Developer clicks Accept. Looks fine. Routine.
Except they just wrote an attacker's SSH key into ~/.ssh/authorized_keys. The attacker now has shell access to their machine.
This is GhostApproval, disclosed by Wiz Research on July 8, 2026. It's not theoretical. Wiz tested it against six major AI coding assistants and all six fell for it. Three vendors patched it. Two acknowledged it and went quiet. The sixth disputed it was a vulnerability at all.
How it works
The technique uses symbolic links — symlinks — which have been a feature of Unix systems since the 1970s. A symlink makes one file path secretly resolve to another. You can create a file called project_settings.json that actually points to ~/.ssh/authorized_keys. Write to the symlink, you write to the target.
A malicious repo contains a file that looks like a project config but is actually a symlink pointing to your SSH authorized keys. The README instructs users to "let your AI assistant configure the workspace." The AI agent follows the symlink, and writes an attacker-controlled SSH key into the user's authorized keys file.
The approval dialog shows project_settings.json. The actual write goes to ~/.ssh/authorized_keys.
The developer sees a request to edit a config file. They click Accept. The attacker now has a persistent backdoor to their machine.
That's it. No malware download. No phishing link. No exploit kit. Clone a repo, ask your AI to set it up, click the approval button your tool shows you.
The part that makes this worse
In the most alarming case Wiz documented, the AI model had already figured out what was happening.
The agent's reasoning trace showed it noting that "project_settings.json is actually a zsh configuration file" — it had followed the symlink and identified the real target. But the approval dialog shown to the developer named only the harmless-looking symlink source. The developer clicked Accept on information that was accurate enough to look legitimate but didn't reflect what was actually being written to disk.
The AI model knew. The developer didn't. And the approval UI sided with the attacker.
This isn't a bug in one product's approval flow — it's a structural problem across the entire category. These tools were designed to be helpful, to follow instructions, to make edits. The assumption baked in is that the repository you're working in is trustworthy. When that assumption breaks, the approval dialogs don't catch it.
Where things stand
Wiz tested six tools. Here's the patch status as of the July 8 disclosure:
Patched:
- Cursor — CVE-2026-50549 issued, CVSS 9.8. Fixed in version 3.0. If you're on anything older, update now.
- Amazon Q Developer — treated as a vulnerability, shipped a fix.
- Google Antigravity — treated as a vulnerability, shipped a fix.
Unpatched:
- Windsurf — acknowledged Wiz's report, no fix released as of disclosure.
- Augment — acknowledged Wiz's report, no fix released as of disclosure.
If your team uses Cursor, check your version. If it's below 3.0, update before opening anything new.
If your team uses Windsurf or Augment, treat untrusted repo clones as a meaningful risk until a patch lands.
What's actually at stake
This isn't a niche dev-ops concern. If you have even one developer using an AI coding tool to onboard into new projects — and you probably do — this is in scope.
The attack surface is any moment where someone on your team: clones an unfamiliar repo, runs "set up the workspace" or "configure environment," and clicks through the approval dialogs without reading each file path. That's normal developer behavior.
SSH key compromise means an attacker can:
- Log into any server where that key is authorized
- Pivot to cloud environments, CI systems, production infrastructure
- Establish persistence that survives password rotations and credential audits
Shell startup file compromise (.bashrc, .zshrc) means the attacker's code runs every time the developer opens a terminal — silently, indefinitely.
For a 5–20 person team without a dedicated security person, a compromised developer machine is often an undetected problem for months.
What to do this week
Update Cursor to 3.0 or later. A CVSS score of 9.8 means Cursor itself treats this as about as severe as vulnerabilities get. If you're running Cursor, this is a mandatory update, not an optional one.
Check for unexpected SSH keys. If your team used Windsurf or Augment to initialize any unfamiliar repo recently, run:
cat ~/.ssh/authorized_keys
You should recognize every key in that file. If you don't, remove the unknown ones immediately and rotate credentials for any server that key could reach.
Check shell startup files while you're there.
cat ~/.bashrc
cat ~/.zshrc
Look for anything you didn't put there — unexpected PATH entries, curl commands, base64-encoded blobs.
Tell developers to read the actual path, not just the filename. "project_settings.json" and "~/.ssh/authorized_keys" are not the same thing. This sounds obvious. It stops being obvious when an AI tool has been showing you clean, sensible filenames all day and you've developed a habit of clicking through.
Set up monitoring on sensitive files. On Linux, inotifywait can alert when ~/.ssh/authorized_keys is modified. On macOS, File System Events can do the same. A write to that file outside of expected maintenance windows should be an immediate flag.
Apply minimumReleaseAge scrutiny to repos too. The same instinct that makes you wait before pulling fresh npm packages should apply to unfamiliar repos: if you don't know where it came from and who maintains it, don't ask your AI to run through its setup instructions.
Wiz published this to push vendors into fixing the problem. Three moved fast. The others are still thinking.
The broader issue isn't going away: AI coding tools are inheriting decades of Unix file system assumptions and not always handling the edge cases well. As these tools get more capable and more autonomous, the question of what they're actually allowed to touch — and what they show you before they touch it — matters more, not less.
Until there's a patch for the tools you use: check what your AI assistant is really writing to, not just the filename it shows you in the dialog.
If your dev team is using AI coding tools and you want to know whether your setup handles this class of risk, we can help. Usually a few hours of work to map the exposure and tighten the right defaults.