Attackers used stolen GitHub personal access tokens to clone thousands of private repositories from several unrelated companies, in a coordinated campaign that ran from mid May through early June 2026. The Wiz Customer Incident Response Team (CIRT), which handled the response at multiple victim organizations, published its timeline and indicators in a report on the campaign.
Personal access tokens, or PATs, are long lived credentials developers create so that scripts and tools can talk to GitHub on their behalf. One stolen token can be enough to read every private repository its owner can reach, which in practice means source code plus whatever cloud keys, API tokens and private keys were committed alongside it.
Three stages, three sets of infrastructure
For most affected organizations the first visible sign was a spike in git.clone events in their GitHub audit logs on June 1. Between 09:14 and 14:55 UTC, Wiz says the actor used 102 AWS IP addresses located in the ca-central-1 region to clone up to thousands of repositories per organization, using the git/2.43.0 user agent and a degree of parallelism that points to automated tooling. The tokens belonged to real employees of the companies that were hit.
Working backwards from that spike, Wiz CIRT found two earlier phases. On May 15 the actor queried GitHub's repository readme API endpoint from a single Amazon EC2 address, 13[.]221[.]167[.]217, using an ordinary Chrome browser user agent, apparently to work out which repositories the stolen tokens could reach. Then between May 29 and May 31 the same tokens pulled a small number of repositories from 107[.]174[.]201[.]183, an address at hosting provider HostPapa, using the git/2.25.1 user agent. Those clones started within seconds of one another across several different victims, which Wiz reads as an automated validation run before the main event.
One detail matters for defenders: that reconnaissance generates api.request events, which GitHub exposes only through Enterprise Log Streaming and not in standard audit logs. Organizations without that stream had no visibility into the first phase at all.
Nobody knows yet how the tokens leaked
Across every affected organization, Wiz says the initial access vector was not identified. Its investigators found no evidence that the tokens had been exposed in code or in cloud resources, and how a single actor obtained valid PATs belonging to staff at several unrelated companies remains an open question. Based on its own experience with credential theft, Wiz considers endpoint compromise a possible route, but states plainly that it could not confirm one.
Why a cloned repo is bigger than stolen code
Repositories routinely hold cloud credentials, SaaS tokens, internal documentation, private keys and regulated data, so this kind of exfiltration is better scoped as a potential credential breach than as intellectual property theft. It is the same pattern running through a string of recent secret harvesting cases, including the AI supply chain compromise that exposed secrets belonging to roughly 2,500 companies and the cloud extortion crew that steals secrets through service accounts.
The clock works against responders here. In GitHub Enterprise Cloud, git.clone, git.fetch and git.push events are retained for only seven days, so an organization that is not shipping those logs somewhere else may simply be unable to establish what was taken.
What you should do
- Revoke the token first, then temporarily remove the user from the organization while you investigate, because owners often cannot independently verify that a classic PAT is really gone.
- Baseline that user's normal source addresses, user agents and access times in the audit log, then pivot on the indicators to catch related activity under other accounts.
- Treat every valid secret inside a cloned repository as compromised: inventory it, rotate it, and then hunt for use of those secrets in cloud and SaaS logs covering the window before rotation.
- Stream GitHub audit logs, ideally at enterprise level, into a system that keeps them for longer than seven days.
Indicators of compromise (defanged): 13[.]221[.]167[.]217 for the May 15 reconnaissance; 107[.]174[.]201[.]183 for the May 29 to 31 validation clones; user agents git/2.25.1 and git/2.43.0; and mass cloning on June 1 from AWS ca-central-1 addresses including 15[.]223[.]74[.]214, 35[.]183[.]112[.]105 and 99[.]79[.]193[.]97.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.