What happened
Researchers at Radware identified at least 83 attacks against 61 public GitHub repositories, including well known projects such as Google LangExtract, Trivy, Brave browser and MLflow, in what they suspect was a coordinated campaign to run commands in CI/CD environments and steal credentials and access tokens. They shared the findings with The Register.
The campaign was fast: 77 of the malicious items appeared inside a 43 minute window on 1 September, with six more within the following two minutes. The attacker used 74 GitHub accounts, many with legitimate development histories, which the researchers say suggests those accounts were compromised rather than created for the job.
The attack chain is what makes it notable. Malicious commands were hidden inside HTML comments in issues, pull requests and comments, so the payload did not appear on the rendered page. Where a repository is configured to respond to that event, a workflow fires automatically, within about a second according to researcher Gabi Nakibly. If the workflow incorporates attacker controlled content into shell source, the hidden command runs, collects environment variables and sends them to an attacker controlled server.
The researchers found the campaign while investigating prompt injection on GitHub. Their judgement is that the goal was a supply chain attack: take repository credentials, change the code, and push the change to everyone downstream.
Why this is a GRC story
Public repositories accept untrusted input by design. An issue tracker is an open channel that anyone can post to. The moment a workflow treats it as a trigger, the repository has wired the internet into its build system, which is an architecture decision rather than a detail for whoever wrote the YAML.
Workflow authoring is a security control. The weakness is interpolation of event content into shell commands, and the mitigations are known and rarely enforced: pass event data through environment variables, scope the workflow token to the minimum, restrict which events can trigger privileged jobs, require approval for first time contributors and pin actions to a commit.
Credential exposure in CI is a data flow question. Runner environments hold registry tokens, cloud keys and signing material. A workflow that can be induced to run attacker code can be induced to send those values outward, so the control question is which secrets it can reach and whether they are usable anywhere else.
Third party trust moves downstream. Consumers rely on maintainer accounts being intact. When those credentials are stolen, release artifacts inherit the compromise and the people installing them have no practical way to tell.
What to watch
Whether Radware publishes indicators, and how GitHub responds, given that the trigger is platform behaviour rather than a bug. The internal test is a search of your workflows for event content interpolated into run steps, plus a review of which secrets reach jobs triggered by issues or comments.
Attribution: Analysis based on The Register and related public reporting. This article is original commentary, not a repost of the source material.