GitHub Actions: workflows that steal secrets

In October 2026, two separate campaigns planted secret-stealing GitHub Actions workflows in thousands of repositories. The first, GhostAction, documented by GitGuardian and Socket, peaked on October 8 and 9; according to GitGuardian, GitHub prevented the malicious workflow from running starting October 9. The second, Gheist, which Wiz Research has tracked since September 15 and described on October 25, also reached private repositories. In both cases, the commits were pushed with the victims' own credentials, by all appearances stolen.

What the sources say

GitGuardian, on GhostAction. The post published on October 7 and updated on October 9 and 13 first establishes that, from August 31 to September 30, 2026, the malicious workflow was pushed to 772 public repositories belonging to 373 users and organizations, targeting 2,577 secrets. The October 13 update changes the scale: "the threat actor targeted more than 30,000 repositories across 3,000 users and orgs," from the accounts of about 1,900 users, attempting to extract 3,174 secrets. GitGuardian adds: "GitHub started preventing the malicious workflow from running starting October 9," so the waves of October 10 and 12 extracted no secrets. Another finding: only 124 repositories, or 16%, had actually been cleaned by October 5. For reference, the 2025 campaign hit 817 repositories across 327 users and exfiltrated at least 3,325 secrets.

Socket, on the same campaign. On October 9, Socket described a burst on October 8: 2 compromised maintainer accounts, 346 repositories hit. Its update the same day reported more than 500 accounts that pushed the workflow to tens of thousands of repositories since October 7, including several owned by organizations. Socket notes that this variant no longer stops at Actions secrets: it also looks for cloud and AI service credentials in the repository's code and history.

The numbers do not match. GitGuardian speaks of about 1,900 accounts, Socket of more than 500 as of October 9. The two counts were published on different dates, October 9 and October 13, each from its own firm's data, so we give each one as published.

Wiz Research, on Gheist. On October 25, Wiz described a different campaign, which it explicitly distinguishes from GhostAction: "We have recovered more than 13,500 planted branches from more than 850 compromised accounts," from personal projects to private enterprise repositories. The credentials it could trace likely came from infostealer logs and from tokens exposed in earlier software supply chain compromises.

GitHub. On July 28, 2026, GitHub announced that potentially malicious runs wait for approval from a collaborator with write access. But "this protection currently applies to public repositories on github.com only." Wiz confirms the hold worked in public repositories, and that it "doesn't apply to private repositories or GitHub Enterprise Server," where it saw runs complete.

Why it matters

A pipeline secret is an identity. It publishes packages, deploys to production, reads a vault or creates cloud resources. GitGuardian's breakdown shows it: SSH keys and deployment server credentials, Azure credentials, container registries, databases, AWS keys. Whoever controls the workflow controls everything those secrets open.

The second lesson is about lifetime. GitGuardian observes that some 2026 victims had already been hit in 2025, likely because old credentials were never rotated. A personal token stolen from a laptop and still valid was enough to push code into every repository it could reach.

Finally, short-lived credentials do not solve the problem on their own. Wiz saw the organizations' own workflows assume AWS roles through OIDC from the planted branches. OIDC removes the stored secret, but the trust relationship must still be limited to protected branches and environments.

What we think at Sentrix

1. Inventory CI secrets as identities. Each secret has an owner, a scope, an expiry date and a list of repositories that can read it. That is the approach in our article on non-human identities.
2. Move to short-lived credentials. OIDC between GitHub and the cloud provider replaces stored keys, provided trust is limited to protected branches and to environments with required reviewers, as Wiz recommends. Our cloud security service covers these trust relationships.
3. Take personal tokens out of automation. Wiz recommends GitHub Apps or short-lived fine-grained tokens instead. Stolen tokens, some traced by Wiz to infostealer logs, are what was abused here. Our identity and access service helps with that clean-up.
4. Review every workflow change. A file added to the workflows directory should require review by a designated owner, even when pushed by a legitimate account, and an alert should flag any new branch that adds one.
5. After an incident, revoke before you rotate. Revoke the token that pushed the commit, rotate every secret the repository could reach, check package release history and treat any affected self-hosted runner as compromised. Detailed indicators are in the GitGuardian, Socket and Wiz write-ups.
6. Ask your vendors the same thing. A vendor whose pipeline is compromised ships compromised code. How it protects its CI secrets belongs among the questions in our article on the SBOM and what to ask a vendor, and in your third-party risk assessment.

The next step

List today the secrets your workflows can read, with, for each one, what it opens, its expiry date and when it was last rotated. The rows without a date are your priority for the week. If you want to do this exercise with us, contact us.