- Socket reports two compromised GitHub accounts added a fake security-audit workflow to 346 repositories on October 8, 2026. It sends secrets to an outside server.
- This variant of GhostAction also searches full git history for cloud and AI keys, including ones developers had removed from current files.
- Rotating Actions secrets is not enough. Scan full history, rotate every key found, and review everything the compromised account could write to.
A deleted secret is still a stored secret
It is easy to treat a leaked key as fixed once the line is deleted from the code. A new GhostAction wave shows why that is not enough. Git keeps every past version of a file. A credential removed last year can still be read today.
Two compromised accounts added a malicious workflow to 346 GitHub repositories on October 8, Socket reports. The henrywoo and kitao accounts each pushed one new file to every project they had permission to change. Socket observed the same file, with only the secret list differing, across all 346. The file, .github/workflows/security-audit.yml, is called a security audit. It has no security function. It collects credentials and sends them to an outside server at 193.32.204[.]199.
How the workflow reads your past
GitHub Actions is the built-in automation that builds and ships code. A workflow is a recipe file that tells it what to run. This recipe has no filter, so any push at all sets it off, whatever the branch or tag.
Earlier GhostAction waves, which GitGuardian documented, took only the secrets stored in Actions settings. Socket reports that this variant keeps that step. It adds a second one: a search for cloud and AI credentials written into the code and its entire history.
The setting that makes this work is fetch-depth: 0. A normal automated checkout pulls one shallow copy of one branch. Depth zero pulls every branch and tag. The script then reads the full text of every past change. Socket notes this includes commits rewritten off the main branch that are still reachable from an old branch or tag. Socket says these are credentials the maintainer most likely believes are gone.
The search uses thirteen patterns. They cover AWS, Google, GitHub, Slack, SendGrid and AI-service keys. The AWS handling is the most deliberate part. An AWS key ID, which starts with AKIA or ASIA, authenticates nothing alone. The secret half usually sits a line or two away in a config file. So the script captures the surrounding lines and rebuilds a working key pair. Everything leaves in one web request.
Two exposures need two cleanups
Socket draws a practical lesson. Rotating Actions secrets does nothing for a key committed to history. Scanning the current files does nothing for an Actions secret. Teams that fix one can believe they fixed both.
The Pyxel project shows the stakes. Its repository, with 18,420 stars, publishes to both PyPI and crates.io. The secrets the script named there were the publishing tokens for both registries, plus a GitHub personal access token. Socket says these credentials could let an attacker ship a malicious release of a package users already trust.
That risk has not materialised so far. Socket has observed no malicious package versions on PyPI or crates.io from this activity at the time of writing. As of October 9, the file had not been removed from the default branch of the repositories Socket checked, uber/athenadriver and kitao/pyxel among them.
The account is the blast radius
Socket did not observe how the operator got the first maintainer credential. That gap matters. It means the entry point is unknown, and any team should assume its own logins could be reached the same way.
The reach is the point. The henrywoo account also wrote the file into uber/athenadriver, an Uber-owned repository, because he is its original author. Socket's description is that the damage is not one person's projects but every repository, in every organization, the credential can write to. A former contributor with old write access is part of your attack surface.
The sweep also touched 279 forks. Socket warns that forks can inherit the workflow when they are created or synced from an affected upstream. Private forks and mirrors carry the most risk, because that is where committed credentials tend to sit. Each run also sends back a repository identifier, with or without a stolen secret. That gives the operator a list of places where its code can execute, whether or not any credential was taken.
What to ask your team this week
First, ask whether anyone has searched full git history for keys, not only current files. Socket suggests git log -p --all, with unreachable objects included. Second, ask who still has write access to your repositories, including past authors and outside accounts. Socket advises listing access by permission, not by expectation.
Third, ask whether secret scanning with push protection is switched on, and whether workflow runs from outside collaborators need approval. Fourth, ask whether your egress logs show any connection to 193.32.204[.]199, including from self-hosted runners.
If the workflow is found, Socket advises treating any completed run as a successful theft. Rotate every named secret, revoke the account's tokens and sessions, and check AWS CloudTrail for new users, keys and unexpected regions.
The lesson is simple. Your repository is a record, and attackers can read all of it. A secret is only gone once it has been revoked.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Socket.
