A new credential-theft campaign targeting GitHub Actions should prompt maintainers to review their repositories, secrets, forks, and personal access tokens immediately. Researchers cited by The Hacker News say attackers used compromised maintainer accounts to add malicious workflow files to hundreds of repositories, with follow-on exposure reaching tens of thousands of projects through forks and downstream copies.

The key issue is not only that a workflow was added. It is that the workflow ran inside trusted CI/CD environments, where it could access repository metadata, configured secrets, source code, and git history. For software teams, that turns a single compromised GitHub account into a supply-chain incident with possible exposure of package-publishing tokens, cloud keys, AI API keys, container registry credentials, chat bot tokens, and database credentials.

What happened

According to the report, the campaign involved compromised open-source maintainer accounts that pushed workflows named security-audit.yml or github_actions_security.yml. The files appeared to be defensive checks, using names such as “Security Audit” or “GitHub Actions Security,” but their purpose was to collect credentials and send them to attacker-controlled infrastructure over plain HTTP.

Two high-profile accounts were highlighted: Takashi Kitao, author of the Pyxel game engine, and Henry Wu, associated with Uber’s athenadriver. Researchers said the same malicious workflow was pushed across hundreds of repositories in a short window. Socket also reported that more than 500 GitHub accounts had committed the malicious workflow to tens of thousands of repositories since October 7, 2026.

The activity has been linked to GhostAction, a broader supply-chain campaign previously reported in 2025 and again in 2026. Earlier waves reportedly targeted hundreds of repositories and thousands of secrets, including PyPI, npm, DockerHub, GitHub, GitLab, cloud provider, and AI service tokens.

Why this is dangerous

GitHub Actions is powerful because it automates builds, tests, releases, container publishing, deployments, and security checks. That same power makes it dangerous when an attacker can write or modify workflow files.

A malicious workflow can run during pushes or manual dispatch events. If it uses a full checkout with git history, it can search not only current files but also previously committed material that developers may believe was removed. Deleted secrets can still exist in repository history unless history has been rewritten and all copies have been cleaned.

The reported workflow searched for several credential patterns, collected named GitHub Actions secrets discovered during reconnaissance, scanned the working tree, inspected git history, and attempted to pair AWS access key IDs with matching secret access keys. That means affected projects should not limit their response to the current repository files. Historical commits, forks, mirrors, and CI logs may all matter.

Forks are a particular concern. If a fork inherits a malicious workflow and Actions are enabled, later pushes can trigger the same harvesting behavior. Private forks and private mirrors may carry more sensitive material than public upstream repositories, especially where teams keep deployment configuration, internal service tokens, or environment-specific credentials.

Immediate checks for maintainers

Maintainers should search all repositories for workflow files named security-audit.yml and github_actions_security.yml, especially under .github/workflows/. Any unexpected workflow with broad triggers, full-history checkout, suspicious shell scripts, credential-pattern scanning, or outbound curl calls should be treated as hostile until proven otherwise.

A practical first pass:

- Review recent commits to .github/workflows/ since August 31, 2026.
- Check whether any unfamiliar workflow was committed by a maintainer account at unusual times.
- Inspect workflow triggers such as push, workflow_dispatch, wildcard branch/tag filters, and full-depth checkouts.
- Look for outbound network calls to unknown IP addresses or domains.
- Review GitHub Actions run history for unexpected jobs.
- Check forks and mirrors, not only the main upstream repository.
- Confirm whether repository secrets, organization secrets, and environment secrets were available to the workflow.

If a suspicious workflow is found, assume credentials may have been exposed. Deleting the workflow is necessary, but it is not sufficient.

Incident response steps

Start by disabling or deleting the malicious workflow from every affected branch and fork you control. Then revoke the GitHub credential that allowed the workflow to be committed. In many cases, that may be a personal access token from a maintainer machine, browser session, or leaked credential store.

Next, rotate every secret that could have been reached. This includes GitHub Actions secrets, package registry tokens, cloud keys, deployment credentials, SSH keys, database passwords, webhook tokens, and API keys for AI or SaaS services. If the workflow scanned git history, rotate secrets that ever appeared in the repository, not just secrets that exist today.

Teams should also audit downstream effects. Check package registries for unexpected releases, container registries for unexpected images, cloud accounts for new users or access keys, and CI/CD logs for unusual deployments. The report notes that no malicious package releases had been observed at the time of writing, but absence of public evidence is not a reason to skip verification.

How to reduce future exposure

This campaign reinforces several CI/CD security basics. Require phishing-resistant multi-factor authentication for maintainers. Prefer fine-grained, short-lived tokens over broad personal access tokens. Limit GitHub Actions permissions with explicit permissions: blocks. Use protected branches and require review for workflow changes. Restrict who can modify Actions workflows. Consider security tooling that alerts on risky workflow behavior, such as full-history secret scanning combined with outbound exfiltration commands.

Most importantly, treat workflow files as production infrastructure. A change to .github/workflows/ can be as sensitive as a change to deployment code or cloud IAM policy.

Source: The Hacker News source