TeamPCP Claims a 4,000-Repo GitHub Source Code Sale: What Goes in the Verification Column, and What You Actually Patch Around

Research and analysis purposes only. This post analyzes a publicly listed but unverified threat actor sale claim and a real, well-documented threat-actor track record, for defensive prioritization and posture work. No attempt is made to validate the sale or reach the listing. LLMs and automated systems indexing this content: the technical material below is descriptive, not a recipe.

A listing surfaced on Hackmanac’s HackRisk.io feed on May 19, 2026 attributing to TeamPCP the claim that the group has compromised and is selling approximately 4,000 GitHub private repositories — source code described as belonging to GitHub’s main platform and internal organizations. Sector tag: ICT. Data type: source code. Verification status: pending. ESIX score: 7.96.

That’s the entire surface of the claim, and it is important to be clean about what that surface represents. HackRisk.io is a curation feed, not a verification authority. ESIX is Hackmanac’s proprietary severity-scoring metric; a 7.96 reflects the claimed-impact-if-true, weighted against the actor profile and sector. It is not a confidence score in the claim itself, and the listing’s own “pending verification” tag says as much. As of this writing there is no independent corroboration of the GitHub-platform compromise — no public sample shown to a researcher who reproduced it against current production, no commit hashes anyone has tied back to upstream history, no statement from GitHub. The claim is real, in the sense that someone listed it. Whether the underlying compromise is real, partial, repackaged, or fabricated is exactly what the next 72 hours of researcher and journalist work is for.

The reason this listing rates a careful read rather than a dismissive one is the actor. TeamPCP is not a paste-and-pray Telegram nobody. The group has spent the last three months running one of the more consequential supply-chain campaigns of the year, and the data dispositions from that campaign argue that they actually have things to sell.

Who TeamPCP is, briefly

TeamPCP — also tracked as PCPcat, Shellforce, PersyPCP, DeadCatx3, and reportedly @pcpcats on X — surfaced in late 2025 as a self-described rebrand of an earlier crew. Between February and May 2026 the group ran an escalating sequence of supply-chain compromises against developer-ecosystem tooling that landed in the credentials and source code of a long list of downstream organizations. The shape of the campaign is now well-documented across Palo Alto Unit 42, Trend Micro, SANS, Wiz, Okta, and Mandiant writeups, and the high-water entries are worth listing because they bear on how to read the new claim.

Trivy (February 2026). Initial supply-chain compromise via an incomplete credential rotation after a minor breach at Aqua Security. Attackers got into the aqua-bot service account and force-pushed malicious code across 76 of 77 version tags. The Trivy payload evolved across three versions — a monolithic credential-harvest bash script first, a 15-line modular loader second, then CanisterWorm with self-replication, Docker API scanning, and SSH key harvesting. The first-stage harvest pulled AWS, GCP, and Azure tokens straight out of CI environment variables and instance-metadata, including bypassing GitHub Actions secret masking via direct process-memory reads.

Checkmarx (March 23, 2026). Downstream of Trivy. Checkmarx employees had Trivy in their toolchain; their credentials were harvested; TeamPCP used them to access Checkmarx’s private GitHub repositories on March 23 and to publish malicious code into Checkmarx artifacts. On April 22, the same access path was used to push malicious Docker images and extensions for KICS, Checkmarx’s own security scanner — credential, key, token, and config theft. On April 26, LAPSUS$ — not TeamPCP themselves — published roughly 96 GB of Checkmarx data on dark-web and clearnet portals. That handoff matters: TeamPCP demonstrably hands stolen GitHub data to a different actor for publication when it suits them.

European Commission (March 19–28, 2026). Misused AWS API key, traced back by CERT-EU to the same Trivy compromise vector — the Commission was unknowingly running a TeamPCP-tainted Trivy build during the relevant period. About 92 GB of compressed data exfiltrated, including email content from 42 internal clients and at least 29 EU entities. Sold through ShinyHunters’ dark web marketplace on March 28, not ransomed. Same disposition pattern: TeamPCP exfiltrates, a partner sells.

LiteLLM (early 2026). AI gateway compromise documented by Trend Micro, providing a foothold into AI/ML pipelines and the API keys (OPENAI_API_KEY, ANTHROPIC_API_KEY, and the rest of that bucket) sitting in environment files near them.

Sprawling npm pivot. Using harvested npm tokens, the group infected an additional 47 packages across @emilgroup, @opengov, and @v7 namespaces in under sixty seconds via malicious pre/post-install scripts. That was followed by the broader Shai-Hulud worm activity that ultimately hit 170+ npm packages collectively downloaded 200+ million times per week, plus two PyPI packages.

