What is known#
SANS ISC reports that the TeamPCP supply-chain campaign remained active through 2026-05-24 and expanded across multiple developer package ecosystems in the same week.
The reported activity touches three separate trust surfaces:
- a malicious Nx Console VS Code extension build on the Visual Studio Marketplace
- trojanized versions of Microsoft’s officially published Azure Durable Functions Python SDK on PyPI
- a large npm wave through the @antv ecosystem
The common thread is not one vulnerable library. It is the abuse of legitimate distribution paths. Publisher accounts, verified-publisher badges, package ecosystems, auto-update behavior, and CI/CD credentials all become part of the attack chain.
SANS describes this as three escalations stacked inside one week. The most serious reported outcome is the GitHub internal breach, where a malicious extension build was identified as the root of an intrusion that exfiltrated about 3,800 GitHub-internal repositories. The source material says reporting suggested no customer-tenant data was affected.
The details below rely on the SANS ISC diary and the reporting it summarizes. Some claims are attributed to independent reporting in the source material, but the collected text does not preserve every outbound reference. Treat those claims as reported, not independently verified here.
The GitHub intrusion started with a poisoned extension#
The first major item is the Nx Console VS Code extension.
According to the source, a malicious build of Nx Console v18.95.0 was published to the Visual Studio Marketplace on 2026-05-18. The publisher was listed as nrwl.angular-console. The extension had a verified-publisher badge and roughly 2.2 million installs. It was reportedly live for about 18 minutes before removal.
That short window still mattered.
SANS reports that on a GitHub employee endpoint, the extension auto-updated during the exposure window. The malicious build exfiltrated developer secrets and was then used to move laterally through GitHub’s internal CI/CD environment. GitHub CISO Alexis Wales publicly named the Nx Console extension as the root of the intrusion, according to the source.
The intrusion reportedly exfiltrated approximately 3,800 internal GitHub repositories before containment. OpenAI, Grafana Labs, and Mistral AI were named as downstream victims whose developers had auto-update enabled.
The important point is not just that a popular extension was poisoned. It is how little friction existed between a compromised publish path and developer machines that trusted the update stream.
A verified-publisher badge did not mean the specific release was safe. It meant the marketplace had confidence in the publisher identity. TeamPCP appears to have exploited the gap between those two claims.
Microsoft’s durabletask package was also trojanized#
The second item is more uncomfortable because the package was officially Microsoft-published.
The source says three malicious versions of Microsoft’s Azure Durable Functions Python SDK, durabletask, were published to PyPI on 2026-05-19. The affected versions were 1.4.1, 1.4.2, and 1.4.3. The package was described as having roughly 417,000 monthly downloads.
The malicious versions were reportedly yanked within hours. That does not remove risk for teams that installed them during the window.
SANS says the dropper was injected into the package’s Python source files. That means importing the SDK was enough to execute the malicious code. No special runtime behavior or manual execution step is described as required.
The reported second stage targeted credentials across major developer and cloud environments, including AWS, Azure, GCP, HashiCorp Vault, 1Password, and Bitwarden. The source also says independent reporting characterized the second-stage payload as carrying a Linux disk wiper.
That last claim matters, but should be handled carefully. The collected source says the payload was reported as carrying a Linux disk wiper. It does not provide the full technical analysis in the pasted material. Still, if accurate, that would move this campaign beyond credential theft and propagation into more destructive territory.
For defenders, the operational trigger is clear enough: if any environment installed durabletask 1.4.1, 1.4.2, or 1.4.3 on 2026-05-19, treat that environment as exposed. That includes CI jobs, build containers, short-lived runners, developer laptops, and test infrastructure.
Ephemeral does not mean harmless. A short-lived runner can still leak a long-lived token.
The @antv npm wave shows campaign scale#
The third item is the @antv npm ecosystem.
SANS reports that on 2026-05-19 a compromised maintainer account, identified as atool, published a third Mini Shai-Hulud wave across @antv packages. The reported count is 639 malicious versions across 323 packages.
The affected set included echarts-for-react, described as having roughly 1.1 million weekly downloads, and size-sensor, described as having roughly 4.2 million weekly downloads.
The source says this was the largest single-hour Shai-Hulud burst the campaign had produced by package count. It also notes that 42 malicious packages were observed displaying fake Sigstore verification badges in the npm UI.
That badge detail is part of the same pattern as the VS Code extension case. Security and authenticity signals help, but they are not the same as release integrity. A valid-looking interface can still present a malicious artifact if the publishing path was compromised or the trust signal itself was spoofed.
The source material says the obfuscated JavaScript payload ran during install and harvested more than 20 credential classes, including GitHub and npm tokens, AWS keys, and cloud credentials. The pasted text cuts off before the full list, so this article should not infer more than that.
The defensive conclusion is still direct: package install scripts remain a high-risk execution path. They run at the exact point where developer machines and CI systems often have access to secrets.
Why this matters#
This campaign is not only about malicious packages. It is about chained trust.
A developer installs a package because it comes from a known ecosystem. A marketplace shows a verified publisher. A CI runner imports an official SDK. An editor extension auto-updates because the extension was already trusted. A token harvested in one wave becomes a publish credential in the next.
Each step is individually plausible. Together they create a supply-chain path that crosses npm, PyPI, VS Code extensions, GitHub, cloud accounts, and CI/CD.
The GitHub case is especially important because the reported chain ties earlier harvested credentials to a later publish event. If that account holds, TeamPCP did not just steal secrets. It reused them to poison a new distribution point and reach a higher-value environment.
That is the model defenders should assume now: a compromised token is not only an access risk. It may become a software distribution risk.
What teams should check now#
Start with exposure windows and affected package names.
For VS Code environments:
- check whether Nx Console v18.95.0 was installed or auto-updated around 2026-05-18
- identify developer endpoints that had the extension during the reported 18-minute window
- rotate credentials available to those endpoints
- review CI/CD access tied to those users or machines
For Python environments:
- check whether
durabletask1.4.1, 1.4.2, or 1.4.3 was installed on 2026-05-19 - treat import-time execution as sufficient for compromise
- include CI runners, containers, build images, caches, and developer virtual environments in the search
- rotate cloud, registry, vault, and source-control credentials that may have been present
For npm environments:
- review installs from the @antv ecosystem around 2026-05-19
- inspect lockfiles and package manager logs for the reported malicious version burst
- do not rely on UI badges alone as proof of safety
- review install-script execution in CI and developer workflows
For all affected environments, credential rotation should not stop at the most obvious token. The reported payloads targeted developer identity, package publishing, cloud access, password managers, and CI/CD secrets. Rotate what the environment could reach, not only what the malicious package was known to name.
What not to overclaim#
Do not treat every install of these projects as compromised. The issue is tied to specific malicious versions and narrow publication windows, based on the source material.
Do not claim customer GitHub data was affected. The source says reporting suggested no customer-tenant data was affected.
Do not assume verified-publisher programs are useless. They solve part of the identity problem. They do not prove every future release is safe.
Do not assume yanked packages remove the incident. Yanked packages stop new normal installs. They do not clean old build caches, developer environments, CI images, private mirrors, or artifacts already produced during the exposure window.
The practical lesson is narrower and stronger: install-time trust needs release-level verification, not only publisher-level reputation.