On September 1, 2026, attackers launched a coordinated campaign targeting 61 public GitHub repositories. Their goal: exploit command injection vulnerabilities in GitHub Actions workflows to exfiltrate secrets tied to continuous integration and delivery pipelines.
Radware’s analysis uncovered 83 malicious entries—issues, pull requests, and comments—aimed at these projects. The bulk of these appeared within a tight 43-minute window, followed by a smaller, secondary wave minutes later. Projects named in the attack include Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet, and PX4-Autopilot, though inclusion doesn’t confirm any breach. Security researchers found that some malicious content executed when workflows processed user-generated text—such as issue titles or comments—as shell script input without proper sanitization.
How the Attack Worked
The key exploit leveraged Bash command substitution syntax ($()), embedded within untrusted text fields. When those fields were inserted into executable shell commands in GitHub Actions, the system treated the injected content as real commands. Even wrapping titles in double quotes didn’t prevent execution in vulnerable configurations.
The payload urged the workflow to run env to dump environment variables, then Base64-encode that data, strip line breaks, and send it via HTTP POST to a remote server at 54.205.16[.]142 on port 8443. While the port suggests HTTPS, the transmission actually used HTTP—amplifying the risk. Environment variables often contain tokens, keys, or settings that provide deep access to infrastructure.
Outcomes & Risk Assessment
While malicious code was seen executing in at least two cases (in PX4-Autopilot and another project dubbed Snouzy/workout-cool), there’s no confirmation yet that secrets were successfully stolen, repositories compromised, or source code altered. In one case, wherein a pull request was disguised as a documentation correction, logs showed the injected command and subsequent output starting with “GIF89a”—an odd signature but no traceable data theft. Another incident saw an issue notification workflow inserting a malicious title directly into a Bash variable, but failure of a subsequent Discord POST (due to invalid JSON) suggests exfiltration may have been thwarted there.
Radware also noted that some attacker accounts may have been hijacked—owners denied submitting the malicious issues themselves and in some cases initiated account protection efforts.
How to Protect Your CI/CD Workflows
Security practitioners are advised to treat untrusted content—titles, comments, labels—with caution. Rather than inserting these into shell scripts or using eval, they should be passed as environment variables or handled in a way that bypasses shell execution. Workflows with elevated privileges should never automatically incorporate unvalidated user input.
If your project exhibits signs of this kind of attack—warnings in logs referencing command substitution, unexpected outbound traffic, or questionable use of secrets—it’s time to act. Rotate credentials, inspect audit logs, review any exposed secrets, and segregate notification or label-checking jobs from more sensitive workflows like those dealing with deploys or release builds.
This incident ties into earlier threats like the GhostAction credential theft and the tj-actions supply chain attacks—each pointing to the same core lesson: CI/CD systems remain a growing target for attackers looking to weaponize development pipelines.
Analysis: This GitHub attack reinforces how dangerously fragile CI/CD pipelines can be when workflows treat user input as executable code. It’s a reminder that even seemingly innocuous interactions—comment threads, issue titles—can open back doors if code doesn’t sanitize inputs. For open source and enterprise projects alike, the urgency is clear: review permissions, enforce strict handling of untrusted content, and treat every public-facing text field as potentially hazardous. Going forward, we should see stricter workflow design standards, more granular permission models, and increased transparency in how GitHub workflows handle input across projects big and small.