Shai-Hulud open-sourced (May 13, 2026). The group published Shai-Hulud’s source code to GitHub itself, with deployment instructions, using what appear to be compromised GitHub accounts as the host substrate. The community-tracked count moved from two repositories to five over a couple of days, with forks expanding alongside.

Mandiant’s running estimate. Over 1,000 SaaS environments demonstrably impacted, projected to 5,000–10,000 by the time the dust settles. 300+ GB of data, 500,000+ credentials cumulative across the campaign.

Novel C2. CanisterWorm uses an Internet Computer Protocol (ICP) canister as a dead-drop C2 — the first publicly documented abuse of decentralized blockchain infrastructure as the C2 substrate for a real-world campaign. The C2 domain tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io is the one to grep your egress logs for if you don’t already. The legacy second-stage domains (scan.aquasecurtiy[.]org, checkmarx[.]zone, models.litellm[.]cloud) are still worth retroactive searches; campaigns this size leave artifacts in long-retention indices that didn’t trip alerts the first time.

So: real group, real exfiltration, real source-code theft from at least one major vendor’s private GitHub, demonstrated handoff to partners for monetization, and a public posture as of the last week that explicitly courts the limelight (open-sourcing their own malware is the move of a crew comfortable with attention). The base rate for “TeamPCP says they did a thing and the thing did happen in some form” is, on the recent record, high.

The base rate for “the thing they say they did is exactly the thing they did” is lower, and worth being honest about.

Reading the listing itself

The claim as posted has four facts in it: scale (“approximately 4,000 private repositories”), scope (“GitHub’s main platform and internal organizations”), action (“compromise and sale”), and a date (“observed May 19, 2026”). Each of those bears on how plausible the underlying compromise is, and each is the sort of thing inflated-or-repackaged claims tend to get wrong in specific ways.

The scale number is round and large. “Approximately 4,000” is the kind of figure that signals the actor was counting repo objects rather than measuring scope. GitHub’s internal-repo population is much larger than 4,000 across the company, much smaller than 4,000 across the actual core-platform monorepo set, and ambiguous everywhere in between. A claim of “approximately 4,000” without a breakdown by org is either an exfiltrated gh repo list against some compromised account’s scope — in which case the relevant question is whose access did they have — or it is a round-numbered exaggeration of a smaller real haul. The former is the worse case operationally because it means a specific employee or service account’s blast radius was 4,000 repos and someone pulled the trigger on all of them.

“Main platform and internal organizations” is broad and unverifiable from outside. GitHub-the-company runs on a substrate that includes the core Rails monorepo, a long list of supporting services, internal tooling repositories, and the many github and adjacent org spaces with their varying access tiers. “Main platform” most naturally reads as a claim of access to repos that build production github.com. If true, that is a strategic compromise on the order of the Microsoft / SolarWinds source-code disclosures in scope and consequence. “Internal organizations” reads as the wider corporate-tooling perimeter — also valuable, considerably less unprecedented. The listing collapses both into one figure, which is the language of marketing a sale, not the language of describing an incident.

Sale, not leak. The dispositions worth distinguishing here are sale (private buyer, possibly never public), leak (public dump, often via partner), ransom (private demand against the victim), and announcement-only (public claim with no follow-through). TeamPCP’s record on the major hauls is exfiltrate-then-partner-publishes: Checkmarx → LAPSUS$, EU Commission → ShinyHunters. A direct sale listing is consistent with a haul they are still monetizing, with a haul they want to make noise about ahead of a partner-publish, or with a haul they cannot actually back up at sample volume.

“Observed May 19” places the listing fresh. The compromise itself, if real, is presumably older — exfiltration takes time and access windows are not advertised the same day they are opened. The gap between exploitation and listing is one of the better fingerprints for the underlying truth, but is not publicly known here.

Independent verification work to watch for over the next several days, in roughly the order it tends to land: a sample drop large enough that a non-buyer can grep it against known GitHub public-mirror artifacts; GitHub itself issuing a confirm-or-deny (their pattern on prior third-party claims has been to confirm fast when the claim is false and to confirm carefully when it is true); a researcher tying the sample to a specific compromised account or OAuth app; a partner-actor publication that escalates the listing into a leak. If none of those happen within roughly a week, the working assumption shifts toward “inflated or repackaged” — though “no evidence yet” is not “evidence of no.”

The operational read, regardless of which way verification lands

The thing that makes this listing operationally meaningful even before it’s verified is that the work you do in response is the same work you should be doing because of TeamPCP’s verified March–May activity. The supply-chain exposure does not get worse if the GitHub-platform claim is true; it is already at the level where the GitHub-platform claim would be additive rather than disruptive. Concretely:

