What we know so far: Hackers have reportedly used a malicious Visual Studio Code extension to gain access to a GitHub developer's machine, then leveraged the stolen credentials to move into GitHub's own infrastructure and copy thousands of internal repositories. From there, they allegedly put parts of the stolen code up for sale on a cybercrime forum, turning what appeared to be a routine developer tool into the starting point of a wider supply chain incident.
GitHub has said it found about 3,800 internal repositories accessed in the breach and stressed that these contained its own code rather than customer projects. The attackers, a group calling itself TeamPCP, claim the number is closer to 4,000 and are actively attempting to sell the stolen data.
"We are here today to advertise GitHub's source code and internal orgs for sale," the group wrote on BreachForums. "Everything for the main platform is there, and I am very happy to send samples to interested buyers to verify authenticity."
For security teams, the GitHub case is just the most visible example of a campaign that has been developing for months. TeamPCP has been heavily focused on software supply chain attacks, seeding malicious code into open-source projects that other developers rely on.
– GitHub (@github) May 19, 2026
Socket, a firm focused on supply chain security, estimates that the group has launched around 20 waves of attacks and tampered with more than 500 separate tools and packages. Each time a developer pulls one of those packages into a build or installs it locally, the attackers' reach expands.
The mechanics are straightforward but effective. TeamPCP first compromises a popular component in the developer ecosystem – such as a VS Code extension, a data visualization library, or another utility that has earned trust over time. When a developer installs or updates the tool, embedded malware executes on their system and harvests sensitive data, including personal access tokens, API keys, SSH keys, and cloud credentials.
Those stolen credentials are then used to publish backdoored updates to other tools, sometimes under the identity of a legitimate maintainer. The process becomes self-perpetuating as more developers download and install the compromised packages.
"It's a flywheel of supply chain compromises," Ben Read, who leads strategic threat intelligence at Wiz, told Wired. "It's self-perpetuating, and it's been a hugely successful way to get access to networks and steal stuff."
Recently, TeamPCP has accelerated that flywheel by automating large parts of its operation. Researchers have been tracking a worm component dubbed Mini Shai-Hulud that can propagate on its own once deployed.
The malware creates new GitHub repositories to store encrypted stolen credentials and tags them with the same phrase: "A Mini Shai-Hulud Has Appeared," along with references to the Dune universe. The naming appears to reference an earlier supply chain worm called Shai-Hulud, though there is no clear evidence that TeamPCP was responsible for that initial variant.
The group's campaigns have affected AI companies, security vendors, developer tools, and public institutions, including OpenAI, Mercor, Mistral AI, and the European Commission's public website. In each case, the critical entry point is not a zero-day in a core platform, but the compromise of something far more ordinary in a modern software pipeline: a scanner, library, or helper service that is widely trusted.
TeamPCP often conducts ransomware and data extortion campaigns against victims, but it is also willing to sell stolen data to the highest bidder. In the GitHub incident, the group said it was not seeking a direct ransom, instead framing the stolen code as a one-time sale: "This is not a ransom. We do not care about extorting GitHub. One buyer and we shred the data on our end." It also added a statement suggesting it may leak the data if no buyer is found: "It looks like our retirement is soon, so if no buyer is found we will leak it free."
Security researchers say the speed and reach of these operations stem from how developer environments are configured. Long-lived credentials, broad-scope tokens, and automated updates can turn IDEs and build systems into high-value targets.
"It's been like wildfire; it's gone very fast," says Nathaniel Quist, who manages the Cortex Cloud intelligence team at Palo Alto Networks. "They find credentials, personal access tokens, and then it's just how far can one credential go. I think we will continue to see these techniques. Threat actors know they work, and they're running with it."
Quist's advice is to start with the basics: tighten credential lifetimes, narrow scopes, and rotate secrets aggressively. "The biggest opportunistic factor making this operation successful is long-lived credentials in these environments," he said. "It's vitally important to change your tokens even if you're not using LiteLLM or any of these packages that have been compromised. If you have Gitlab and GitHub personal access tokens, rotate them. And AWS, Azure, GCP, Alibab [sic], Oracle all of these credentials are being taken."
Other experts are calling for changes to how teams consume open-source software. Read suggests "age-gating" updates: applying security patches quickly, but delaying new feature releases until they have been vetted and observed in the wild.
In at least one recent case involving a TeamPCP-linked package, Wiz flagged the malicious update within minutes, but many users had already downloaded it because auto-updates were enabled. "You don't want to just install the freshest version all the time," Read said.
For organizations that rely heavily on open-source and cloud-native stacks, this shift implies moving away from blind trust toward a "trust, then verify" posture. Philipp Burckhardt of Socket argues that scanning updates for malware before deployment, combined with cooling-off periods and stricter controls on developer machines, should become standard practice. As he puts it, once an attacker's code is already running locally, there is no easy undo. "At the point it hits your machine," Burckhardt said, "it's already too late."