“Our guess is that the final aim was a supply-chain attack in which the attacker gains credentials for the repo, and then he has the power to change the contents – the code – as he wishes,” Radware VP and researcher Gabi Nakibly told The Register.
Radware's timeline and scope of the campaign
Researchers at Radware identified a rapid, large-scale campaign that published at least 83 malicious GitHub items across 61 public repositories. Most (77) of the malicious items were published during a 43‑minute window on September 1; the remaining six were posted in the following two minutes, the team reported. As of October 13, Radware had verified payloads across those 61 repositories and disclosed findings to the projects' maintainers.
How the novel attack chain worked
Radware describes a stealthy, automated chain that begins with an attacker posting an issue, pull request, or comment containing hidden commands inside HTML comments — content that does not appear in the rendered page. A GitHub event like a pull request or issue can automatically trigger a workflow if the repository is configured to respond to that event. If that workflow is vulnerable, it can incorporate attacker-controlled content directly into shell source code and execute the hidden command.
The executed command, Radware found in actual run logs, attempts to harvest environment variables and exfiltrate them to an attacker‑controlled server. The researchers said they found two cases with evidence that the malicious command ran inside the automation environment, but they “can’t definitively say whether the attacker successfully obtained repository write permissions, modified source code, or compromised downstream software.”
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadHigh-profile targets: 61 public repositories named
The affected repositories span AI frameworks, security tools, development infrastructure, databases and other widely used open source projects. Radware listed a range of prominent projects by name and star count, including agno-agi/agno (42.7K stars), ToolJet/ToolJet (41.1K), google/langextract (38.9K), aquasecurity/trivy (38.4K), CopilotKit/CopilotKit (38K), and podman-container-tools/podman (33K).
Other named targets included QwenLM/qwen-code (28.5K), mlflow/mlflow (28.4K), discordjs/discord.js (26.8K), cilium/cilium (25.6K), brave/brave-browser (23.9K), dotnet/maui (23.3K), Homebrew/homebrew-cask (22.2K), github/docs (21K), apache/doris (16K), and PX4/PX4-Autopilot (12.8K). “These projects are used by thousands of organizations,” Radware researcher Zvika Babo said.
Radware determined the actor used 74 different GitHub accounts to post the payloads; many of those accounts displayed legitimate development histories and were likely compromised. “Considering that dozens of accounts posted the same type of payload, on the same day, within a narrow time window, and to the same infrastructure, it is reasonable to assess that the activity was coordinated,” the Radware team wrote.
Remediation steps and the researchers' advice
Radware disclosed the findings to all the projects' maintainers; most of the affected repositories were closed or fixed, although Radware cannot confirm that all were remediated. The researchers caution that the technique is easy to start — “Basically, every user with a GitHub account can try to run this attack — it's very easy to start this attack,” Babo said — and that attackers will continue to attempt similar campaigns.
Their recommendations are concrete. Radware advises applying least‑privilege access to CI/CD workflows and separating workflows triggered by external events from jobs with elevated permissions. “Developers should treat external content as untrusted, and also limit the secrets and environment variables that are available to the workflow,” Babo said. Nakibly added, “There is no way to stop the attackers from attempting. The only way is to make sure that the workflow code is resilient, and not vulnerable to such attacks.”
What this means for open-source maintainers, CI/CD teams, and organizations that use the projects
- Open-source maintainers: Review workflow triggers and closure policies for issues and pull requests, and act on the researchers' advice to restrict secrets and separate externally triggered jobs from privileged tasks; Radware has already disclosed findings to maintainers and many repos were closed or fixed.
- CI/CD and security teams: Prioritize least‑privilege configuration for automation, treat external content as untrusted, and audit workflows that interpolate user-supplied content into shell code — the observed attack chain depended on such interpolation to execute hidden commands and exfiltrate environment variables.
- Organizations that rely on affected projects: Track remediation status of the named repositories and assume that credentials are a target; Radware's assessment emphasizes that attackers were “trying to find every possible way to get inside the repos to get credentials.”
The episode is notable for its speed, breadth and the use of innocuous-looking GitHub artifacts as an execution vector. Radware's evidence shows a coordinated push to weaponize standard collaboration features and a clear intent to harvest credentials; whether the campaign achieved write access or altered downstream software remains an unresolved, consequential question for maintainers and consumers alike.
