When the security community first felt the tremors of the Shai-Hulud campaigns, there was a palpable sense of alarm. A "self-propagating worm" in the open-source ecosystem sounds, on paper, like the work of a sophisticated, nation-state adversary. It suggests zero-day exploits, advanced stealth mechanisms, and a highly coordinated infrastructure.
But that notion dissolves when you actually look at the mechanics. TeamPCP, the group behind these incidents, isn't redefining the frontier of cyber warfare. They are, quite simply, very good at exploiting the gaps in developer trust and the persistent "it works" mentality that governs modern CI/CD.
Their history is less about "sophisticated threat actor" and more about being an opportunistic force, harvesting leaked tokens, phishing maintainers, and abusing unpinned dependencies. They are the scourge of the open-source community, not because they are geniuses, but because they have successfully commoditized the most basic configuration failures that developers, time and again, fail to fix.
This article aims to strip back the mythology of the Shai-Hulud threat actors. By examining their actual tactics—from the initial token-scraping worms to the cascading pipeline exploits in packages like LiteLLM and TanStack—we can move away from treating them as monolithic geniuses and start viewing them for what they are: a clear signal that the open-source ecosystem is fragile, primarily because we continue to leave the digital equivalent of our front doors wide open.
This isn't just a technical problem; it's a structural one. If you want a deeper look at where the industry is struggling, take a look at our analysis on cybersecurity evolution. The rise of these automated threats makes it increasingly obvious that the old perimeter solutions are failing, and the new era of agentic tools requires much smarter protection—as discussed in securing autonomous agents.
For security teams, the TeamPCP attacks are a harsh reality check. We are operating in an environment where speed often dictates engineering culture, and security practices are frequently bolted on as an afterthought. TeamPCP has weaponized that speed, and until we change the underlying trust model of our supply chain, they will keep finding success.
The Mechanics of Shai-Hulud: 1.0 and 2.0
The initial Shai-Hulud campaigns were a masterclass in exploiting low-hanging fruit. When we talk about Shai-Hulud 1.0 (September 2025), we're not talking about custom exploit chains. We're talking about a self-replicating npm worm that made heavy, effective use of existing, benign tools like TruffleHog.
The Token Harvesting Game
The core of the 1.0 campaign was remarkably simple: the worm would search for leaked credentials—AWS keys, GCP service accounts, GitHub tokens, and, most importantly, npm publishing tokens—inside of packages.
Once it compromised a maintainer's account, it didn't just stop at one package. It used that token to find other packages maintained by that same account and published malicious new versions of them. These versions contained postinstall or preinstall scripts that would execute automatically upon installation. It was, in essence, a digital virus designed to replicate itself by compromising the trust of the very people meant to maintain the software. This pattern of exploiting trust bounds is reminiscent of other modern threats, such as the Miasma Worm, which targeted developer environments through self-replicating packages.
It got more malicious. The worm would also clone compromised private GitHub repositories as public ones, naming them something harmless-sounding like *-migration. This was a brazen attempt to exfiltrate proprietary code.
Shai-Hulud 2.0: The Destructive Pivot
By November/December 2025, the group was back with "Sha1-Hulud: The Second Coming." This campaign was not just about token theft; it had a more disruptive intent. Infecting nearly 800 npm packages—with the popular @asyncapi/specs package acting as the "patient zero"—the actors introduced more sophisticated anti-detection and, for the first time, destructive capabilities (data wipers targeting user directories).
This variant began utilizing the Bun runtime, hiding its malicious payloads inside setup_bun.js and bun_environment.js. By moving into a modern runtime like Bun, TeamPCP showed their ability to adapt to the latest developer tools, turning the speed and innovation of modern JS ecosystems against the developers themselves. It was no longer just about harvesting; it was about demonstrating reach and inflicting damage.
The lesson here is one we should have learned long ago: the repository is not inherently secure, even if it's "verified" by an official-sounding name or wide usage. If a maintainer's token is compromised, the integrity of everything they touch is effectively void.
March 2026: Cascading Pipeline Exploits
If the 2025 campaigns were a warm-up, the March 2026 attacks on LiteLLM and Telnyx were the main event. This was the moment TeamPCP pivoted from simple repository compromise to full-blown supply chain hijacking. They weren't just attacking the code; they were attacking the infrastructure that produced the code.
The LiteLLM and Telnyx Incident
The attacks on LiteLLM and Telnyx were a stark example of a cascading failure. The threat actor stole the LiteLLM CEO’s GitHub credentials, which provided them access not just to the source code, but to the entire CI/CD pipeline.
The critical misconfiguration was painfully common: unpinned dependencies in the CI/CD environment. The runner was using Aqua Security’s Trivy scanner, but crucially, it was not pinned to a specific version. TeamPCP was able to exploit this fact, exposing the PyPI publishing credentials in the process.
This wasn't an exploit of LiteLLM itself, but an exploit of the environment that LiteLLM trusted. Once the actors had those publishing credentials, they could push malicious versions of LiteLLM directly to PyPI, where they would be automatically pulled in by thousands of downstream users. This tactic of compromising ecosystem repositories is a growing hazard, closely mirroring recent alerts regarding 73 malicious packages targeting AI coding agents via credential harvesting scripts.
Telnyx suffered a similar fate. Their Python packages (versions 4.87.1 and 4.87.2) were infected by modifying the _client.py file to point to an external command-and-control (C2) server (83[.]142.209.203).
Targeting the Developer Experience
TeamPCP also directed their focus toward developer tools, hijacking Checkmarx VS Code plugins—specifically ast-result v2.53 and cx-dev-assist v1.7.0—which were listed on the Open VSX registry. The goal was again secrets exfiltration, using checkmarx[.]zone as their C2 server.
By compromising these plugins, TeamPCP was actively targeting the developer while they were coding. It’s a bold move that shows a clear understanding of where the most valuable secrets reside: in the IDEs, and in the environment variables developers use on their local machines.
May 2026: The JavaScript Infostructure Targets
The May 2026 "Mini Shai-Hulud" campaign served as a final, stinging reminder of how deep the rot goes in the JavaScript ecosystem. Targeting highly used building blocks—most notably TanStack packages like @tanstack/react-router—TeamPCP compromised 169 npm packages and pushed 373 malicious versions.
This campaign was a refinement of their earlier successes. They abused stolen npm publishing credentials to post their poisoned updates, again focusing on secrets harvesting and maintaining worm-like propagation through CI/CD environment tokens.
The choice of TanStack was intentional. It is a fundamental library for React developers, the kind of dependency that developers never think twice about. When you poison the fundamental infrastructure, the downstream impact is catastrophic.
This brings us back to the same fundamental question: why does a dependency on a library allow a third party to gain full access to your build pipeline? The answer, unfortunately, is that we have designed our CI/CD pipelines to rely on ambient authority—long-lived, untrusted tokens—rather than true, identity-based security. We have built a house of cards, and TeamPCP is simply pulling out the bottom cards to see what happens.
The Path Forward: Defense and Remediation
So, what do we do? The temptation is to look for a "silver bullet"—a scanner that catches every worm, an AI that predicts every breach. But TeamPCP’s successes show us that these are temporary fixes to a systemic problem.
True remediation, the kind that stops campaigns like this, is far more pedestrian.
1. Kill the Long-Lived Tokens
The primary target of TeamPCP is always the secret that grants broad, persistent access. If your CI/CD pipeline uses long-lived GitHub or npm tokens, you are already vulnerable. Transitioning to OIDC-based authentication, which provides short-lived, identity-bound credentials, is not optional anymore. It is the single most effective way to eliminate these attack vectors.
2. Pin Everything
If you aren't pinning your dependencies (to a specific hashtag, not a mutable version tag) and you aren't pinning your CI/CD action versions, you are allowing the actor to inject their own malicious code into your build environment. package-lock.json and requirements.txt are not suggestions; they are the foundation of your build integrity.
3. Build Confidence, Not Trust
The ultimate fix is a shift in mindset. We cannot simply "trust" the packages in our dependency tree. We need to move toward a model where every build action is verified, every token is ephemeral, and every pipeline configuration is treated as code subject to the same security rigors as the application itself.
TeamPCP has made a name for themselves as a scourge of the community, but they are only an opportunistic threat actor. Their success is a direct indictment of modern DevOps practices that prioritize convenience at the expense of security. If we don’t fix these foundational problems, we are just waiting for the next TeamPCP to come along and show us the holes we’ve been ignoring for far too long.