What the GitHub Actions issue-injection campaign means

Researchers at Radware found at least 83 malicious GitHub issues, pull requests and comments posted to 61 public repositories, most of them within a 43-minute window on September 1, according to The Register. Each post hid a shell command inside an HTML comment and was aimed at the automation that the post would set off. The detail that decides whether you are exposed is narrow. The attack only works where a workflow inserts attacker-controlled text directly into shell code. So the question for you is how your own workflow files are written.

The background you need

GitHub Actions is GitHub’s built-in automation system. A workflow is a YAML file stored in the repository’s .github/workflows folder. It says when to run (the trigger) and what to do. Triggers can be pushes and releases. They can also be events that outsiders create: someone opens an issue, opens a pull request, or leaves a comment. When a trigger fires, GitHub starts a temporary machine called a runner and executes the workflow’s steps there. Many of those steps are plain shell scripts.

Workflows often need details about the event that started them, such as an issue title or a comment body. GitHub provides expressions for this, written like ${{ github.event.issue.title }}. The important point: GitHub substitutes the value into the script text before the shell runs it. If that value came from a stranger, the stranger’s text is now part of your program. This class of flaw is usually called script injection. It is a close cousin of SQL injection, where user input ends up being treated as code.

An analogy: picture a robot that reads a form letter aloud and does whatever the letter says. You fill in a blank with a visitor’s name. If a visitor gives their name as Bob, and also hand me the safe keys, the robot does both. The analogy breaks in two places. Real shells have syntax rules, so a payload has to be crafted to fit them. And the attacker does not watch the robot directly. The command has to send its loot somewhere the attacker can collect it.

The loot here is environment variables. These are named values the runner makes available to the job. In CI/CD (continuous integration and delivery, the automated build-test-release pipeline), they often hold access tokens, API keys and other secrets. A token with write access to a repository is the prize in a supply chain attack. In that kind of attack, the goal is not one project. It is everyone who downloads that project’s code.

The last piece is the hiding spot. GitHub renders issues and comments as Markdown, and HTML comments do not appear on the rendered page. A maintainer reading the issue in a browser sees nothing odd. A workflow that receives the raw text gets the hidden command too.

What actually changed

Script injection in workflows is a known weakness. What is new in this report is a coordinated campaign built on it, plus the way it was run.

According to The Register, 77 of the malicious items went up in 43 minutes on September 1, and six more followed within the next two minutes. As of October 13, Radware had identified 83 items with a verified payload across 61 repositories. The targets include agno-agi/agno, ToolJet, google/langextract, aquasecurity/trivy, CopilotKit, podman, mlflow, discord.js, cilium, brave/brave-browser, dotnet/maui, Homebrew/homebrew-cask and github/docs, among others.

The attack needed almost no effort after posting. As Radware’s Gabi Nakibly put it: “The workflow automatically is triggered within a second, and if the workflow is indeed vulnerable, then the attack is executed successfully.” The hidden command collected environment variables and tried to send them to an attacker-controlled server.

The posts came from 74 different GitHub accounts. Radware says many had legitimate development histories, which the researchers say means those accounts were likely compromised. They suspect a single individual is behind the campaign. They did not name anyone.

The researchers found the campaign while studying prompt injection on GitHub, which means hiding instructions for an AI model inside content it reads. The payloads described in this report target the shell, not an AI model.

On results, the report is cautious. Radware examined logs from real workflow runs and found two cases with evidence that the malicious command ran inside the automation environment. The researchers cannot say definitively whether the attacker got repository write permissions, changed source code, or compromised downstream software. Nakibly described the likely goal as stealing repository credentials so the attacker could change the code and push it to others, and he called that their guess.

What it means for developers and IT staff

The key lever is the workflow code, not the post. Zvika Babo of Radware said the attacker does not need access to the codebase, and that “every user with a GitHub account can try to run this attack”. You cannot stop someone from opening an issue on a public repository. You can decide what your workflow does with the text.

If you maintain repositories:

• List every workflow that runs on issue, pull request or comment events.
• In each one, look for places where event text such as titles, bodies or comments lands inside a shell step.
• Apply what the researchers recommend: least-privilege access for CI/CD workflows, and keep workflows triggered by external events as separate as possible from jobs with elevated permissions.
• Follow Babo’s advice to treat external content as untrusted and to limit the secrets and environment variables available to the workflow.
• If a suspicious item triggered one of your workflows, review that run’s logs. Treat any secret that job could reach as possibly exposed.

If you depend on the listed projects, the report does not say any of them shipped tampered code. Radware disclosed its findings to all the maintainers. Most repositories were closed or fixed, according to The Register, but the researchers cannot confirm all of them were. Watch the advisories and release notes of projects you rely on.

What we don’t know yet

• Whether anything was actually tampered with. Radware cannot say definitively whether the attacker got write access, changed code or compromised downstream software. The Register reports the researchers are trying to find out.
• What leaked in the two cases where the command ran. The report does not say which secrets were present in those runs.
• Who is behind it. Radware suspects one person but names no one.
• How the 74 accounts came to be used. Radware’s assessment is that many were likely compromised. The report does not say how, or confirm it.
• Which repositories are still unfixed. Most were closed or fixed, but not all are confirmed.
• Whether the count is complete. The figures are given as of October 13 and described as at least 83 attacks. The report does not say whether more items exist.