Two security disclosures published on July 8 expose different weaknesses in the same assumption: that an AI coding agent can safely act on untrusted code as long as a sandbox, an approval dialog, or another model remains in the loop.
Wiz Research’s GhostApproval targets the filesystem boundary. A symbolic link inside a repository redirects an apparently local edit to a sensitive file outside the workspace. AI Now Institute’s Friendly Fire targets the instruction boundary. Prompt injections hidden in an untrusted codebase persuade an agent performing a security review to execute an attacker-controlled binary.
These are not two names for the same vulnerability. One exploits path resolution and misleading authorization. The other exploits the model’s inability to reliably separate repository content from instructions. Together, they show why agent security cannot be delegated to the agent itself.
Two attacks, two failed boundaries
GhostApproval begins with a familiar Unix primitive: a symbolic link. A file that appears to live inside the project actually resolves to a path such as ~/.ssh/authorized_keys or a shell configuration file. The agent reads repository instructions, proposes a harmless-looking project edit, and follows the link when it writes.
Friendly Fire begins with a compromised or malicious repository. Documentation describes what appears to be a normal security-checking workflow. Decoy source code makes an included binary appear legitimate. When Claude Code or Codex is asked to review the repository, the injected instructions steer the agent toward running the binary as part of its own defensive task.
The critical difference is the action each attack corrupts:
- GhostApproval corrupts file authorization. The user may approve one displayed path while the agent modifies another resolved path.
- Friendly Fire corrupts task interpretation. The agent treats untrusted documentation as evidence about which command is safe and relevant to run.
- Both cross a host boundary. The dangerous result occurs because the agent can write files, launch processes, or reach credentials that matter outside the model conversation.
How GhostApproval hides the real destination
Wiz tested six major coding assistants: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The exact behavior differed, but all six followed a malicious repository path outside the intended workspace in the researchers’ tests.
In the clearest version, the repository contains a symlink named like an ordinary configuration file. Its README asks the agent to update that file. The approval surface displays the repository-relative name, while the operating system resolves the write to a sensitive destination.
Figure: The symlink redirects an apparently local edit into a developer’s SSH authorization file. Source: Wiz Research.
That distinction matters because an approval prompt is only useful when it presents the action that will actually occur. Showing project_settings.json while writing to ~/.ssh/authorized_keys is not informed consent. It turns human review into approval of a false description.
Some implementations were more severe. Wiz reported that Amazon Q Developer and Windsurf could write before presenting an undo or accept/reject control. Augment allegedly performed tested reads and writes without a confirmation prompt. In those cases, the UI was not an authorization gate at all.
The disclosure status was mixed as of July 8:
- AWS fixed its issue in language-server version 1.69.0 and assigned CVE-2026-12958.
- Cursor fixed the issue in version 3.0 and assigned CVE-2026-50549.
- Google fixed the tested Antigravity behavior in version 1.19.6.
- Wiz listed fixes for Augment and Windsurf as still in progress.
- Anthropic disputed the vulnerability classification. It told Wiz that a symlink warning had shipped in Claude Code 2.1.32 before the report; Wiz says newer versions resolve links and warn before sensitive writes.
This is why the category-level lesson is more durable than any affected-version table: every agent file operation should authorize the canonical destination, not the path string supplied by a repository.
Friendly Fire turns a security review into code execution
AI Now researchers Boyan Milanov and Heidy Khlaaf tested Claude Code in auto-mode and Codex in auto-review while the agents assessed a modified copy of the open-source geopy library. The proof of concept used repository documentation, a security-checking script, a decoy Go source file, and an attacker-controlled binary.
The documentation did not simply say “run malware.” It described the script as a normal security check. The decoy source and binary were constructed to appear related, encouraging the agent to classify the executable as part of the review workflow. The researchers reported successful execution across Claude Sonnet 4.6, Sonnet 5, Opus 4.8, and GPT-5.5 without adapting the payload for each model.
The result is especially relevant to defensive automation. A conventional scanner treats repository text as data to inspect. A coding agent also uses that text to decide what to do next. The same README can therefore be both evidence and an instruction channel.
AI Now says the attack succeeded repeatedly, but also notes that agent behavior is nondeterministic and can change with model or backend updates. The disclosure demonstrates a viable attack path under the tested configurations. It does not establish that every current invocation will execute the same sequence.
Why another model is not a complete security boundary
Auto-mode and auto-review attempt to preserve long-running autonomy by having a classifier evaluate actions that would otherwise require human approval. Friendly Fire challenges that design when the reviewer and acting agent consume the same adversarial context.
If untrusted content influences both the proposed command and the decision that the command is safe, the second model is not independent in the way a separate operating-system policy is. It may add friction and catch many obvious attacks, but it cannot provide a hard guarantee about process execution.
The same applies to human prompts. Requiring approval for every command can reduce autonomy and create prompt fatigue. More importantly, the human may still be shown an incomplete path, a plausible command, or an agent-generated explanation already shaped by malicious context.
The stronger pattern is to enforce policy below the reasoning layer.
A practical containment baseline
Teams that allow agents to inspect third-party repositories should assume that every file, issue, test fixture, dependency message, and build log can contain hostile instructions.
- Use an ephemeral environment. Run the review in a disposable VM or container that has no developer home-directory mount, SSH agent socket, browser profile, or persistent shell configuration.
- Start without secrets. Do not expose production cloud credentials, package-publishing tokens, signing keys, or broad source-control tokens. Inject narrowly scoped credentials only when a task proves it needs them.
- Resolve every path before authorization. File tools should reject writes whose canonical destination leaves the workspace. They should also block link traversal at the final operating-system call rather than relying only on a preflight string check.
- Restrict process execution. A security review should not automatically run binaries shipped by the repository. Build and test commands should execute under a separate policy with an explicit allowlist or a clean rebuild from reviewed source.
- Control network egress. Default-deny outbound connections prevent many successful code-execution attempts from becoming credential theft or remote control.
- Separate inspection from action. Let one stage map the repository and identify suspicious artifacts without executing them. A later, isolated stage can run approved tests with a fresh context and narrower permissions.
- Log resolved actions. Record canonical file destinations, child processes, network requests, and the policy decision that allowed each operation. Agent chat logs alone are not sufficient for incident response.
A lightweight repository preflight can at least reveal tracked symbolic links and executable files before an agent session begins:
git ls-files -s | awk '$1 == "120000" { print "symlink:", $4 }'
find . -type f -perm -111 -printThis is detection, not containment. A clean result does not make a repository trustworthy, and generated files or dependency installation can introduce new paths later.
The signal
Coding agents are becoming operating environments, not just code-completion interfaces. They read instructions, cross-reference files, select tools, launch processes, and modify persistent state. That makes their trust model closer to a build system or CI runner than a chatbot.
GhostApproval shows that a human approval can be meaningless when the UI hides the resolved action. Friendly Fire shows that automated approval can be captured by the same untrusted context it is supposed to evaluate.
The immediate response is to patch affected tools. The durable response is architectural: keep untrusted repository content, model reasoning, authorization policy, and host capabilities in separate trust domains.
