Coordinated GitHub supply chain attack hid malicious commands in invisible HTML comments
Attackers exploited GitHub's automated CI/CD workflows by embedding hidden shell commands in HTML comments within issues and pull requests, targeting 61 high-profile repositories including Trivy, Brave, MLflow, and Podman in under an hour.
Summary
Radware researchers identified a novel supply chain attack campaign that compromised 74 GitHub accounts to publish 83 malicious items across 61 public repositories during a 45-minute window on September 1. The attacker exploited a weakness in GitHub's automation model by hiding malicious shell commands inside HTML comments within issues, pull requests, and comments—rendering them invisible to human reviewers while still executable by CI/CD workflows. When repositories had workflows configured to trigger on these events and incorporate external content into shell scripts, the hidden commands automatically executed within seconds, harvesting environment variables and attempting to exfiltrate credentials to attacker-controlled infrastructure.
The targeted repositories span critical open-source infrastructure including security scanner Trivy, container engine Podman, AI/ML platforms MLflow and Google's LangExtract, browser Brave, and networking project Cilium. The researchers confirmed two cases where malicious commands successfully ran in automation environments but could not verify whether the attacker achieved repository write access or downstream code compromise. The attack chain is particularly concerning because it requires no prior repository access—any GitHub account can attempt it—and leverages legitimate automation patterns that many projects rely on for contributor management.
How the HTML comment attack chain bypasses visibility controls
- HTML comment cloaking: Malicious shell commands were embedded inside
<!-- -->HTML comments, making them invisible in rendered GitHub pages while remaining present in the raw content that CI/CD systems process. - Event-driven workflow exploitation: The attacker relied on repositories having GitHub Actions or similar automation configured to trigger workflows on issue, pull request, or comment events, enabling hands-off execution within approximately one second of publication.
- Shell injection via unsanitized incorporation: Vulnerable workflows directly interpolated attacker-controlled content into shell script source code without sanitization, causing the hidden commands to execute with the workflow's privileges.
- Credential harvesting objective: The executed payloads collected environment variables—typically containing tokens, API keys, and authentication credentials—and attempted to exfiltrate them to infrastructure controlled by the attacker.
- Compromised legitimate accounts: The campaign used 74 distinct GitHub accounts, many with prior legitimate development histories, suggesting account compromise rather than newly created throwaway identities.
Why it matters
This attack vector exposes a fundamental tension in GitHub's automation model: the same workflow triggers that enable open-source collaboration also create exploitable attack surfaces when external content is incorporated without strict sanitization boundaries. Projects using issue_comment, pull_request_target, or similar event triggers with unsanitized shell interpolation are particularly at risk, and the technique's low barrier to entry means copycat campaigns are likely. For maintainers, this necessitates auditing workflow files for unsafe interpolation patterns, restricting workflow permissions to minimal scopes, and treating all externally sourced content as untrusted regardless of apparent visibility.
What to do
- Treat all external content in issues, pull requests, and comments as untrusted.
- Apply least-privilege access to CI/CD workflows.
- Separate workflows triggered by external events from jobs with elevated permissions.
- Limit the secrets and environment variables available to workflows.
Original reference: www.theregister.com →