TeamPCP: A Valid Signature That Certified Crypto Malware

Crypto was built on a promise: "don't trust, verify." In May 2026, an npm worm produced a perfectly valid cryptographic signature — certifying malware. The group TeamPCP poisoned Nx Console, the official VS Code extension (2.2 million installations), and unleashed Mini Shai-Hulud, the first documented worm to self-propagate with authentic SLSA Build Level 3 provenance (signed origin). GitHub confirmed the exfiltration of approximately 3,800 of its internal repositories in less than 20 minutes. But the data point that matters for crypto isn't that: it's that cryptographic attestation — the very type of proof upon which all on-chain trust is built — ceased to guarantee anything. And it is not an isolated case: it is the latest link in an eight-year line of supply chain attacks specifically targeting crypto. We say this without alarmism: the payload sweeps wallet paths, but as of June 1, there is no postmortem documenting DeFi funds stolen by this campaign. It is a confirmed vector, not a consummated loss — and previous history explains why it should be taken seriously.

What exactly happened in May 2026?

On May 11, 2026, supply chain security teams detected the first wave of a worm infecting npm packages: more than 170 compromised packages, including components from widely used projects like TanStack and Mistral AI libraries. On May 12, the worm's source code was briefly published in a public GitHub repository before being removed — material that served as the basis for subsequent forensic analysis.

The qualitative leap came on May 18. TeamPCP published a malicious version (v18.95.0) of Nx Console, the official VS Code extension for the Nx monorepo, with over 2.2 million installations. The poisoned version was available in the VS Code Marketplace for a very short window: the official Nx postmortem estimates it at 11 minutes and the CISA alert at 18 — in any case, less than 20 minutes. In Open VSX (the open registry used by editors like Cursor or VSCodium), the window lasted about 36 minutes. More than enough time for automatic updates to push it to an unknown number of developer machines.

