Radware: malicious GitHub issues and pull requests hit 61 public repos to steal CI/CD credentials

TLDR

• Radware identified 83 malicious GitHub issues, pull requests and comments across 61 public repositories, all published on 1 September 2026.¹²
• The payloads tried to run shell commands in vulnerable CI/CD workflows and send environment variables to an attacker's server.¹²
• Radware confirmed execution in two cases but did not establish that repository write access or downstream compromise followed.¹²

The Register reports, in an exclusive, that Radware researchers identified at least 83 attacks against 61 public GitHub repositories, including Google LangExtract, Trivy, Brave browser and MLflow, in what they suspect is a coordinated campaign to execute commands in CI/CD environments and steal credentials and access tokens.¹ Radware's own post, dated 29 October, describes 83 verified malicious items across 61 distinct repositories, all published on 1 September 2026.² Both say 77 of the items appeared within about 43 minutes, and Radware puts that span between 11:26:51 and 12:10:00 UTC.¹² The sources differ on the remaining six: The Register says they followed within the next two minutes, while Radware says a second wave of six came later that day, within roughly two minutes.¹² The Register says the count was as of 13 October, so the activity dates from 1 September and was disclosed on 29 October.¹²

The Register says an attacker publishes an issue, pull request or comment containing malicious commands hidden in HTML comments, so the content is not visible in the rendered page.¹ If a repository's workflow is triggered by that event and incorporates the content directly into shell source code, the shell runs the hidden command, which collects environment variables and tries to send them to an attacker-controlled server.¹ Radware describes a payload built on $() command substitution that runs env, encodes the output and posts it with curl to an attacker-controlled server over HTTP, and says the attack can work even if the issue or pull request is never approved, never merged or is closed within minutes.² Radware adds that GitHub Actions secrets are not automatically exposed to every workflow, because availability depends on the event type, permissions and how the workflow uses them.²

Radware says it examined logs from real runs and found two prominent cases with direct evidence that the malicious command executed inside the automation environment.² It says it did not establish that the attacker obtained repository write permissions, modified source code or compromised downstream software, and that the supply chain scenario it describes is an illustration of potential consequences rather than a verified outcome.² The Register reports that researcher Gabi Nakibly believes the final aim was to gain credentials for a repository and then change its code, and that the researchers suspect a single individual used 74 GitHub accounts, many with legitimate development histories and so likely compromised.¹ Radware separately reports finding accounts with prior legitimate activity and a user who publicly said they had not created the malicious activity attributed to them and later said they had changed their password and revoked access keys.² The Register adds that the researchers disclosed the findings to all affected maintainers and that most repositories were closed or fixed, though they cannot confirm all of them were.¹

The Register quotes Nakibly: "There is no way to stop the attackers from attempting. The only way is to make sure that the workflow code is resilient, and not vulnerable to such attacks."¹ The researchers recommend least-privilege access for CI/CD workflows and separating workflows triggered by external events from jobs with elevated permissions.¹ Radware advises treating issue titles, pull request bodies and comments as untrusted data, passing them to scripts through environment variables rather than inserting them into run: blocks, and not giving a workflow permissions it has no explicit need for.²

Why it matters: the sources show that ordinary issue, pull request and comment text can reach CI/CD environments when workflows insert it into shell code, so workflow input handling and permissions are the defence they point to.¹²