New ‘Friendly Fire’ exploit turns AI code reviewers into attack vectors
Security researchers have disclosed a ‘Friendly Fire’ attack that hides malicious instructions in code repository READMEs, tricking AI-based code review agents into running harmful payloads on developers’ machines. The flaw turns tools meant to catch vulnerabilities into a new software supply-chain risk.
A newly disclosed exploit is turning one of software development’s newest safety nets into a potential attack vector, raising uncomfortable questions about how much trust to place in AI-powered coding assistants.
Security researchers have detailed what they call a "Friendly Fire" attack against AI agents designed to review and secure code, including systems like autonomous code reviewers and assistants integrated into developer workflows. The technique plants malicious instructions not in the code itself, but in the documentation around it—specifically, in a project’s README file or other natural-language artifacts.
When a developer asks an AI agent to audit a repository, the system dutifully reads the README as context. Hidden in that text can be carefully crafted instructions telling the agent to execute a payload, such as running a script or command that compromises the host machine. Because the agent is typically granted the same permissions as the developer’s tools, those commands can do real damage: exfiltrate credentials, alter code, plant backdoors or pivot deeper into the corporate network.
For developers and security teams, the danger is that this turns a routine task—"review this code"—into a potential breach point, without the usual red flags that accompany suspicious binaries or obfuscated source. In many organizations, AI agents are being piloted or deployed precisely to reduce human error, catch insecure patterns and offload repetitive checks. A compromised agent in that role amounts to a trusted internal insider following an attacker’s script.
Operationally, the exploit expands the attack surface of the software supply chain. Open-source repositories, third-party libraries and internal projects all increasingly interact with AI tools that fetch, read and even execute snippets as part of their analysis. An adversary does not need to convince a human to run a rogue installer; it is enough to get their poisoned README or issue thread in front of the right AI agent with sufficient privileges.
Strategically, the "Friendly Fire" finding exposes a blind spot in how AI safety has often been framed. Many guardrails focus on preventing an AI system from answering harmful user prompts, not on defending the system from hostile input embedded in what looks like harmless documentation. That inversion—where the AI becomes the one being socially engineered—means established security assumptions no longer fully apply. It also complicates regulatory and compliance discussions, because an organization may find that its own tools, rather than its staff, were the initial point of failure.
The broader pattern echoes earlier shifts in cyber operations, where attackers moved from directly targeting hardened servers to compromising upstream suppliers, continuous integration pipelines and even developer laptops. The difference this time is that AI agents are being handed growing autonomy inside those pipelines, from writing patches to executing test suites and deployment scripts.
One line captures the stakes: as soon as you give an AI agent the keys to your build system, every README it reads becomes a possible knock on the back door.
What to watch next is how quickly AI tool providers introduce stricter execution policies, sandboxing and content filters for autonomous actions triggered by natural-language inputs; whether enterprises update their threat models to treat AI agents as privileged users needing monitoring and access control; and if attackers begin to share real-world campaigns that weaponize this technique against widely used open-source projects or popular commercial platforms.
Sources
- OSINT