#They already have your tokens. Now they're checking which ones work.

On May 27, 2026, security researchers observed a mass campaign from IP ranges associated with a bulletproof hosting provider (RoyaleHosting) systematically validating stolen GitHub Personal Access Tokens against the GitHub API.

The attacker isn't stealing tokens. That part already happened. Through supply chain malware, data breaches, accidentally committed secrets, paste sites, and the TeamPCP credential harvesting pipeline, they've aggregated a massive collection of GitHub PATs.

Now they're calling the GitHub API with each one to see:

• Is this token still valid?
• What scopes does it have? (repo? workflow? admin:org?)
• What repos can it access?
• What organization does it belong to?

The high-value tokens (full repo scope, workflow scope, admin scope) get triaged for immediate use. The rest get cataloged for resale.

A single valid PAT with repo and workflow scope gives the attacker:

• Read/write access to every repo the token owner can access
• CI/CD pipeline control (modify workflows, inject build steps)
• Secret extraction from GitHub Actions environment variables
• Source code theft
• Backdoor insertion into any branch

That's near-complete control of an organization's source code and deployment infrastructure. From one stolen token.

#Where the tokens came from.

GitHub tokens end up in attacker databases through multiple paths:

1. Supply chain malware. Every wave of the Mini Shai-Hulud campaign harvests GitHub PATs from compromised developer machines. The credential harvest includes ~/.config/gh/hosts.yml which stores GitHub tokens.

1. Accidentally committed to repos. Developers accidentally commit tokens in .env files, config files, or code. GitHub has secret scanning to detect this, but not everyone enables it, and there's a window between commit and detection.

1. Data breaches at other services. If a developer used the same email/password for GitHub and a breached service, and their GitHub account doesn't have MFA, the attacker can generate new tokens.

1. Paste sites and code snippets. Developers paste code containing tokens to Stack Overflow, Pastebin, Gist, or Slack. Automated scrapers collect them instantly.

1. Infostealer malware. Browser-stored credentials and saved tokens from the developer's machine. The Lumma infostealer that hit Vercel harvests exactly this kind of data.

#What to do. Today.

1. Audit your GitHub PATs right now.

Go to github.com/settings/tokens. Look at every token. Ask yourself:

• Do I still use this?
• Does it have more scope than it needs?
• When does it expire? (If "never," fix that.)

Revoke anything you don't actively need. This takes 5 minutes and eliminates the most common attack vector.

2. Switch to fine-grained tokens with minimal scope.

Classic PATs have broad scopes (repo gives full read/write to all repos). Fine-grained tokens let you restrict access to specific repositories with specific permissions. Use them.

3. Set token expiry to 90 days or less.

A token that never expires is a token that works forever once stolen. Set a 90-day expiry and rotate regularly. Yes, it's annoying. Less annoying than explaining to your clients why their source code is on a dark web forum.

4. Enable secret scanning and push protection.

GitHub offers secret scanning that detects tokens committed to repos and push protection that blocks commits containing secrets before they're pushed. Both are free for public repos and included with GitHub Advanced Security for private repos.

Go to your org settings > Code security and analysis > Enable both.

5. Enforce SSO and MFA across your organization.

If your GitHub org uses SAML SSO, tokens generated outside the SSO flow are automatically invalidated. This prevents stolen tokens from being usable. And MFA on every account prevents the credential-stuffing path.

6. Monitor your audit log.

GitHub audit logs show API access, including which tokens were used and from which IPs. Set up alerts for API access from unexpected locations or at unusual times.

`

#Check your org's audit log for PAT usage

gh api /orgs/YOUR-ORG/audit-log?phrase=action:org.oauth_app_access_requested

`

#Further reading

• GitHub: Managing Your PATs - fine-grained token setup
• GitHub: Secret Scanning - detect committed secrets
• GitHub: Audit Log - monitor token usage
• GitHub: Requiring 2FA - enforce MFA on your org