About 4,800 GitHub Accounts Abused With Apparently Stolen Tokens, CI Secrets and Cloud Credentials Stolen (November 2026): What Repository Owners Should Do Today

In every repository your account can write to (including organizations where you are a collaborator), check these three things since November 10. According to Firm A, of 61,839 probe pull requests, 10,431 went to repositories the account does not own, reached through collaborator or organization access.

• Pull requests that neither you nor a teammate opened. Even if the title looks harmless (such as a docs update), the same pattern across many repositories is a warning sign
• Short-lived branches you do not recognize, or signs that branches were created and deleted
• Actions run history with runs you do not recognize or gaps in run numbers. Firms A and C write that the attacker deletes runs and logs within about a minute, so a gap in numbering is a clue. Check the organization audit log as well

If you find any of these, continue below. Firm A writes that an account with a probe pull request should be treated as compromised even if the later stage did not run.

This order follows the guidance of Firms B and C.

• Revoke personal access tokens, authorizations to third-party apps (OAuth apps and GitHub apps), SSH keys and active sessions, then recreate only what you need
• Enable two-factor authentication. A token that is already stolen works without it, so revoking the token comes first (our view)
• Close the probe pull request and delete branches you do not recognize. Before deleting, record which account they were created under

Firms A and B write that if the malicious change ran, every secret and cloud role available to that workflow should be treated as stolen.

• Reissue Actions secrets and variables (repository, environment and organization level), publishing tokens (including for packages) and deploy keys, and invalidate the old ones
• If you use OIDC to reach a cloud account, include that cloud permission (next step)
• If you built a repository that may have received a malicious change on a development machine, rotate the credentials that machine could read too (SSH keys, cloud credentials, package-publishing tokens and so on). Firms B and C report changes that run at package install time
• If you published packages since November 10, check that the published versions do not contain the malicious change; if they do, withdraw them and republish from a clean state

As changes that survive a secret rotation, Firm A lists rewriting an AWS role trust policy and adding Azure federated credentials (Firm B also notes AWS access keys left behind). Check these two areas in both audit logs and current settings.

• AWS: newly created access keys, and changes to role trust policies (has trust widened to unintended accounts or conditions)
• Azure (Entra ID): federated credentials added to applications that point back to a repository

Separately, as a check for privilege escalation with stolen credentials, also look at Google Cloud (unusual service-account use or token-issuing calls) and Vault or Kubernetes (GitHub OIDC logins you do not recognize).

Even if you find nothing, check whether your OIDC trust conditions are narrowed to the repository, branch and environment (see "What to review" below).

In your GitHub settings, list the following and remove what is unneeded or unfamiliar.

• Personal access tokens: delete unused ones; for the rest, limit repositories, permissions and lifetime
• OAuth apps and GitHub apps you authorized, including those connected for hosting or CI deployment. Remove authorization for any you no longer use
• SSH keys and deploy keys: remove unused keys and keys without an owner
• Permissions of bot and automation accounts: check for any that can bypass protected-branch rules

According to the cloud provider's notice, reconnection is required for that provider's app. If you use it, follow the provider's instructions.

The same provider explains that some apps deployed through GitHub published the whole build directory, so a token left there could be retrieved. Check that your app's public URL does not serve the contents of the version-control folder (.git). If it does, exclude it from the image, redeploy, and rotate any credentials it contained. Also check whether your deployment platform uses a similar mechanism.

Here valid stolen tokens were used. Limit personal access tokens to specific repositories and permissions, give them short lifetimes, and delete them when no longer used (use the fine-grained type). Authorize third-party apps only for the scope they need (our view).

Make the default workflow permission read-only and grant write only where needed. Narrow cloud OIDC trust to the repository, branch and environment so that not every workflow can enter. Putting approvers on environment secrets means a rewritten workflow cannot simply read production secrets (our view).

Firm A writes that the code includes a mechanism meant to get past branch protection. Do not rely on check names alone: require approving reviews from code owners and allow no exceptions for bot accounts (our view).

In this case runs and logs were deleted and gaps in numbering were the clue. Keep the organization audit log, and set alerts for workflow changes and for cloud access-key creation, trust-policy changes and added identity federation. Firm C also recommends limiting outbound traffic from CI to an allowlist.

Apart from CI secrets, credentials in code history are taken along with a stolen token of anyone who can read them. For catching them before commit, see Stopping secrets before commit with gitleaks; for the order of revocation, see 540,000 credentials exposed on GitHub are still valid.