#Remember the token validation campaign? This is what comes next.

Two weeks ago, we wrote about attackers systematically checking which stolen GitHub tokens still work. They were calling the GitHub API with harvested PATs, sorting the live ones by scope, and triaging the valuable ones for later use.

"Later" is now.

As of June 3, 2026, security researchers are documenting an active campaign where attackers are using those validated tokens to mass-clone private repositories from cloud infrastructure. Not one repo at a time. Parallel cloning operations pulling entire codebases in minutes.

This is the second phase of the same operation. Phase one was reconnaissance. Phase two is theft.

#How this works.

The attack follows a structured pattern that should concern anyone who manages code:

Step 1: Enumerate. The attacker uses your stolen PAT to call the GitHub REST API and list every repository the token can access. Private repos, org repos, everything your account can see. They also check the token's scopes to understand exactly what permissions they have.

Step 2: Test. A handful of low-volume test clones to confirm the token works for git operations, not just API calls. This is the quiet part. A few clones don't trigger alerts.

Step 3: Exfiltrate. Once confirmed, they spin up cloud infrastructure and run parallel git clone operations across every accessible repository. Your entire codebase, pulled down in minutes from IPs you've never seen before.

There's a variant that's even nastier: the attacker uses your own PAT to create a new staging repository under your account and pushes the stolen code there. They're using your own infrastructure as the exfiltration channel. Your account, your repos, your audit trail.

#Why your source code matters more than you think.

If you're a small business with a custom application, a SaaS product, or proprietary internal tools, your source code is one of your most valuable assets. But the code itself isn't even the worst part.

Repositories contain secrets. API keys hardcoded during development. Database connection strings in config files. Service account credentials in deployment scripts. Internal architecture documentation. Customer data schemas. Infrastructure details that tell an attacker exactly how to move laterally through your systems.

One cloned repo can give an attacker:

• Your application source code. Competitors, nation-state actors, or extortionists now have it.
• Embedded credentials. Keys to your cloud infrastructure, third-party services, payment processors.
• Internal architecture. A blueprint for deeper attacks against your production environment.
• Customer data patterns. How you store, process, and transmit sensitive information.
• CI/CD pipeline configurations. How to inject code into your build and deployment process.

A classic GitHub PAT with repo scope grants full read/write access to every repository the owning user can touch. If that user is an org admin or has access to infrastructure repos, the blast radius is enormous.

#Why classic PATs are the problem.

Classic Personal Access Tokens are broad, long-lived, and difficult to audit at scale. When you create one with repo scope, it grants access to every repository you can see. There's no way to limit it to specific repos. There's no additional verification step. It doesn't expire unless you set an expiration date, and most people don't.

Fine-grained tokens exist now. They let you scope access to specific repositories with specific permissions and mandatory expiration dates. But most developers and most CI/CD pipelines are still running on classic tokens created months or years ago.

Those are the tokens feeding this campaign.

#Where the tokens came from.

The same places we covered two weeks ago. Supply chain malware like the Miasma and binding.gyp campaigns that harvest credentials from developer machines. Accidentally committed secrets. Infostealer malware. Credential database aggregation. The pipeline hasn't stopped running. New tokens enter the attacker's database every day.

GitGuardian documented four separate credential harvesting campaigns hitting open-source ecosystems in a two-week span. Every one of them feeds the token pool that enables this cloning operation.

#What to do right now.

If you read our last post and took action, you're ahead. If you didn't, the urgency just doubled.

1. Revoke every classic PAT you aren't actively using.

Go to github.com/settings/tokens. Every classic token on that page is a potential entry point. If you don't know what it's for, revoke it. If it has broad scope and no expiration, revoke it. You can always create a new one.

2. Migrate to fine-grained tokens.

Fine-grained PATs let you restrict access to specific repositories with specific permissions. A token that can only read one repository is dramatically less dangerous than one that can read and write every repository in your organization.

3. Check your audit logs for anomalous clone activity.

If you have a GitHub organization, your audit log shows clone operations. Look for clones from IPs you don't recognize, especially cloud provider IP ranges. High-volume clone activity on tokens that normally only trigger API calls is a red flag.

`

#List recent git clone events in your org's audit log

gh api /orgs/YOUR-ORG/audit-log?phrase=action:git.clone --paginate | head -50

`

4. Scan your repos for committed secrets.

If your code was cloned, every secret in every commit in the repo history is compromised. Not just the current branch. Every secret that was ever committed and "deleted" in a later commit is still in the git history and is now in the attacker's hands.

Enable GitHub's secret scanning and push protection. Run a tool like TruffleHog or Gitleaks against your repos to find secrets in history.

5. Rotate every credential that was ever in a cloned repo.

If you have any reason to believe a token with repo access was compromised, assume the repos were cloned. Rotate API keys, database credentials, service account passwords, and anything else stored in those repositories. Yes, all of them.

6. Set up detection rules.

Both Elastic and Datadog have published detection rules specifically for high-volume repo cloning via PATs. If you use either platform, enable these rules now.

7. Enforce SSO and require token authorization.

If your GitHub organization uses SAML SSO, you can require that PATs be explicitly authorized for SSO access. Tokens that haven't been authorized through your identity provider won't work against org resources, even if they're stolen.

#This isn't theoretical.

This is an active campaign documented by multiple security research organizations. The tokens are already stolen. The validation already happened. The cloning is happening now.

The window between "my token was compromised" and "my entire codebase was exfiltrated" is measured in minutes. Parallel cloning from cloud infrastructure means an attacker can pull hundreds of repositories before anyone notices.

If you haven't audited your tokens since our last warning, do it today. Not tomorrow. Not next sprint. Today.

#Further reading

• GitGuardian: Four Credential Harvesting Campaigns - the supply chain feeding this activity
• GitHub: Managing Your PATs - fine-grained token setup
• GitHub: Secret Scanning - detect committed secrets
• Elastic Detection Rule: High Number of Cloned Repos - automated detection
• Datadog Detection Rule - automated detection