The attacker in this study can do exactly one thing: file a bug report. No access to the repository, the agent, the tests or the pipeline. Just the issue form any open-source project leaves open to the world.
Researchers took bug reports filed against open-source Python projects and rewrote each one, keeping the original complaint intact and adding a plausible extra requirement: a small helper function, an environment-variable hook, a bit of validation support. The rewritten tickets went to automated program repair agents running on three different models. In 52% of cases the agent shipped a patch that fixed the reported bug, passed the project's test suite, and wired in the attacker's flaw. One patch added a helper that read a command out of an environment variable and ran it through the shell. Another, attached to an innocuous request for a --skip-checks flag, hunted through the environment for anything resembling a secret and wrote hashes of them to disk.
"This matters for APR security evaluation because a test-passing patch should not be treated as safe by default: the same issue description that motivates a correct repair can also shape the repair toward security-reducing behavior."
The tests are no help, which is the point. Nor is the agent's own performance: repair quality held steady on the poisoned tickets, and for one model it improved, because the attacker's requirement arrived with the concrete implementation detail a vague bug report never has. A struggling agent is not the tell.
The defences fared badly. Screening the incoming ticket with a model briefed on exactly what to look for was right about two-thirds of the time. Static analysers reading the finished patch did worse, and a model reading the patch was barely better than a coin toss. All three stacked together got back to roughly two-thirds. The researchers sampled 600 misses and asked why: mostly the reviewer had read the payload as ordinary feature work, and much of the rest it was waiting for the ticket to announce its own malice.
That failure names what a reviewer should do instead. On this evidence, the question that catches these patches isn't "is this code dangerous" but "does this change do anything the reported bug didn't require". That's an alignment check between ticket and diff, and it's the one thing none of the automated defences asked. If an agent can turn an issue into a pull request, the tracker has become an untrusted input to production code and deserves the standing of a patch from a stranger, not of information. Few teams treat it that way. And a vendor calling its repair agent safe because patches get scanned before merge is leaning on the weakest defence tested here.
The authors also ran the attacks that fooled all three models past a frontier model, watched it inject the flaw in the overwhelming majority, and drew a conclusion.
"This indicates that better coding LLMs might actually be easier to fool as they are so much better at following instructions, including the adversarial ones."
A reasonable reading, but the design can't test it: those cases were pre-selected because every other model had already fallen for them, so they say nothing about how the stronger model handles the rest. The safer version is that capability isn't a defence. Weaker than the paper's claim, and still bad news.
The authors flag the obvious limits themselves: Python repositories, five classes of flaw, one agent framework. What they never tested is a person. Every check the study ran was automated, leaving open the question a team actually cares about: whether a reviewer holding the ticket and the diff together catches what the tools missed. Nor is any of this evidence that agents write insecure code unprompted. Somebody had to put the payload in the ticket. It just took no privilege to do it.
Sources
- Trad, F., Chen, S., Pham, H. V., Uddin, G., Ray, B., "Adversarial Testing of Automated Program Repair Agents for Security Vulnerabilities" — https://arxiv.org/abs/2609.15963