Command Injection Campaign Hits 61 GitHub Repos, Aiming at CI/CD Secrets

A coordinated command-injection campaign targeted 61 public GitHub repositories on September 1, 2026, using issues, pull requests, and comments to trigger code execution inside GitHub Actions workflows. Radware’s investigation identified 83 malicious items posted that day, with most activity concentrated in two rapid waves. The incident highlights how routine project discussions can become an entry point into automated build systems when workflows treat untrusted text as executable code.

How the campaign worked

Radware found attackers embedding Bash command-substitution expressions written as $() into user-controlled titles and comments. Vulnerable workflows inserted those strings directly into shell code, and Bash evaluated the embedded expressions as commands. The payloads ran env to collect environment variables, encoded the output using Base64, stripped newlines, and attempted to exfiltrate the results with curl via an HTTP POST. Every verified payload pointed to 54.205.16[.]142 on port 8443, although the connection used plain HTTP rather than HTTPS.

Scope and timeline

Researchers observed 77 malicious items within roughly 43 minutes, followed by six additional items in a second wave lasting about two minutes, for a total of 83 posts. Targets named by Radware included projects such as Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet, and PX4-Autopilot. Inclusion on the list does not mean every project was breached; the impact depended on each workflow’s permissions and environment access.

Concrete examples from repositories

In PX4/PX4-Autopilot a pull request that appeared to be a documentation correction carried the payload in its title. A title-checking workflow inserted the title into a Bash command that invoked Python; logs showed a command-substitution warning and returned content starting with GIF89a, indicating the malicious expression was processed. In Snouzy/workout-cool an issue notification workflow assigned the attacker’s title directly into a Bash variable and produced a command-substitution warning; a later attempt to forward results to Discord failed because of invalid JSON in the request body. Radware also noted signs some participating accounts may have been hijacked, including owners denying they opened malicious items.

Risk, limitations, and what was not observed

Execution inside a workflow does not automatically mean secrets were stolen. GitHub Actions secrets are not automatically exposed to every job or workflow, so successful command execution is necessary but not sufficient to confirm credential theft. Radware did not confirm stolen secrets, repository write access, source-code changes, or compromised releases in these incidents. The campaign nevertheless exposed CI/CD systems to potential credential exposure where workflows had access to sensitive environment variables.

Recommended mitigations for maintainers

Radware’s findings underscore several concrete mitigations maintainers should adopt:

• Treat untrusted input as data, not code: pass user-controlled titles and text through environment variables rather than inserting them verbatim into shell source.
• Avoid eval and similar practices that execute unchecked content.
• Limit workflow permissions and scope to the minimum necessary.
• Keep notification and other low-privilege jobs separate from workflows that can access secrets or perform privileged releases.

Teams that find evidence of execution should review which secrets were available to affected jobs, rotate any potentially exposed credentials, inspect audit logs, and investigate unexpected outbound traffic.

Broader context and takeaways

Radware’s report complements earlier incidents such as GhostAction and the tj-actions supply-chain attack, which also targeted CI/CD secrets through different vectors. The incident is a reminder that automated workflows increase the attack surface and that normal project interactions—issues, PRs, and comments—can be weaponized if pipeline code treats untrusted text as executable. Providing SOC teams with contextual alerts and integrating threat intelligence can help detect and stop incidents rapidly.