Hidden GitHub issue text: Radware finds 47 attacks on AI agents, 61 repos hit in an hour

Hidden text in GitHub issues, pull requests and comments is now a tool attackers use against the bots and AI agents that read them. Radware researchers Gabi Nakibly and Zvika Babo scanned about 145 million GitHub items and found 47 attacks aimed at AI agents. The Register separately reports, citing Radware, a one-hour campaign on 1 September that planted hidden commands in 83 items across 61 public repositories, including well-known projects such as Trivy, MLflow and discord.js. If your repositories run automation on issues or pull requests, this is a good week to check what that automation reads and what secrets it can reach.

Key points

• Radware's public dataset covers about 145 million GitHub items and lists 2,281 AI-directed hidden-text findings in issues, pull requests and comments, of which 47 are attacks on AI agents (43 in issues, PRs and comments, 4 in READMEs).
• More than half of the attacks target a project's own triage, review or CI agent, according to Radware's repository.
• The Register reports 83 items with a verified payload across 61 public repositories as of 13 October, 77 of them posted in a 43-minute window on 1 September, using 74 GitHub accounts.
• The campaign hid commands in HTML comments, which do not show on the rendered page, and aimed to send environment variables from the CI environment to an attacker's server.
• Radware says it cannot confirm whether the attacker gained write access, changed source code or compromised downstream software.

What to do

• Find workflows that react to outside content. Look for workflows triggered by issues, issue_comment, pull_request or pull_request_target that use the title, body or comment text.
• Never paste outside text into a shell. The Register's description of the campaign is that a workflow inserted attacker content into shell source code, and the shell ran it. Pass such text through an environment variable or an input and treat it as data.
• Limit what the job can reach. Radware's advice, as The Register reports it, is least-privilege workflows, separating jobs triggered by external events from jobs with elevated permissions, and limiting the secrets and environment variables a workflow can see. The Cloud Security Alliance's May 2026 note adds explicit minimum permissions on every workflow and pinning third-party Actions to full commit SHAs.
• Do not let a bot obey a marker without checking who wrote it. Radware's repository warns that anyone can type the same marker in a public thread.
• Scan your own repositories. Radware publishes a detector, ipi-scan, for hidden text in your own projects. If you find an attack in someone else's project, report it privately to the maintainers.

What happened

Radware's researchers crawled issues and pull requests created between 1 June and 30 September 2026 (95.1 million items), added 47.6 million issues, PRs and comments from the GH Archive dataset covering September 2025 to May 2026 (plus comments from June to August 2026), and read the READMEs of the two million most-starred repositories. They looked for text a human reader would not see but an AI agent would, for example inside HTML comments.

They report 2,281 hidden-text findings that are directed at AI, about 16 per million items. Most are harmless or even helpful: 1,519 are first-party instructions across 178 projects, where a project leaves guidance for its own agents. Another 374 try to override how content is described and 345 are defensive. Forty-seven are attacks on agents. First-party findings rose from 7.0 to 15.4 per million new issues and PRs between June and September 2026.

First-party instructions1519

Content overrides374

Defensive345

Attacks on AI agents47

Hidden-text findings in GitHub items, by category (as listed by Radware; categories may not sum exactly to the total) (findings)

	findings
First-party instructions	1519
Content overrides	374
Defensive	345
Attacks on AI agents	47

Source: Radware, github-ipi-in-the-wild repository

Separately, The Register's 29 October report describes a campaign Radware found while investigating prompt injection in GitHub. As of 13 October, Radware had identified 83 items with a verified payload across 61 repositories. Seventy-seven were published in 43 minutes on 1 September and the other six in the following two minutes. The attacker used 74 GitHub accounts, many with apparently legitimate histories, which Radware believes were compromised, and Radware suspects one individual. The Register lists projects it says were targeted, among them aquasecurity/trivy, mlflow/mlflow, discordjs/discord.js, cilium/cilium, brave/brave-browser, dotnet/maui, Homebrew/homebrew-cask, github/docs and apache/doris.

Each payload hid a command in an HTML comment in an issue, pull request or comment. When a vulnerable workflow ran, it put that text into shell source, the shell executed it, and the command collected environment variables and tried to send them to a server the attacker controlled. Radware found two cases whose logs show the command ran inside the automation environment. Most affected repositories have since been closed or fixed after disclosure, but Radware cannot confirm that all were.

We could not find the 61-repository figures in Radware's public repository, which describes the wider scan rather than this campaign; they come from The Register's report, so treat them as reported, not independently confirmed.

Background

The weakness is old: workflows that build shell commands from untrusted text have been a known injection route in CI for years. What changed in 2026 is the number of agents that read issues and pull requests and hold credentials. The Cloud Security Alliance's AI Safety Initiative described the pattern in a note dated 3 May 2026: AI agents in GitHub Actions process pull request titles, issue bodies, code comments, branch names and commit messages, while holding repository write access and pipeline secrets. An attacker embeds instructions, the agent follows them, and secrets such as API keys or a GITHUB_TOKEN end up in public comments or logs. The note cites April 2026 "Comment and Control" research on three tools and Aikido Security's PromptPwnd research, and says filing a public issue was enough in the PromptPwnd case.

We covered a nearby risk in GitHub Agentic Workflows going generally available, where agents run inside Actions.

How it works

A GitHub issue is Markdown. Markdown allows HTML comments, which the web page does not display, so a maintainer sees an ordinary bug report while a script or model reading the raw text sees more. That gap is the whole trick, and it works against two kinds of reader:

1. A shell step. If a workflow interpolates ${{ github.event.issue.body }} straight into a run: script, hidden text becomes commands. This is the route The Register describes.
2. An AI agent. If an agent reads the same raw body as part of its prompt, hidden text becomes instructions. Radware's repository notes that GitHub's Copilot cloud agent strips HTML comments before its model sees them, so this kind of hidden text cannot reach that agent.

In both cases the attacker needs no access to the repository. Radware says any GitHub user could try it, and a GitHub event can start a vulnerable workflow within about a second.

What it means

For maintainers, the lesson is to audit automation, not just code. A workflow that reads a title or comment is an input parser and needs the same care as one.

For teams adopting AI triage and review bots, the lesson is to separate reading from acting. The CSA note recommends separating the agent's decision-making from the execution layer that holds credentials, so secrets are only available in downstream jobs after output is reviewed.

For everyone who installs open-source packages, the risk is indirect: a stolen CI token can become a poisoned release. Radware suspects credential theft leading to a supply chain attack was the goal, but it has not confirmed any downstream compromise.

What we don't know yet

• Whether any of the 61 repositories lost a token, had code changed or shipped a bad release. Radware cannot confirm it.
• Who is behind the 74 accounts, and whether the accounts really were compromised, which is Radware's belief.
• How many of the targeted workflows were vulnerable rather than merely probed. Radware found two cases with log evidence.
• Whether the 61-repository campaign is part of the 47 attacks in the dataset; the public repository does not say.

What to watch next

Watch for maintainers of the named projects publishing post-incident notes, for GitHub tightening how workflows receive untrusted text, and for Radware publishing a full write-up of the 1 September campaign with indicators. The attack rate in Radware's data is rising, so expect more.

Sources

• Radware: github-ipi-in-the-wild (dataset, detector and taxonomy) (primary source)
• The Register: Attackers turn GitHub issues into supply chain campaign against 61 public repos in less than an hour
• CybrSecMedia: Who Is Prompt-Injecting Coding Agents? A Scan of 86 Million GitHub Items
• Cloud Security Alliance: Prompt Injection in AI-Powered GitHub Actions