Contents
In brief
The GhostAction campaign, according to GitGuardian, collected more than GitHub credentials. CI secrets, cloud keys, npm, PyPI, and Docker Hub tokens, and model-provider keys were in scope. A malicious workflow uses trust the build job already has. Looking at one GitHub account does not tell you whether a package was published, a cloud role was used, or a model key started a bill that is not yours. Save the run evidence first, then check every connected service.
What happened
A Dev.to post is about containment after a GitHub Actions secret theft, not a victim list. Every run has an identity: GITHUB_TOKEN, repository secrets the job can read, a short-lived cloud token via OIDC, and the network if the runner is self-hosted. The question is not whether the workflow file mentions a secret name. It is whether the malicious run could read a live value and send it out. A job stopped before it ran and a job that already reached the network are different evidence.
The author looked at the public internet layer in ZoomEye on 6 November 2026, around 15:46 UTC. A query for domain="github.com" returned 101 matches, 54 of them on port 443. A separate query for 193.32.204.199 returned two indexed observations. That is a snapshot of public infrastructure, not a victim count and not proof that credentials reached an attacker. The query does not show which clouds, registries, and model providers were tied to a repository.
Next is an inventory for each affected repository. For the cloud: role, account, and logs of token creation and use, and whether an unexpected principal appeared. For a package registry: scope, owner, and publish logs, and whether a new package or version went out. For source control: token scope and audit events, and whether the token changed other repositories. For a model provider: key owner, usage, and bills, and whether there was unexplained spend or a new project. The author asks you to keep the raw log or an export with a checksum. A screenshot of a dashboard does not replace that.
Why it matters
The incident crosses tool boundaries. Build trust is already wired into the cloud, into package publishing, and into model billing. While you only look at GitHub, someone else's package can sit in a registry and a model-key bill can already be running.
A short-lived token via OIDC, as GitHub's docs describe it, lowers the value of a secret found in git history. Access is tied to one run and can be read from the log. It does not close every door. A package registry often still wants a publish token. A model provider still wants an API key. The static secrets that remain should be narrowed to a project, a permission set, and a spend limit.
Deleting a key in a UI is not the same as revocation. The old value can keep working if the revoke step never finished.
In practice
- Save the workflow, the run record, and outbound network traces first. Then list the values each executed job could read.
- Rotate whatever has the widest reach. Confirm the approved consumer already uses the new value, and only then revoke the old one.
- Test the old key against a harmless endpoint. The answer should be a refusal. For cloud roles, read the trust policy and session logs. For registries, read release history and ownership. For model providers, read usage, project membership, and key creation.
- Do not read a public report as a claim that your cloud account was the one touched. Open write-ups do not name the repositories or every leaked value. They are a reason to check each connected provider.
Takeaway
A stolen build secret is a check of every door that build already opens. GitHub is the first line on that list, not the last.
Comments