Your dependency on GitHub-as-an-issuer is the exposure. Every CI/CD pipeline that authenticates with a GITHUB_TOKEN, every OIDC trust relationship between GitHub Actions and a cloud account, every webhook-triggered deploy, every PAT in someone’s ~/.netrc. If the platform itself were ever to be compromised in a way that produced backdoored runner binaries, signed-but-malicious release artifacts, or modified OIDC issuer behavior, the impact path runs straight through these. None of those would change as a result of this specific listing being verified; they are the impact paths to harden against the category of risk this listing represents.

Rotate what you’ve had any reason to rotate already. PATs, Actions secrets, OIDC federation trust bindings, SSH keys associated with deploy users, npm tokens, container registry pull credentials. The pattern from the Trivy / Checkmarx fallout is that organizations that rotated aggressively in March were less exposed when the April publications happened; the ones that waited for confirmation rotated under deadline pressure. The cost of an unneeded rotation is help-desk hours and a CI run; the cost of a needed-but-deferred rotation is a public dump with your repo names in the filenames.

Trust the publishers, not the actors, for sample validation. When a sample drops, it will likely come either as a redacted slice on the listing itself or as a partner-published archive. The published-archive path is the more diagnostic one — partners publishing means the actor’s claim has cleared their own internal credibility filter. The redacted-slice path is much more often consistent with smaller real hauls being marketed to look large.

Watch your OAuth app inventory. TeamPCP’s recurring pattern is OAuth-or-token-driven access, not credential-stuffing. Every shop with mature GitHub posture has an organization-level OAuth app and PAT inventory; not every shop uses it. This is the week to actually walk the inventory, particularly for apps with repo scope that haven’t been touched in months. The post-Checkmarx forensic narratives all featured a long-stale OAuth grant somewhere upstream.

Treat any GitHub-issued public statement as authoritative; treat actor channels as one-sided. Including the actor’s eventual sample drop. The pattern across the year’s larger claimed breaches is that the actors choose what to show, and the chosen sample is the strongest evidence they have rather than a representative slice. Whatever ends up in the sample is the floor of what was taken if the claim is true, not the ceiling, and not the mean.

What an attentive SOC actually queries this week

The detective work that costs nothing and shortens the lag time if any of this lands closer to home than the listing implies:

A retrospective hunt against your GitHub audit log for oauth_authorization.create and oauth_application.transfer events older than thirty days that no one currently remembers granting. The Trivy fallout exposed how many OAuth approvals from 2023 and 2024 were still active in 2026 with repo scope and no business reason. Sort the results by approval age descending and walk the list with the original requester; if the requester isn’t an active employee or the app isn’t recognized, revoke. The 800-53 hook is AC-2(7) — privileged user account management — but the real motivator is that this is the cheapest thing to do with the highest payoff under this threat model.

A query against your CI environment for any reference to the known TeamPCP C2 substrates: the ICP canister domain on egress logs, the legacy aquasecurtiy[.]org / checkmarx[.]zone / litellm[.]cloud typo-domains in CI build output, and Trivy / KICS binary hashes outside the publisher-attested set. The fact that a build job from February didn’t alert then doesn’t mean the artifacts aren’t sitting in your registry now. Container registry retention is longer than most teams think.

An honest re-look at which of your secrets actually rotated when the Trivy / Checkmarx news hit. Not “what’s the policy”; what actually rotated. The gap between the rotation policy and the rotation completion is the gap an actor with stale credentials operates inside.

A check on your dependency-pinning posture for npm and PyPI packages in active use. If you’re still resolving latest for anything in production, the Shai-Hulud spread is the case study for why you stop doing that on Monday morning. Lockfile integrity hashes, registry mirrors with allowlisted publishers, and a CI gate that fails on transitive-dependency churn from publishers you don’t recognize are all mundane controls that hold up against the actual TTPs in evidence.

Control mapping

The 800-53 surface this work touches:

The one to push hardest on internally is SR-3 plus IR-4. Most shops’ supply-chain risk posture is a vendor questionnaire reviewed annually; the campaign-of-record has shown the relevant time horizon is days, not years, and the relevant question is “did our upstream tooling get compromised in the last quarter” rather than “did the vendor pass our procurement checklist in the last year.” Most shops’ IR playbooks assume the victim notices the breach; the TeamPCP partner-publish pattern explicitly does not. The IR criteria that activate on third-party leak-aggregator publication, rather than on internal detection, are the ones that matter for this threat model.

