GhostAction is still reusing stolen GitHub tokens: what that could mean for your releases
GhostAction is a campaign that uses compromised GitHub developer accounts to push malicious Actions workflows into repositories. Its October 2026 waves largely failed, but they showed something worth acting on: the same stolen tokens kept working. No release swap has been reported in GhostAction. This page is about what a token like that could do to your releases, and how to shut it down.
What GhostAction is
As Dark Reading describes it, attackers compromise developer accounts and commit GitHub Actions workflow files into repositories. The workflows try to collect repository secrets, package publishing tokens, GitHub personal access tokens and credentials sitting in source code. Each compromise is a chance to reach more repositories, CI systems and cloud accounts.
GitGuardian's October 27 research by Gaetan Ferry tracks the latest waves in detail.
What the October waves did, and what they didn't
- In an October 8 to 12 wave, attackers pushed a
security-audit.ymlworkflow into roughly 30,000 repositories (Dark Reading). - Between October 13 and 21, the operator "pushed 72,000 commits to 23,000 public repositories," and 8,000 of those were new targets (GitGuardian).
- The campaign shipped five payload families, including one that tries to use GitHub OIDC tokens to assume AWS roles, and a stealer aimed at developer machines (GitGuardian, Dark Reading).
What did not happen, as far as anyone has reported: GitHub identified and prevented execution of the malicious workflows, GitGuardian noted. Of the five payloads, only the developer-machine stealer had a chance to run, and GitGuardian has no evidence that any run actually occurred.
No source reports GhostAction publishing, editing or swapping a release. Everything below about releases is a risk path, not a description of what GhostAction did.
That developer-machine stealer copies its launch technique from PolinRider, a campaign that has been associated with North Korea. That link is the assessment of GitGuardian and OpenSourceMalware. GitGuardian says it could not assess whether the two campaigns overlap, and suggests the GhostAction operator may have copied a public PolinRider launcher.
Why the same tokens keep working
GitGuardian found that "1,382 of the 1,792 compromised accounts had already been used on Oct. 8, so the same stolen tokens keep working." In other words, most of the access came from tokens stolen earlier that nobody revoked. GitHub blocking a workflow does not revoke the token that pushed it, and deleting a workflow file does not either. GitGuardian expects new waves "with revised payloads."
What a stolen token could do to a release
Whether a token can touch your releases depends on its type and permissions. Per GitHub's release assets API docs, uploading, editing or deleting a release asset needs the "Contents" repository permission with write access.
| Token | Could it change releases? | What to do |
|---|---|---|
Classic personal access token or OAuth token with repo scope (or public_repo for public repos) | Treat it as yes. GitHub says repo grants read and write access to code in public and private repositories. (scopes) | Revoke it. Replace it with a fine-grained token limited to the repos and permissions you need. |
| Fine-grained personal access token or GitHub App token with Contents: write | Yes, on the repositories it can reach. (fine-grained permissions) | Limit it to specific repositories. Give Contents: write only where a release is actually published. |
| Fine-grained token with Contents: read only | No. Release asset uploads and deletes need write. (release assets) | Prefer read-only tokens for anything that only downloads. |
A workflow's GITHUB_TOKEN | Only if the job grants it write access to contents. | Set default permissions to read and grant write per job. (GITHUB_TOKEN docs) |
On a release that is not immutable, a token with write access to contents could replace the files under the same version name. That is exactly what happened in a separate incident, the OVHcloud CLI swap, where a compromised account was used. See What 2026's GitHub supply-chain incidents show about unlocked releases.
Close it this week
From GitGuardian's advice, as reported by Dark Reading, if your repos or accounts were hit:
- Find and delete the files GitGuardian lists in the indicators section of its post, on every branch, not just the default one.
- Revoke the affected account's tokens across the board.
- Rotate every credential committed in the affected repository or its history, every Actions secret, and every wiki credential.
ReleaseLock's own advice, for everyone who publishes releases:
- Review your personal access tokens and revoke any you no longer use. GitHub's docs explain how tokens expire and get revoked.
- Move from classic tokens to fine-grained tokens scoped to specific repositories.
- Set the default
GITHUB_TOKENpermissions to read only. - Turn on immutable releases, described below.
Backstop: lock releases so a token can't swap them
Revoking tokens closes the door you know about. Immutable releases protect you from the ones you don't. Once an immutable release is published, GitHub blocks changes to its assets and blocks moving or deleting its tag. A stolen token with write access could still delete an immutable release, but GitHub says the tag name cannot be reused, so it cannot quietly put different files under the same version. Immutability applies to releases published after you turn it on.
To see whether the tools you install are locked, search the ReleaseLock directory, and read Can this GitHub release be swapped? for what each lock level means. To fail CI on unlocked or unpinned Actions, add the free ReleaseLock gate.
Quick answers
What is GhostAction?
GhostAction is a campaign that uses compromised GitHub developer accounts to commit malicious Actions workflows into repositories. The workflows try to collect repository secrets, package publishing tokens, personal access tokens and credentials in source code.
Did GhostAction swap or change any GitHub releases?
No source reports that. GitGuardian noted that GitHub identified and prevented execution of the malicious workflows, and it has no evidence that even the one payload that could run actually ran. The release risk comes from what stolen tokens could do, not from anything GhostAction is known to have done.
Why do stolen GitHub tokens matter after GitHub blocks the workflows?
Blocking a workflow does not revoke the token that pushed it. GitGuardian found 1,382 of the 1,792 compromised accounts in the October 13 to 21 wave had already been used on October 8, so the same stolen tokens kept working.
Which GitHub tokens can change a release?
Uploading, editing or deleting release assets needs the Contents repository permission with write access. That includes fine-grained tokens and GitHub App tokens with Contents write, classic tokens with repo or public_repo scope, and a workflow GITHUB_TOKEN that has been granted contents write.
What stops a stolen token from swapping an existing release?
Immutable releases. Once an immutable release is published, GitHub blocks changes to its assets and its tag. A token could still delete the release, but the tag name cannot be reused, so different files cannot be published under the same version.
Look it up in the directory, or add the free scan step to your workflows.
Search the directorySources
- Dark Reading, Alexander Culafi, October 28, 2026, GhostAction Hacking Wave Fizzles, but Attackers Lurk on in GitHub
- GitGuardian, Gaetan Ferry, October 27, 2026, GhostAction Crosses Paths With PolinRider: Inside the October Escalation
- GitHub Docs, REST API endpoints for release assets
- GitHub Docs, Permissions required for fine-grained personal access tokens
- GitHub Docs, Scopes for OAuth apps
- GitHub Docs, Use GITHUB_TOKEN for authentication in workflows
- GitHub Docs, Managing your personal access tokens
- GitHub Docs, Token expiration and revocation
- GitHub Docs, Immutable releases
- GitHub Docs, Preventing changes to your releases