The GhostAction GitHub attack is back, and this time it has reached Uber's open-source code. The campaign takes over developer GitHub accounts and plants malicious workflows in their repositories. By October 9, 2026, it had injected them into 790 repositories, according to GBHackers. The core activity is days old, but new counts keep arriving, and the stolen haul includes cloud keys and AI provider API keys that can spread well beyond the repository where they were found.
Where the October wave hit
The decisive bursts came on October 8. Socket and StepSecurity documented two automated injection runs, as summarized in the GBHackers coverage. The first touched 27 repositories tied to the kitao account. The second touched 318 repositories tied to the henrywoo account, 279 of them forks, and it included Uber's athenadriver repository. Cyber Security News also names the kitao/pyxel project among the affected projects.
Counts differ across reports, and the sources reviewed do not reconcile them:
- 790 repositories injected by October 9, per GBHackers.
- About 1,900 compromised accounts and more than 30,000 targeted repositories, per GitGuardian as reported by The Hacker News and PBX Science.
- More than 500 maintainer accounts compromised since October 7, per a Breached report that cites Socket data.
- 3,174 secrets the workflow tried to extract, per PBX Science.
Whether these figures overlap or describe separate waves is unclear. Treat the 30,000 number as a count of targeted repositories rather than confirmed breaches, since the reporting describes targeting, not verified theft from each one.
The campaign has a longer history. GitGuardian first documented GhostAction in September 2025, when it counted 817 repositories and at least 3,325 secrets stolen. Its later tally of a 772-repository wave, which ran from August 31 through September 30, 2026, shows the operation returning in waves rather than stopping after one burst. GitGuardian's blog tracks that history.
How the attackers take over developer accounts
The initial access route is an inference. Researchers believe the attackers used stolen personal access tokens, or credentials pulled from infostealer logs and leaked data dumps, to get into developer accounts and add a workflow file. DIESEC says that explanation is not a confirmed finding, so read it as the leading theory.
The push itself is better documented. Researchers say the malicious workflows went straight to default branches without a pull request or review. A normal review gives maintainers a chance to notice a new workflow file, so the skipped step is a central weakness in this case.
The workflow uses names that look routine: Security Audit or Github Actions Security. It runs on every push to any branch and can also be triggered manually. That means it can fire during ordinary development work, not only when someone deliberately runs it. Attribution to a specific group has not been established in the sources reviewed.
What the newer GhostAction payload steals
The newer variant goes further than the 2025 original. It searches full Git history, not only current files, and it captures data over plain HTTP to a hard-coded IP address, 193.32.204.199. DIESEC reports that the payload looks for 13 credential patterns, including AWS keys, GitHub and GitLab tokens, and Anthropic, OpenAI and OpenRouter API keys.
Each category carries a different kind of risk. A stolen cloud key can reach storage, databases and deployment systems. A GitHub or GitLab token can push code into other repositories. An AI provider key can make billed API calls under the victim's account. Any of them can become the starting point for the next intrusion.
History is the detail that changes the cleanup. A secret committed last year and deleted last month may still sit in the commit log, where the newer payload can find it. Scrubbing the current files does not remove exposure that already happened.
How GhostAction differs from the tj-actions compromise
The tj-actions/changed-files compromise poisoned a shared GitHub Action that many projects pulled into their pipelines. GhostAction works differently. According to The New Stack, it used stolen developer credentials to modify workflows directly, with no vulnerability in GitHub Actions itself.
That difference changes the defense. Patching GitHub Actions will not close this gap, because the weak point is the account. Two-factor authentication, token hygiene and stricter review rules on default branches address the actual entry point.
Trusted delivery channels remain a favored target. In a separate case, attackers hijacked AOMEI update servers to push a Windows backdoor, which shows how one compromised trust point can reach many users at once. Our AOMEI report covers that campaign.
The supply-chain risk extends past GitHub. Stolen PyPI, npm, Docker Hub or crates.io credentials could let an attacker publish a poisoned package from a trusted project, and downstream users would install it. The reporting reviewed for this story has not documented that step yet.
How to check a GitHub repo for a malicious workflow
These steps are general recommendations, not a single source's checklist. Start with the repositories you own or maintain, then extend the review to forks and linked projects.
- Open the .github/workflows folder and look for files named security-audit.yml or github_actions_security.yml.
- Check workflow display names for Security Audit or Github Actions Security, even if the file name looks different.
- Review commits from the past several weeks, especially any pushed directly to default branches without a pull request.
- Look for outbound traffic to 193.32.204.199 in firewall, proxy and CI runner logs.
- Review organization audit logs for token or session activity you do not recognize.
Rotate GitHub secrets after a supply chain attack
Rotate every secret that may have been exposed. That includes credentials committed in the past and later deleted, because the newer payload searches history. Prioritize cloud keys, package-registry tokens for PyPI, npm, Docker Hub and crates.io, and AI provider keys from Anthropic, OpenAI and OpenRouter.
Revoke personal access tokens that may have come from infostealer malware. Require two-factor authentication for maintainers and shorten token lifetimes so a stolen token has less time to be useful. Check cloud and AI provider usage logs for activity you cannot explain.
Blocking the campaign's activity does not automatically secure data already taken. Rotation is what cuts off stolen credentials, and it has to reach every system that trusted the old key.
What to watch next
Three questions will shape the coming weeks. First, whether the victim counts converge. The 30,000 repository figure and the 500 account figure have not been reconciled, and the number of US victims has not been confirmed beyond Uber's repository. Second, whether stolen credentials surface in poisoned package releases, which has not been reported. Third, who runs the operation, since attribution has not been established.
Federal guidance arrived the same week, but it runs on a different track. On October 16, NSA, CISA and NIST published 10 voluntary practices for handling incidents involving AI systems that take unauthorized actions during training and evaluation, according to Cryptika. That guidance is aimed at AI labs and does not address GhostAction directly.
The next signal will come from package registries and from any US company that discloses a breach tied to these keys. Teams that audit their workflows now will be better positioned than those that wait for a confirmed victim list.
