A collaborator's GitHub account pushed to your repo: how to tell if CI secrets leaked and what to rotate first
Quick answer, Nov 12, 2026As of 12 November 2026, Aikido reports compromised GitHub accounts pushing a workflow that steals GitHub Actions secrets and cloud credentials, starting 10 November. If a collaborator's account pushed to your repository, remove its access first, read the audit log for deleted workflow runs, then rotate cloud credentials and publishing tokens before everything else.
What Aikido reports
Aikido Security published its analysis on 12 November 2026. It says that "starting on November 10, a threat actor used stolen GitHub credentials to push a malicious workflow payload into tens of thousands of repositories," and that "the payload steals GitHub Actions secrets and cloud credentials." Aikido calls it wfx-loot. By its count, 4,837 compromised accounts opened probe pull requests in 61,764 repositories, and at least 1,835 repositories ran the payload.
Aikido also reports that 10,431 of those pull requests went into repositories the account does not own, "reached through collaborator or organisation access." That is this page's case: someone with write access was compromised. GitHub's Secure use reference, "Use secrets for sensitive information" (under "Principle of least privilege"), says why that matters: "Any user with write access to your repository has read access to all secrets configured in your repository." NIST SP 800-204D, section 3.1.5 "Types of Exploits", names both halves: "Stolen credentials that grant access to other systems" and "Stealing secrets by submitting merge requests".
Seven steps, in order
| Step | What to check or do | Where it is written |
|---|---|---|
| 1. Indicators | A wfx-docs branch, a docs: dependency audit notes pull request, the listed commit titles, gaps in workflow run numbers since 10 November | Aikido, "Who is affected", "What happened" and "GitHub indicators" |
| 2. Deleted runs, secrets passed | Export the audit log and filter workflows.delete_workflow_run and workflows.prepared_workflow_job | GitHub, Audit log events for your organization, "workflows"; SP 800-53 Rev. 5 AU-6 |
| 3. Contain the account | Remove its write access until its owner has secured it | GitHub, Removing an outside collaborator; CSF 2.0 RS.MI-01 |
| 4. Undo persistence | Cloud role trust policies, federated identity credentials, IAM access keys created since 10 November | Aikido, "What it steals"; SP 800-53 Rev. 5 IA-5(d) |
| 5. Rotate | Cloud first, then publishing tokens, then every other secret on the job's list | GitHub Secure use reference, "Delete and rotate exposed secrets"; SP 800-53 Rev. 5 IA-5(f) |
| 6. Merge gates | Required status checks tied to an expected source app; review what merged since 10 November | GitHub, About protected branches, "Require status checks before merging" |
| 7. Harden | Read-only GITHUB_TOKEN default, CODEOWNERS on workflow files, environment reviewers, narrow OIDC trust | GitHub Secure use reference; CSF 2.0 PR.AA-05 |
How to tell whether the payload ran
Aikido's "Who is affected" section lists the marks: a wfx-docs branch or a pull request titled docs: dependency audit notes; and commits titled ci: refresh build cache, chore: add ci helper or chore: add dependency audit workflow. It says: "If the probe ran, that user is compromised, even if the workflow stage did not run."
Aikido says the actor "reverts within at most one minute and deletes the workflow run, along with its logs," and that "a missing run number in the workflow's history is often the only trace." An organization's audit log still records it: GitHub's events list, under "workflows", includes workflows.delete_workflow_run and workflows.prepared_workflow_job, which "includes the list of secrets that were provided to the job". That is your rotation list. It is available "only via the REST API, audit log streaming, or JSON/CSV exports" (see "Exporting the audit log" in Reviewing the audit log for your organization). For a personal account, the security log "lists all actions performed within the last 90 days."
What to rotate first, and why the order matters
Aikido: "If the payload ran in your repository, assume every secret and cloud role available to its workflows is compromised." The order below is ours, worked out from what Aikido says the payload does, not a published standard.
Access before secrets. Anyone who still has write access can read a new secret.
Cloud trust before cloud keys. Aikido lists three actions "designed to outlast credential rotation": forged success status checks, an AWS role trust policy rewritten to "Principal": {"AWS": "*"}, and new Azure federated identity credentials named wfx-ci-…. The payload also calls iam:CreateAccessKey and exchanges minted OIDC tokens for cloud sessions. Rotating a GitHub secret undoes none of that, so review trust policies, federated credentials and new keys first.
Publishing tokens next. Aikido found the payload in a Packagist package and a Go module "through automated publishing triggers." Check every version you published since 10 November, then rotate registry tokens.
Then everything else on the job's list, including AI provider keys, which Aikido names as targets. Self-hosted runners need rebuilding: GitHub says they "can be persistently compromised by untrusted code in a workflow" ("Hardening for self-hosted runners"). The GITHUB_TOKEN needs no rotation; GitHub says it "expires when the job finishes or after its effective maximum lifetime."
Check what merged
Aikido says branch protection "matches on the context name, not on the app that posted it," so forged checks can clear merge gates. GitHub's "Require status checks before merging" confirms "any person or integration with write permissions to a repository can set the state of any status check," and says you "can select an app that has recently set this check as the expected source of status updates." If yours accept any source, review what merged since 10 November.
After: making the next one smaller
GitHub's Secure use reference recommends a GITHUB_TOKEN default of "read access only for repository contents" ("Restricting permissions for tokens") and CODEOWNERS on .github/workflows ("Using CODEOWNERS to monitor changes"). It adds that with environment required reviewers, "a workflow job cannot access environment secrets until approval is granted by a reviewer" ("Consider requiring review for access to secrets"). On Free, Pro or Team plans, that works only in public repositories. OIDC removes long-lived cloud secrets, but this payload mints OIDC tokens, so trust conditions should match a narrow subject, such as one protected environment.
Where this sits next to the other pages
Third-party access through a managed service provider is in Your MSP's RMM tool just went dark; the contract side is in Third-party risk after a provider-led breach.
From an AI assistant, the Distributed Risk MCP server runs check_dependencies, which checks package versions against OSV.dev, including OpenSSF's malicious-package reports. If you need people to investigate, the criteria are in Choosing a cyber crisis response firm, or brief an advisor and we arrange a partner firm.
Questions
Our repository is private. Are we clear? Not necessarily. Aikido says the payload's private-repository settings suggest it "may be being deployed in private repositories as well as the public ones we can identify." Read your own audit log.
No wfx-loot artifacts or caches. Nothing taken? Not necessarily. Aikido says their absence "does not mean data was not taken" and that the run itself is usually deleted.
Is this legal advice? No. This page is a procedural checklist drawn from the public record. Counsel decides what your contracts and your regulator require.