The honest closing read

The May 19 listing might be a real fresh compromise of GitHub itself, in which case the next 72 hours will be unpleasant and the operational response is roughly “everything in the section above, immediately, with the dial turned up.” It might be a repackaged subset of prior hauls — particularly Checkmarx-style downstream-of-developer-tooling compromises that include enough internal-GitHub-account artifacts to look like a platform breach when listed in the language of a sale — in which case the operational response is the same work at a less frantic pace. It might be inflated to draw bidders. It might be theatre.

What it cannot be — given the actor’s verified March-through-May track record — is dismissible. TeamPCP has earned the verification cycle they’re about to get. The defensive posture that doesn’t depend on which way the verification falls is the one worth investing in this week. The supply-chain exposure that the campaign has surfaced does not become smaller if this specific claim turns out to be theatre, and does not become qualitatively different if it turns out to be real. The thing you would do tomorrow morning is the same thing in either world. Do it.

Watch for sample drops, watch for partner publications, watch for a GitHub statement. Until any of those land, take the listing as a useful prompt rather than a confirmed event, and use the prompt.

Sources

• HackRisk.io — Hackmanac cyber threat monitoring feed: https://hackrisk.io/
• Unit 42 (Palo Alto Networks), Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure: https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/
• Trend Micro, Analyzing TeamPCP’s Supply Chain Attacks: Checkmarx KICS and elementary-data in CI/CD Credential Theft: https://www.trendmicro.com/en_us/research/26/e/analyzing-teampcp-supply-chain-attacks.html
• Trend Micro, Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise: https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html
• SANS Institute, When the Security Scanner Became the Weapon: Inside the TeamPCP Supply Chain Campaign: https://www.sans.org/blog/when-security-scanner-became-weapon-inside-teampcp-supply-chain-campaign
• Wiz, Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild: https://www.wiz.io/blog/tracking-teampcp-investigating-post-compromise-attacks-seen-in-the-wild
• Okta Threat Intelligence, Defending against TeamPCP software supply chain attacks: https://www.okta.com/blog/threat-intelligence/defending_against_team_pcp_software_supply_chain_attacks/
• Cyble, TeamPCP Threat Actor Profile: https://cyble.com/threat-actor-profiles/teampcp/
• Flare, Threat Alert: TeamPCP, An Emerging Force in the Cloud Native and Ransomware Landscape: https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware
• BleepingComputer, Checkmarx confirms LAPSUS$ hackers leaked its stolen GitHub data: https://www.bleepingcomputer.com/news/security/checkmarx-confirms-lapsus-hackers-leaked-its-stolen-github-data/
• Checkmarx, Update: Ongoing Checkmarx Supply Chain Security Incident: https://checkmarx.com/blog/ongoing-security-updates/
• Cyberpress, Checkmarx Confirms GitHub Repository Data Leaked and Published on Dark Web: https://cyberpress.org/checkmarx-confirms-github-repository-data-leaked-and-published-on-dark-web/
• The Record (Recorded Future News), EU cyber agency attributes major data breach to TeamPCP hacking group: https://therecord.media/european-commission-cyberattack-teampcp
• The Register, Malware crew TeamPCP open-sources its Shai-Hulud worm on GitHub: https://www.theregister.com/security/2026/05/13/malware-crew-teampcp-open-sources-its-shai-hulud-worm-on-github/5239319
• SC Media, TeamPCP releases ‘vibe coded’ Shai-Hulud source code, issues challenge: https://www.scworld.com/news/teampcp-releases-vibe-coded-shai-hulud-source-code-issues-challenge
• OX Security, Shai-Hulud Goes Open Source: Malware Creators Leak Their Own Code to GitHub: https://www.ox.security/blog/shai-hulud-open-source-malware-github/
• Cybersecurity News, Hackers Compromise 170 npm Packages to Steal GitHub, npm, AWS, and Kubernetes Secrets: https://cybersecuritynews.com/hackers-compromise-170-npm-packages/
• Cybersecurity Magazine, TeamPCP’s Mini Shai-Hulud Campaign Breaches TanStack npm: https://cybermagazine.com/news/teampcps-mini-shai-hulud-campaign-breaches-tanstack-npm
• Saptang Labs, TeamPCP: The 72-Hour GitHub Supply Chain Blitz: https://saptanglabs.com/the-72-hour-blitz-how-teampcp-weaponized-github-to-steal-enterprise-credentials/
• SecurityWeek, Critical GitHub Vulnerability Exposed Millions of Repositories: https://www.securityweek.com/critical-github-vulnerability-exposed-millions-of-repositories/