Source: SANS Internet Storm Center — https://isc.sans.edu/diary/rss/33016
What changed#
The TeamPCP supply-chain campaign appears to have crossed a new line in late May 2026. According to the SANS Internet Storm Center summary, the activity now spans multiple developer package ecosystems at the same time. The reported incidents include a malicious VS Code extension build tied to GitHub’s internal breach, trojanized versions of an officially Microsoft-published Python SDK on PyPI, and a large npm wave across the @antv ecosystem.
The point is not that package poisoning is new. It is that several trust shortcuts failed in the same week.
A verified publisher badge did not make a Visual Studio Marketplace extension safe. An official Microsoft publisher path did not prevent a malicious PyPI release. Package UI signals and ecosystem trust marks did not stop users from being exposed during short publish windows.
That is the useful lesson for security teams. The campaign is not only abusing open registries. It is abusing the assumptions developers use to move fast.
The GitHub intrusion path#
The most serious reported escalation involves the Nx Console VS Code extension.
SANS cites public statements from GitHub CISO Alexis Wales naming a malicious Nx Console build, version 18.95.0, as the root of an intrusion that exfiltrated about 3,800 GitHub-internal repositories. The extension was published under the nrwl.angular-console publisher and carried a verified-publisher badge. The source summary says it was live on the Visual Studio Marketplace for roughly 18 minutes.
That short window was still enough.
According to the source material, a GitHub employee endpoint auto-updated to the malicious extension. The extension then exfiltrated developer secrets. Those secrets were reportedly used to move laterally through GitHub’s internal CI/CD environment. SANS says reporting suggests no customer-tenant data was affected, but the internal repository exposure was still large.
The source also states that OpenAI, Grafana Labs, and Mistral AI were named as downstream victims whose developers had auto-update enabled.
The important detail is the credential chain. SANS says reporting ties credentials harvested in a May 11 TanStack wave to the May 18 Nx Console publish. If accurate, this is a public example of the campaign using loot from one supply-chain compromise to execute the next one through a trusted maintainer or publisher path.
That changes the defensive model. A malicious package is no longer only a one-time payload. It can become a credential-harvesting step for the next trusted release.
The Microsoft-published PyPI package#
The second reported escalation involves Microsoft’s Azure Durable Functions Python client, referenced in the source as durabletask.
SANS says three versions, 1.4.1 through 1.4.3, were trojanized on PyPI on 2026-05-19 and later yanked. The package is described as an officially Microsoft-published Python SDK with roughly 417,000 monthly downloads.
The source says the malicious dropper was injected into Python source files. That matters because import behavior can become execution behavior. If a build system, test runner, application process, or CI job imported the affected SDK versions, that may have been enough to trigger the malicious code.
The reported second-stage payload is described as a credential stealer and worm. It allegedly targets cloud and developer secrets across AWS, Azure, GCP, HashiCorp Vault, 1Password, and Bitwarden. The SANS summary also says independent reporting characterizes the second stage as carrying a Linux disk wiper.
That last point should be handled carefully. The source attributes the disk-wiper claim to independent reporting. It should not be treated as fully established beyond that attribution without reviewing the underlying technical analysis. But it is serious enough that affected environments should be handled as potentially compromised, not merely as package hygiene incidents.
The practical trigger is narrow but important: teams that installed or imported durabletask versions 1.4.1, 1.4.2, or 1.4.3 on 2026-05-19 should treat those environments as exposed. That includes ephemeral CI runners, build containers, developer laptops, test hosts, and automation jobs that pulled dependencies during the affected window.
The @antv npm wave#
The third reported wave hit the @antv npm ecosystem.
SANS describes it as a third Mini Shai-Hulud wave pushed through a compromised maintainer account named atool. The reported scale is 639 malicious versions across 323 packages. Packages named in the source include echarts-for-react, with roughly 1.1 million weekly downloads, and size-sensor, with roughly 4.2 million weekly downloads.
The payload is described as an obfuscated JavaScript file of about 499 KB that runs during package activity and harvests more than 20 credential classes. The source text names GitHub and npm tokens, AWS keys, and GCP and Azure tokens among the targeted material before cutting off.
SANS also says 42 of the malicious packages were observed displaying fake Sigstore verification badges in the npm UI.
Again, the defensive point is not subtle. Users were not only exposed through obscure packages. They were exposed through popular packages, known ecosystems, compromised maintainer access, and misleading trust indicators.
For teams that depend on @antv packages, the immediate question is not “did we intentionally install malware?” It is simpler: did any automated process resolve one of the malicious versions during the affected window, and did that process have useful credentials in scope?
Why this matters#
This campaign targets the soft center of modern development: credentials, automation, and implicit trust.
Developer ecosystems are built to reduce friction. Extensions auto-update. CI jobs pull fresh dependencies. Package managers trust publisher continuity. Registries show badges. Maintainers publish quickly. AI coding agents and local dev tools often sit near secrets because they need context to be useful.
TeamPCP appears to be using that design against itself.
The campaign’s reported pattern is especially dangerous because it compounds. One compromised package can steal tokens. Those tokens can enable the next malicious publish. The next publish can reach a larger or more trusted user base. Each step looks legitimate enough to pass through normal human filters until after execution.
This is why publisher verification should not be treated as install-time safety. It answers a narrower question: whether the publisher identity or account has some recognized status. It does not prove that a specific release was intentional, clean, or safe.
The same applies to official package ownership. A package published from an official account can still be compromised if the publishing workflow, maintainer credential, CI process, or registry access path is compromised.
What teams should check now#
Start with exposure mapping. Look for installs, updates, imports, or build logs involving the named packages and versions during the reported windows.
Check at least these areas:
- VS Code extension inventory for Nx Console version 18.95.0, especially on developer machines with access to internal repositories or CI/CD systems.
- PyPI dependency logs for
durabletaskversions 1.4.1, 1.4.2, and 1.4.3 on 2026-05-19. - npm lockfiles, artifact caches, and CI logs for affected @antv packages and the named packages
echarts-for-reactandsize-sensor. - Ephemeral runners and build containers that may have pulled dependencies and then been destroyed, leaving only logs or cache traces.
- Developer endpoints with auto-update enabled for IDE extensions.
- AI coding agent configuration files and local tool configs for persistence or unexpected credential access.
If exposure is plausible, rotate credentials. Do not wait for perfect certainty if the affected environment had registry tokens, cloud keys, GitHub tokens, npm tokens, vault credentials, or CI secrets available.
Credential rotation should include developer tokens and machine identities, not only obvious user passwords. In this kind of campaign, the useful loot is often automation-grade access.
What not to overclaim#
The source summary is strong, but it is still a collected incident view. Some details are attributed to public statements. Some are attributed to independent reporting. Some package counts and victim lists may change as registries, vendors, and researchers reconcile data.
Do not overstate unconfirmed blast radius. Do not assume customer data exposure where reporting says none is known. Do not assume every installation of a named package was affected outside the stated version and time windows.
But also do not underreact because the windows were short. Eighteen minutes is long enough for auto-update. Thirty-five minutes is long enough for CI. A single import can be enough if the malicious code sits in package initialization paths.
The durable lesson is clear: trust badges, official publishers, and familiar package names are not execution controls. They are metadata. Treat them that way.