What Changed or What the Data Shows
On September 1, attackers executed 83 malicious GitHub issues against 61 public repositories in just 43 minutes. This campaign targeted CI/CD workflows through a new exploitation method: attackers posted issues with commands hidden in HTML comments. These triggered automated workflows to execute the malicious code and attempt credential theft.
This wasn't random testing. The coordination, timing, and infrastructure suggest a single actor using 74 different GitHub accounts. Many accounts had legitimate development histories, indicating prior compromise. Targets included popular repositories like aquasecurity/trivy (38.4K stars), mlflow/mlflow (28.4K stars), brave/brave-browser (23.9K stars), and github/docs (21K stars).
Radware's threat hunters discovered this campaign while investigating prompt injection vectors. They found evidence of malicious commands executing in automation environments, though the full impact, whether attackers gained write permissions or modified source code, remains unconfirmed.
Key Findings
Workflow triggers create automatic attack surfaces. When a repository is set to respond to external events like issues or pull requests, a GitHub event can trigger a workflow in seconds. The attacker doesn't need direct repository access. Any GitHub account holder can attempt this by posting a crafted issue.
HTML comment injection bypasses visual inspection. Malicious commands were hidden in HTML comments, invisible in rendered pages. Workflows incorporating attacker-controlled content directly into shell source code execute these hidden commands without human review.
Compromised accounts provide operational cover. The 74 accounts used weren't throwaway profiles. Many had legitimate development histories, making malicious activity harder to spot. This suggests the attacker invested in account compromise before launching the attack.
Credential theft enables downstream supply chain compromise. The malicious commands targeted environment variables to exfiltrate credentials and access tokens. Success would give attackers repository write permissions, allowing them to modify source code and push malicious changes to downstream consumers.
Separation of privilege is the primary control gap. The vulnerability exists where workflows triggered by external events have elevated permissions. Repositories that don't separate untrusted triggers from privileged jobs create a path from public issue to credential access.
What This Means for Your Team
When assessing a vendor's software development practices, evaluate whether their CI/CD configuration creates automatic attack surfaces. A vendor using GitHub Actions or similar platforms needs controls to prevent external events from triggering privileged operations.
This attack pattern changes your due diligence questions. It's not enough to ask if a vendor uses automated testing or continuous integration. You need to understand:
- Which workflow triggers accept external input (issues, pull requests, public comments)
- Whether workflows triggered by untrusted events have access to secrets or write permissions
- How the vendor treats external content in workflow execution contexts
- What monitoring exists for unusual workflow execution patterns
For vendors whose software you integrate or whose repositories you consume, this represents a supply chain risk that doesn't require a vulnerability in their code. The attack surface is in their automation configuration.
If you're using SIG Core or similar questionnaires, your CI/CD security section needs to address workflow isolation, not just build pipeline security. The question isn't "Do you use CI/CD?" but "How do you prevent untrusted events from executing privileged operations?"
Action Items by Priority
Immediate: Inventory vendor CI/CD exposure. Identify which vendors in your Critical or Important Functions classification use GitHub or similar platforms with public repositories. These vendors have the highest exposure to this attack pattern. Request documentation of their workflow trigger configurations and permission boundaries.
High: Update due diligence templates. Add specific questions about CI/CD workflow isolation:
- Do workflows triggered by external events (issues, PRs, comments) have access to repository secrets?
- Are privileged operations (deployments, releases, credential access) separated from workflows accepting untrusted input?
- What controls prevent execution of attacker-controlled content in shell contexts?
High: Require least-privilege workflow architecture. For new vendor assessments and contract renewals, establish that CI/CD workflows must implement least-privilege access. Workflows triggered by external events should not have elevated permissions. Jobs requiring secrets or write access should only trigger from protected branches or authorized maintainer actions.
Medium: Establish monitoring requirements. Vendors should treat external content as untrusted and monitor for unusual workflow execution patterns. This includes tracking workflow runs triggered by new or low-activity accounts, workflows that fail after attempting network connections, and sudden spikes in workflow executions.
Medium: Review your own CI/CD configurations. If your organization maintains public repositories, audit your GitHub Actions (or equivalent) for this vulnerability pattern. Look for workflows that use pull_request_target, issue_comment, or similar triggers and have access to secrets or write permissions.
Ongoing: Update contract language. Your Right to Audit provisions should explicitly include CI/CD configuration review. Your vendor security requirements should reference secure CI/CD architecture, not just secure coding practices.