On May 19, GitHub confirmed the exfiltration of approximately 3,800 of its own internal repositories — a figure claimed by the attacker and provisionally validated by the platform. GitHub clarified that customer repositories were not affected. That same day, a second wave of the worm was unleashed against packages in the @antv family (AntDesign's data visualization suite), bringing the total to over 500 compromised packages in that wave. The figure of 518 million circulating corresponds to the total cumulative historical downloads of the affected packages, not downloads of the malware.

How did the attack work, step by step?

The elegance of the attack lies in chaining legitimate trust at every link. The sequence, reconstructed from StepSecurity and OX Security bulletins and the Nx postmortem:

1. Poisoned extension. The developer installs or updates Nx Console from the official Marketplace. The extension has a valid signature and comes from the correct publisher. Upon activation, the malicious version executes code on the developer's machine with the same permissions as their editor session.
2. CI/CD token theft. Many repositories use GitHub Actions with OIDC tokens (OpenID Connect: short-lived credentials a pipeline obtains to authenticate without static secrets) and npm publishing tokens. The payload searches for these credentials in the environment and project configuration files: environment variables, .npmrc files, and cached Actions tokens.
3. Worm propagation. With a valid npm publishing token, the malware doesn't need to wait for another human victim. It republishes trojanized versions of the packages that the token controls, and those packages in turn infect whoever installs them. This is the property that turns a localized incident into a worm: self-replication through the dependency network.
4. Valid provenance signature. Here is the innovation that is truly frightening. Mini Shai-Hulud generates authentic SLSA Build Level 3 attestations for the malicious packages. The provenance chain that npm displays as proof that a package was built in a trusted pipeline was cryptographically correct — it just happened to be certifying malware. The signature wasn't forged: it was issued by a hijacked pipeline.
5. Credential and wallet sweep. The payload scans the disk for cryptocurrency wallet paths — Bitcoin, Ethereum, and Monero files, and directories for applications like Exodus, Electrum, and Atomic — in addition to CI/CD keys, cloud tokens, and deployment secrets. This is what turns a generic supply chain attack into a specific threat for those developing in Web3.

Why is this attack specifically dangerous for Web3 devs?

A traditional application developer who suffers this compromise loses, in the worst case, corporate secrets and access to company infrastructure. A Web3 developer has assets on the same machine, and often in the same project tree, that are bearer instruments.

The Web3 equivalent of "stealing the production password" is stealing the private key that signs a contract deployment, or the seed of a protocol's treasury wallet. There is no fraud department to reverse the transaction nor support to freeze the account: if the key is leaked and the attacker signs, the funds are gone. The paths that the Mini Shai-Hulud payload tracks — Exodus, Electrum, Atomic, Ethereum, and Bitcoin keys — are exactly what a crypto dev has on hand to test, deploy, and operate.

Added to this is the pipeline risk. If your library's npm publishing token is leaked, the attacker doesn't just steal from you: they trojanize your package and deliver it to all your users with your signature. For a DeFi project whose SDK library is consumed by other dapps, this means unknowingly becoming the vector that compromises third parties. The reputational and trust damage is difficult to reverse.

The honest distinction: as of June 1, 2026, there is no public postmortem documenting stolen DeFi funds attributable to this campaign. The vector is confirmed by payload analysis; the theft of crypto assets through it is an active risk, not a reported fact. Treating it as imminent is prudent; claiming it has already emptied treasuries is false.

Is this new? The lineage of supply chain attacks against crypto

No. What makes Mini Shai-Hulud relevant is not that it is unprecedented, but that it is the highest rung on a ladder that crypto has been climbing since 2018. The software supply chain — npm packages, libraries that sign transactions, SDKs that load dapps — has been a recurring target precisely because it connects directly to money. These are the milestones:

The theft column teaches two things. First: scale and damage do not go hand in hand. The September 2025 attack touched packages with 2.6 billion weekly downloads and took cents; Ledger drained over half a million dollars in less than two hours with a much smaller library because it was plugged directly into dapp signatures. What decides the loot is not how many machines you infect, but how many have a key that moves money within reach. Second: sophistication does scale. Copay waited passively for a wealthy victim; Shai-Hulud self-propagates; Mini Shai-Hulud, furthermore, signs its own malware with an attestation that the system accepts as good.

The trust paradox: when a valid signature certifies malware

Here is the blow that should make crypto more uncomfortable than the theft of 3,800 repositories. The software industry built SLSA and npm provenance attestations as a response to SolarWinds: the idea was that you could cryptographically verify that a package was built in a trusted pipeline, without having to trust anyone's word. It is, point for point, the same philosophy that sustains crypto — "don't trust, verify," verification replaces trust.

Mini Shai-Hulud did not break that verification: it co-opted it. Its malicious packages carry an authentic, cryptographically correct SLSA Build Level 3 provenance signature because it was issued by a real pipeline — it just happened to be hijacked. The verification passes. The proof is valid. And it certifies malware. The lesson is unpleasant and applies directly to any attestation-based system, including much of the on-chain scaffolding: a valid signature proves where something comes from, never that it is honest. When we confuse "verified" with "secure," cryptography stops protecting us and starts giving us a false, signed sense of security.

How does it differ from SolarWinds?

The SolarWinds attack (2020) is the mandatory reference for software supply chains. The comparison helps measure how much the bar has changed in six years.

Two differences matter more than the others. The first is self-replication: SolarWinds depended on victims installing a specific update; Mini Shai-Hulud spreads on its own every time it captures a publishing token, without waiting for human intervention. The second is valid provenance: the industry built SLSA and npm attestations precisely as a response to SolarWinds, so you could verify that a package came from a trusted pipeline. TeamPCP didn't break that defense — they co-opted it. An authentic provenance signature ceases to be a guarantee when the pipeline issuing it is already compromised.

Who is TeamPCP and why does attribution matter?

Google Threat Intelligence (Mandiant) tracks the group as UNC6780. Unlike SolarWinds, attributed to nation-state espionage, TeamPCP has financial motivation: it monetizes access through the ransomware group Vect, according to analysis gathered by SANS Internet Storm Center and CSA Labs. The group has been latent since approximately May 24; there are no new waves dated after that time that can be confirmed.

The institutional timeline came full circle at the end of May. On May 27, the Nx Console vulnerability — registered as CVE-2026-48027, with a CVSS score of 9.8 in the NVD and 9.4 in the CISA assessment — was added to CISA's KEV (Known Exploited Vulnerabilities) catalog, the list of flaws with confirmed active exploitation. On May 28, CISA issued a formal alert regarding the Nx Console and GitHub repository compromises. Separately, CERT-EU documented the European Commission as a downstream victim through a previous compromise by the same group in the Trivy tool (March 2026), showing the actor's institutional reach beyond the crypto ecosystem.

How do I audit my Web3 development environment right now?

This is the actionable block. If you develop in Web3 and use VS Code, npm, or CI/CD pipelines, go through these points before reading further.

• Audit installed VS Code extensions. Review the list of extensions and their versions. If you have Nx Console, confirm you are not on v18.95.0; Nx published a clean version after the incident. Beyond this specific extension, disable automatic extension updates in environments where you handle sensitive keys: silent updates were precisely what distributed the payload in less than 20 minutes.
• Verify the provenance of your npm dependencies — with skepticism. Run npm audit signatures and review provenance attestations, but assume that valid provenance is no longer sufficient proof on its own. A useful clue reported in this case: in the @antv wave on May 19, over 300 versions were published in a burst of about 22 minutes; dependency analysis tools like Socket.dev or Phylum detect such mass-publishing patterns in real-time.
• Isolate CI/CD keys from publishing permissions. The token that builds and tests should not be the same one that publishes packages. Use granular npm tokens with minimal scope, prefer short-lived OIDC over long-lived static secrets, and configure trusted publishing where the registry supports it. A stolen build token that cannot publish won't turn your library into a worm.
• Remove wallet keys from the development environment. Do not store production seeds or deployment keys in project files, editor environment variables, or secret managers that the VS Code session can read. Use a hardware wallet or an isolated signer for any operation with real value, and disposable, fundless wallets for testing.
• Rotate credentials if you have the slightest doubt. If you installed or updated Nx Console between May 11 and May 19, treat all credentials accessible from that machine as compromised: npm and GitHub tokens, cloud keys, and especially any wallet keys that touched that machine. Rotation is cheap compared to assuming nothing happened.

What signs indicate an extension or package is compromised?

There isn't always a published CVE when you need it. What made this incident difficult to detect, according to Microsoft and StepSecurity analyses, is that it didn't rely on unknown external infrastructure but on trusted platforms — the official Marketplace itself, GitHub, the npm registry — exactly where security tools usually lower their guard. That's why the recommendation from response teams (CISA, CERT-EU) was not to look for a specific signature, but to review unusual access and activity on that trusted infrastructure during the May 18-19 window.

The most reliable ecosystem indicator in this campaign was temporal: a burst of new versions published almost simultaneously across many packages from the same author or organization — the pattern of a stolen publishing token republishing en masse, like the 300+ versions of @antv in ~22 minutes. This is a pattern that dependency analysis tools flag in real-time.

The practical defense is not to detect day zero, but to reduce the blast radius: manual and reviewed updates on machines with keys, minimal permissions, and a sharp separation between the machine where you write code and the place where keys that move money live.

What lessons remain for Web3 development?

Three data points from the incident itself concentrate the lesson. The first is reaction time: CISA took nine days to issue the formal alert (from the May 19 compromise to the May 28 alert), and CVE-2026-48027 didn't enter the KEV catalog until the 27th. Anyone who waited for the official notice to act was exposed for over a week; defense cannot depend on institutional cadence.

The second is scope: CERT-EU documented the European Commission as a downstream victim of a previous compromise by the same group in the Trivy tool, dated March 2026. In other words, UNC6780 had been operating in the same supply chain for at least three months before the industry connected the dots. The surface of a crypto project no longer ends at the audited contract: it begins at the editor, the package registry, and the deployment pipeline.

The third is the one that teaches the most because it's the one that worked: according to GitHub, customer repositories were not affected precisely because the compromised access did not reach them — credential segregation contained the damage. That is the frontier that separates an annoying breach from an irreversible loss. SLSA signatures and npm attestations are still useful, but TeamPCP co-opted them: they prove a package came from a pipeline, not that the pipeline was honest. Defense is shifting toward minimal permissions and the assumption of compromise by default — and never leaving keys that move value within reach of an editor.

Sources and links: Official Nx Postmortem · StepSecurity (compromised extension) · SecurityWeek (GitHub confirms 3,800 repos) · The Record (customers unaffected) · OX Security (Mini Shai-Hulud) · SANS ISC (UNC6780 / Vect) · CVE-2026-48027 · CISA Alert (May 28) · npm (event-stream/Copay, 2018) · Ledger Connect Kit (2023) · @solana/web3.js (2024)