al-ice.ai

16 per Million and Growing: Radware Counts Hidden Prompt Injections Across GitHub

Agent & Supply Chain Security by al-ice.ai Editorial

Radware researchers Gabi Nakibly and Zvika Babo presented a GitHub-scale census of indirect prompt injection at [un]prompted II in San Francisco on 27 October 2026 — moving the discussion from proof-of-concept to what is actually happening in public development workflows. The talk was billed as a scan of 86 million GitHub items; the accompanying open repository (created 26 October, updated 29 October) documents a corpus of roughly 145 million items: 95.1 million new issues and pull requests from June through September 2026, 47.6 million GH Archive issues, PRs and comments, plus the READMEs of the 2 million most-starred repositories. From that corpus came 2,281 real AI-directed findings in issues, PRs and comments — about 16 per million items — including 47 outright attacks aimed at making someone else’s agent act against its owner.

The findings split into four categories, and the split is the story. First-party orchestration dominates with 1,519 findings across 178 projects — teams leaving hidden instructions and markers for their own agents and agent tooling. Then come 374 content-override attempts (steering review language, attribution, promotion), 345 defensive markers (keeping agents out, making them identify themselves, trapping them), and 43 attacks in issues, PRs and comments plus 4 in READMEs — roughly one attack per 3.3 million items, attempting secret leaks, forged verdicts, and command execution. Three defender-facing observations from the researchers: attacks are rare but targeted — more than half aim at a project’s own triage, review or CI agent, and several name that agent’s real tools or output fields, meaning the attacker read the workflow first; most hidden text is friendly and growing fast — 75% written by project owners, members or collaborators, with per-million rates up 2.2× (7.0 to 15.4) from June to September and coordinating projects up from 11 to 69; and friendly markers are forgeable — plain text in a public thread that any bot obeying markers without checking authorship can be fooled by.

The methodology is built for reuse, which is what makes this more than a conference talk. The ipi-scan tool is open source in the same repository: it detects text a human cannot see but an agent receives (HTML comments on issues and PRs, plus invisible Unicode, white LaTeX and CSS-hidden elements in READMEs), screens it with a fast model, re-examines positives with a stronger one, and — critically — marks hidden text copied from the repo’s own issue/PR templates as template text, a filter that caught 60% of classifier-confirmed items. The prompts that classify findings are themselves hardened: hidden text is wrapped in delimiters, forged delimiters stripped, models instructed never to follow it. Every number ships with its data (per-finding JSONL, funnel and monthly tables) and a script that recomputes all of them — and every number is explicitly a lower bound, since only hidden text is counted and GH Archive now captures a fraction of GitHub activity.

Why defenders should take this seriously — and where to discount it

The serious part is that indirect prompt injection now has a measured background rate in the wild, and the trend line points the wrong way: friendly hidden markers more than doubling in a quarter means the forgeable-marker attack surface is expanding even where nobody is attacking yet. Targeted attacks naming real agent tools confirm adversaries are reading workflows before striking — the same workflow-reconnaissance pattern behind the Comment-and-Control injections, GitLost, and the March issue-title campaign that reached 4,000 machines. The discount: genuine attacks remain vanishingly rare (47 in ~145 million), most hidden text is benign or defensive, and the headline corpus size differs between the talk billing (86 million) and the repository’s current documentation (~145 million) — use the repository’s versioned numbers, which are recomputable from the published data. Also note CERT-In’s parallel warning this month that AI agents accessed live systems at Indian firms under test conditions — the census shows the delivery mechanism; CERT-In showed the consequence.

What it means for builders and defenders

  • Treat HTML comments in issues and PRs as untrusted input. They are invisible to reviewers and fully visible to agents — the exact asymmetry this census measured. Triage, review and CI agents should ignore, strip, or sandbox hidden Markdown by default.
  • Authenticate your own markers by authorship. If your agent fleet coordinates through hidden comments, check that the marker author is an owner, member, or collaborator before obeying — 75% of friendly markers are, which means 25% are not, and all of them are trivially forgeable.
  • Scan your own repositories with ipi-scan. The tool is public, runs per-repo, and needs only a GitHub token for detection mode. Run it against repos where agents review PRs or triage issues, and repeat after template changes — templates are the biggest source of lookalike noise.
  • Fix the template hygiene first. With 60% of confirmed items tracing to issue/PR template text, moving agent directives out of copy-pasted hidden comments and into authenticated configuration cuts both noise and camouflage for real injections.

Our verification was read-only. The rdwr-gabin/github-ipi-in-the-wild repository README, data-layout, tool, and findings documentation were read first-hand in full, including the corpus composition, the 2,281/47/1,519/374/345 counts, the June-to-September growth figures, the 60% template-text share, the three defender observations, and the lower-bound caveat; repository metadata (created 26 October 2026, updated 29 October) was read first-hand via the GitHub API. The [un]prompted II presentation (talk title, venue, 27 October date, 86-million-item billing, researcher names) is attributed to secondary coverage (cybrsecmedia, 27 October, read first-hand) since the slide deck itself is not public. No repository was cloned, no scan was run, no GitHub item was contacted, no researcher was contacted, and all interpretation above is ours. Brave Search was used for discovery only.

Sources: