Hidden GitHub comments hit 61 repos

Attackers used GitHub issues, pull requests and comments as delivery vehicles in a coordinated campaign that targeted 61 public repositories, according to research shared with The Register by security firm Radware. The point was not vandalism in plain sight. It was to persuade automated software pipelines to run hidden commands and give up credentials.

Radware said it identified at least 83 malicious GitHub items across those repositories, with 77 of them posted within a 43-minute span on September 1 and six more in the next two minutes. The speed matters because it suggests industrialized scanning rather than a patient attempt against one project: throw the same bait at many repositories, and let weak workflow design do the rest.

Among the targeted projects were widely used open-source tools and frameworks including Google’s LangExtract, Aqua Security’s Trivy, Brave browser and MLflow, The Register reported from Radware’s findings. Other named repositories included projects tied to developer infrastructure, databases and AI software. That breadth is the uncomfortable part of this story. Open source runs through modern software like wiring behind a wall; many users never see it, but plenty of companies depend on it.

The reported technique is both simple and difficult to spot. Radware told The Register that the attacker hid shell commands inside HTML comments in issue text, pull requests or comments. Those comments do not appear in the rendered GitHub page, but a repository workflow may still ingest the raw content. If that workflow is set up to trigger on external events and carelessly inserts user-controlled text into shell code, the hidden command can run automatically.

According to The Register’s account of the research, Radware examined logs from real workflow runs and found two cases with evidence that the malicious command executed inside the automation environment. The command attempted to collect environment variables and send them to attacker-controlled infrastructure. That is a serious finding, but it is not the same as proof that source code was altered or that tainted software reached downstream users. Radware said it could not definitively confirm that the attacker gained write permissions, modified repositories or compromised distributed code.

That distinction matters because supply-chain attacks are frightening partly for what they could become. Here, what is established is narrower and still important: a large set of public repositories was probed with hidden payloads designed to exploit CI/CD workflows, and at least some of those payloads appear to have run. What remains unknown is how many repositories were actually exposed beyond execution, whether any credentials stolen were usable, and whether any maintainers or users suffered a deeper compromise.

Radware suspects one actor coordinated the campaign using 74 GitHub accounts, many of which appeared to have legitimate development histories and were likely themselves compromised, The Register reported. If that assessment is right, the attack says something bleakly practical about trust online: the account posting an issue may look ordinary because it belonged to someone ordinary first.

The researchers said they notified maintainers and that most affected repositories were closed or fixed, though not all responses could be confirmed. Their advice was familiar because the weakness is familiar: treat all external content as untrusted, keep secrets out of workflows that process public input, apply least-privilege access and separate externally triggered jobs from more privileged ones.

What Radware appears to have caught is not a grand breach with a single dramatic victim, but a fast search for tiny openings in the machinery that turns public collaboration into production software. In software security, that kind of search is often enough.