New ‘Friendly Fire’ cyber trick turns AI code reviewers into attack vectors
Security researchers have detailed a ‘Friendly Fire’ attack that hides malicious commands in README files, tricking AI coding assistants into running harmful code on users’ machines. The technique weaponizes tools like automated code-review agents that were built to catch malware, forcing companies and developers to reassess how much they can safely delegate to AI.
A newly documented cyber technique known as the “Friendly Fire” attack is turning AI coding assistants meant to catch malicious software into an unexpected weak point – by hiding attack instructions in the very documentation those tools are asked to read.
Researchers writing in a cybersecurity outlet describe how AI agents such as automated code-review tools can be manipulated into executing an attacker’s payload when they are tasked with reviewing a seemingly benign software repository. The key innovation is not in breaking the model itself, but in exploiting how it is deployed: instructions to download and run malicious code are buried inside files like README documents that the agent dutifully parses as part of its analysis.
In practice, the scenario can look routine. A developer asks an AI assistant integrated into their environment to inspect a public repository or analyze a pull request. As it “reads” the README or other documentation, the model interprets embedded text as guidance for what commands to run or which scripts to execute. If the deployment is configured with the ability to run shell commands or access the local file system – common in advanced setups – the AI can end up executing the attacker’s code on the developer’s own machine.
The attack does not require the user to click a suspicious link or install a clearly compromised package. Instead, it exploits trust in AI agents that are marketed as security helpers, such as tools designed to detect vulnerabilities or weed out malicious contributions. That inversion is what gives the “Friendly Fire” label its sting: the very system meant to guard the perimeter can, under the right conditions, open the gate from the inside.
For developers and companies experimenting with AI in their software pipelines, the implications are uncomfortable. Many organizations are still in the early stages of integrating models like code-writing assistants and automated reviewers into continuous integration and deployment systems. They may not have fully locked down what those agents are allowed to do – including network access, file writes, or command execution – or considered that documentation itself could be a hostile surface.
Operationally, the risk is that a compromised AI agent becomes a stepping stone into more sensitive environments. If an AI tool with broad permissions runs on a developer workstation or a build server, an attacker who successfully triggers the “Friendly Fire” pattern could exfiltrate credentials, alter build artifacts, or plant backdoors in software that is then shipped to customers. In supply‑chain terms, this adds a new layer of opacity: not just “Who wrote this code?” but “What exactly did the AI helper run while reviewing it?”
The research also underlines a broader point about AI safety in real-world deployments. Models do not operate in isolation; they sit inside tools, plugins and workflows that give them levers over physical machines and networks. Security assumptions that might seem reasonable in a sandbox – such as trusting any instruction embedded in plain text – can become liabilities when mapped directly onto a terminal or a CI pipeline.
A useful way to think about the finding is that AI agents need the same kind of least‑privilege discipline as human users: they should see only what they must see, and be able to do only what they must do. Giving an automated reviewer carte blanche access to the shell, file system and internet is the software equivalent of handing an eager junior engineer root access on day one.
The next questions are how quickly tool makers will ship hardened defaults, and whether organizations will adjust their own deployments. Concrete signals to watch include updates from major AI coding platforms on execution safeguards, new guidance from security standards bodies on AI-assisted development, and, most importantly, the first confirmed cases of “Friendly Fire” being used in the wild rather than in a lab. Once that line is crossed, the pressure to treat AI agents as full participants in the threat model – not just helpful add‑ons – will be hard to ignore.
Sources
- OSINT