Threat
Attackers turn GitHub issues into supply chain campaign against 61 public repos in less than an hour
First reported theregister.com
Page published · Page updated
Earliest dated coverage: 29 Oct 2026 · First observed: 29 Oct 2026 · Latest dated coverage: 29 Oct 2026
Coverage timeline
Single-source incident — one report is available.
Why it matters
The GitHub campaign highlights how attacker-controlled repository content can threaten automated workflows and expose credentials capable of authorizing downstream code changes.
Radware researchers identified 83 attacks against 61 public GitHub repositories during an investigation into prompt injection. The suspected coordinated campaign hid malicious commands in HTML comments within issues, pull requests, and comments to target event-triggered CI/CD workflows, potentially stealing credentials and enabling supply-chain compromise. The supplied excerpt does not establish successful compromises or explain the AI-specific execution mechanism.
Summary
Radware researchers identified a suspected coordinated campaign that used public GitHub issues, pull requests, and comments to attack repository automation. As of October 13, they had verified malicious payloads in 83 GitHub items across 61 repositories. The reported posting burst was highly concentrated: 77 items appeared within 43 minutes on September 1, with the remaining six appearing within the following two minutes. Targets included Google LangExtract, Trivy, Brave browser, and MLflow, but the target list should not be read as a list of compromised software projects.[0]
The attack crossed the boundary between externally supplied repository content and executable workflow code. Commands were concealed inside HTML comments, making them invisible in the rendered GitHub page. Where an issue, pull request, or comment triggered a vulnerable workflow, attacker-controlled content was incorporated directly into shell source code. The resulting command attempted to collect environment variables and send them to attacker-controlled infrastructure.[0]
The strongest reported outcome was workflow-level command execution: researchers found two cases with supporting execution-log evidence. Credential theft, repository write access, source modification, and downstream software compromise were not confirmed. The researchers assessed that obtaining credentials for a subsequent supply-chain attack was the likely objective, rather than an established completed outcome.[0]
The campaign used 74 GitHub accounts, many with legitimate development histories that researchers considered indicative of account compromise. They suspected coordination and possibly a single operator, but no actor was named. Maintainers were notified, and most repositories were reportedly closed or fixed; remediation was not confirmed everywhere. The recommended response centers on removing unsafe handling of external content and restricting the privileges and secrets available to externally triggered workflows.[0]
Attack chain
- 1. Publish concealed payloads: An attacker posts an issue, pull request, or comment containing malicious commands inside HTML comments. The payload remains in the underlying content while being hidden from the rendered page. The researchers reported campaign activity through 74 GitHub accounts.[0]
- 2. Trigger repository automation: The GitHub event automatically starts a workflow when the repository is configured to respond to that event. The researchers emphasized that attempting this attack does not require prior compromise of the repository or access to its codebase.[0]
- 3. Execute through unsafe shell interpolation: A vulnerable workflow incorporates attacker-controlled content directly into shell source code, causing the hidden malicious command to execute. Researchers identified two cases with log evidence of execution inside the automation environment; the evidence does not establish execution across all 61 targeted repositories.[0]
- 4. Collect environment data and attempt exfiltration: The malicious command gathers environment variables and attempts to send them to an attacker-controlled server. Researchers assessed that obtaining credentials could enable subsequent repository modification, but did not confirm repository write access, source changes, or downstream compromise.[0]
Disclosure timeline
| Date | Event |
|---|---|
| September 1 | Researchers reported that 77 malicious GitHub items were published during a 43-minute interval, followed by six more within the next two minutes. The article does not explicitly state the year of this activity.[0] |
| October 13 | The researchers' inventory had reached 83 GitHub items with verified payloads across 61 repositories. The article does not explicitly state the year of this inventory cutoff.[0] |
| 2026-10-29 12:00 UTC | The Register published the findings and researcher interviews. The report stated that maintainers had been notified and that most repositories were closed or fixed, while complete remediation remained unconfirmed.[0] |
How it works
The described weakness is unsafe handling of untrusted GitHub event content inside repository workflows. When that content is incorporated directly into shell source code, attacker-supplied text can become executable commands rather than remaining data. The exploitation condition is the vulnerable workflow configuration, not merely the presence of a public repository.[0]
HTML comments provide concealment rather than the execution mechanism. They hide the malicious command from the rendered GitHub page while leaving it in content that automation may consume. A visual review of the rendered issue, pull request, or comment therefore may not expose the payload described in this campaign.[0]
Event-driven automation supplies the path from public interaction to execution. A configured workflow can start automatically after an attacker creates the relevant GitHub item, without the attacker first obtaining repository code access. Successful execution still depends on the workflow incorporating the hostile content unsafely.[0]
The payload's reported collection target was the workflow environment. It gathered environment variables and attempted outbound exfiltration, creating a potential route to credentials and access tokens exposed to the job. The available evidence establishes two executions, not successful theft of a usable credential or completion of a downstream supply-chain attack.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| GitHub repository CI/CD workflows processing external event content | Workflows that directly incorporate attacker-controlled issue, pull-request, or comment content into shell source code. Researchers identified malicious items targeting 61 public repositories, but did not establish that every targeted repository was vulnerable or compromised. No affected software-version ranges were reported. | Researchers reported notifying all targeted projects' maintainers and said most repositories were closed or fixed. They could not confirm remediation for every repository, and the article provides no version-specific patch information.[0] |
Key takeaways
- The campaign's scale is established at the level of malicious submissions: 83 verified payload-bearing items across 61 repositories. Confirmed execution was narrower, with two cases supported by workflow logs.[0]
- The critical trust boundary is between public GitHub content and executable workflow code. Concealed HTML comments and automatic event triggers made that boundary exploitable without prior repository access.[0]
- A downstream supply-chain attack was a suspected objective, not a confirmed result. The researchers could not establish repository write access, malicious source changes, or compromised downstream software.[0]
- Similar payloads, clustered timing, and common destination infrastructure support the researchers' coordination assessment. They do not establish a named actor, and the proposed single-operator explanation remains uncertain.[0]
Defensive actions
- Treat issue, pull-request, and comment content as untrusted, and prevent it from being incorporated directly into executable shell source.: Direct incorporation of attacker-controlled content is the execution mechanism described in the campaign. Payloads concealed in HTML comments still remain in the content consumed by automation.[0]
- Apply least-privilege permissions to CI/CD workflows.: The researchers assessed that the attacker sought credentials that could enable repository modification. Restricting workflow permissions limits the authority available to a command that executes through this weakness.[0]
- Separate workflows triggered by external events from jobs with elevated permissions as much as possible.: The campaign used public GitHub interactions to trigger automation without prior repository compromise. The researchers specifically recommended separating those externally triggered workflows from privileged jobs.[0]
- Limit the secrets and environment variables available to externally triggered workflows.: The malicious command collected environment variables and attempted to exfiltrate them. Reducing what the job can access directly addresses the payload's reported collection objective.[0]
- Review workflow execution logs associated with suspicious issues, pull requests, and comments to determine whether commands actually ran.: Researchers used logs from actual workflow runs to identify two executions. This distinction is important because a malicious item in a repository is not, by itself, evidence that the repository's automation was successfully exploited.[0]