66.5% of Malicious GitHub Issues Walked Past Every Agent Guardrail
A new benchmark hid malicious instructions inside ordinary-looking GitHub issues and pointed three production coding agents at them. Two-thirds got through — and the blocking that did happen came from the model, not the agent's safety layer.
NeuroX AI · July 29, 2026

Researchers at Concordia University built IssueTrojanBench to answer a narrow question: if you hide a malicious instruction inside a normal-looking GitHub issue, will a coding agent do it? Across 4,176 runs against Cursor, Claude Code, and Codex Desktop, 66.5% of malicious issues penetrated every guardrail the agents had — agent-level and model-level both.
The attacks weren't exotic. Four categories — supply-chain package installs, hidden shell scripts posing as validation hooks, config edits that disable the agent's own safety constraints, and process-spawn resource exhaustion — delivered six ways, including PDF attachments, image alt-text, source-code comments, and plain issue text. Ordinary developer inputs, all of them.
The finding that should change your architecture is where the refusals came from. The paper reports that rejection is almost entirely from the LLM, not the agent framework — "the current agent-level defense strategy offers limited additional protection." Bypass rates spread from roughly 41% to 85% depending on which model sat behind the agent, while the framework barely moved the number.
So the safety layer your tool advertises is mostly decoration. What actually holds is the model you chose and the boundary you built around it — sandbox, least-privilege tokens, a human on anything that touches a dependency or a config file. Treat agent input as untrusted, because a GitHub issue is a stranger's text arriving at a tool with shell access.