Hackers Target 61 GitHub Repositories With Command Injection Attacks to Steal CI/CD Secrets

Hackers targeted 61 public GitHub repositories in a coordinated command injection campaign designed to steal data from automated development systems.

Radware researchers identified 83 malicious issues, pull requests, and comments posted on September 1, 2026, with evidence that injected commands executed inside two GitHub Actions workflows. The findings show how routine project discussions can become entry points into software build systems.

According to Radware’s investigation, 77 malicious items appeared within about 43 minutes. Six more followed in a second wave lasting roughly two minutes.

Targets included Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet, and PX4-Autopilot. Their inclusion does not mean every project was breached.

The campaign exploited workflows that placed user-controlled text directly into shell scripts. GitHub Actions can automatically respond when someone opens an issue, submits a pull request, or posts a comment. These tasks may check titles, assign labels, or send notifications.

Hackers Target 61 GitHub Repositories

Attackers placed Bash command substitution expressions, written as $(), inside that content. When a vulnerable workflow inserted the text into executable shell code, Bash treated the embedded expression as a command rather than ordinary text. Wrapping the inserted title in double quotes did not prevent execution.

The payload ran env to collect environment variables, encoded the output with Base64, removed newline characters, and used curl to attempt an HTTP POST request.

Every verified payload pointed to 54.205.16[.]142 on port 8443, with a separate collection identifier for each attempt. Despite the port number, the connection used HTTP rather than HTTPS.

The risk depended on what each job could access. Environment variables could contain service tokens, deployment credentials, or internal settings.

GitHub Actions secrets are not automatically available to every workflow, so execution alone does not establish that sensitive credentials were stolen.

In PX4-Autopilot, a pull request posing as a documentation correction carried the payload in its title. A title-checking workflow inserted that title into a Bash command invoking Python. Logs showed a command-substitution warning and returned content beginning with GIF89a, replacing the malicious expression.

In Snouzy/workout-cool, an issue notification workflow inserted the attacker’s title directly into a Bash variable assignment. A warning tied to that line confirmed command substitution. A later Discord request failed because its body contained invalid JSON, although that failure did not prove successful data theft.

Radware did not confirm stolen secrets, repository write access, source code changes, or compromised releases. Researchers also found signs that some participating accounts may have been hijacked, including one owner publicly denying opening a malicious issue.

The findings complement earlier reporting on GhostAction credential theft and the tj-actions supply chain attack. Those incidents used different routes but also put CI/CD secrets at risk.

Maintainers should pass untrusted titles through environment variables instead of inserting them into shell source, avoid eval, and limit workflow permissions.

Teams finding execution evidence should review available secrets, rotate potentially exposed credentials, inspect audit logs, and investigate unexpected outbound traffic. Keep notification jobs separate from privileged release workflows to reduce the damage an injected command could cause.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.