May 2026 will be remembered as the month software supply chain attacks stopped being theoretical.
On May 11, the Mini Shai-Hulud worm hit TanStack's npm packages, compromised OpenAI employee devices, and produced valid SLSA provenance for malicious code for the first time in history. On May 13, the Nitrogen ransomware gang breached Foxconn, stole 8 terabytes of data from Apple, Google, and Nvidia's supplier, and triggered 600+ manufacturing cyberattack reports for the year. Sometime in between, the PyPI "lightning" package was compromised, stealing tokens and credentials from AI development environments. And the LiteLLM supply chain attack from March was still making waves.
Three major incidents in thirty-one days. Each using a different technique. Each targeting a different part of the supply chain. Each with broader impact than the last.
The TanStack Worm Broke New Ground
The Mini Shai-Hulud attack on TanStack was not the largest supply chain incident by volume. The Shai-Hulud wave from September 2025 hit 500+ packages across 700+ repos. What made the TanStack attack different was the technique.
An attacker opened a pull request against TanStack's router repository. The PR triggered a GitHub Actions workflow that ran fork-controlled code in the base repo's security context. That code poisoned the build cache. Eight hours later, the legitimate release workflow pulled the poisoned cache, and the attacker-controlled binaries extracted the OIDC token from the runner's memory. The malicious packages were published with valid SLSA provenance because they went through TanStack's own build pipeline.
The worm then propagated itself through the npm dependency graph. It wrote persistence hooks into VS Code workspace tasks and Claude Code settings files. It installed a dead man's switch that would destroy the user's home directory if the stolen token was revoked.
OpenAI confirmed on May 14 that two employee devices were compromised. The worm did not target OpenAI specifically. It spread through the dependency graph, and OpenAI happened to be there.
We covered the full technical breakdown in our post about the Mini Shai-Hulud worm. The important pattern for this conversation is that none of the three chained vulnerabilities were novel individually. Each was a known attack vector. The novelty was in how they were combined.
Foxconn Was a Different Kind of Supply Chain Attack
The Foxconn breach was not about software dependencies. It was about physical supply chains intersecting with ransomware. The Nitrogen gang claimed to have stolen 8 TB of data from Foxconn's North American facilities, including confidential documents related to Apple, Google, and Nvidia manufacturing.
Dark Reading reported that this was one of 600 cyberattacks on manufacturers in 2026 so far. The number is climbing because manufacturing supply chains have a vulnerability that software supply chains do not. You cannot patch a factory floor with a software update. If the assembly line stops, revenue stops.
The Nitrogen gang knew this. Their playbook is the same one that has worked against hospitals, pipelines, and school districts for years. Find a target where downtime costs more than the ransom, and make sure the target knows it.
The PyPI Lightning Attack Hit AI Developers Directly
Sandwiched between TanStack and Foxconn was the compromise of the "lightning" PyPI package. The malicious version stole tokens and repository credentials from AI development environments. The UK's National Health Service issued a formal cyber alert about the campaign, which is a sign of how seriously the supply chain threat is being taken at the government level.
The Lightning attack was smaller in scale than TanStack but targeted a more concentrated user base. AI developers who installed the compromised package through their Python environment would have had their credentials harvested silently.
What These Three Attacks Have in Common
Different techniques, different targets, different parts of the supply chain. But three patterns run through all of them.
Trust is the attack surface. TanStack's OIDC token was trusted by npm. Foxconn's internal systems were trusted by Apple and Google. The Lightning package was trusted by developers who had been using it for months. Every supply chain attack works because someone trusted something they should not have.
Automated propagation is accelerating. The Mini Shai-Hulud worm spread to 170+ packages within hours through automated npm API queries. It did not need human operators to find new targets. It wrote code to find them itself.
Attribution is getting harder. TeamPCP, the group behind the TanStack attack, is also tracked under the aliases DeadCatx3, PCPcat, ShellForce, and CipherForce. They announced a partnership with the Vect ransomware group on BreachForums. The lines between hacktivists, ransomware gangs, and state actors are blurring.
Your Defense Has to Change
Most organizations respond to supply chain attacks the same way. They run npm audit, update the affected package, and move on. That worked when supply chain attacks were about exploiting a known vulnerability in a dependency. It does not work when the attack is about compromising the build pipeline itself.
You need controls at every layer of your dependency chain. Release-age cooldowns on your package managers. Behavioral analysis on package installs instead of just signature verification. OIDC configuration that is pinned to specific workflows and branches, not entire repositories. Network-level blocking of known C2 domains.
The NHS cyber alert for the May 2026 campaign specifically recommended blocking *.getsession.org at the DNS level, because the TanStack worm used the Session P2P messenger network for exfiltration. That is the kind of practical measure that makes a difference.
We have written about supply chain response patterns in our post about the LiteLLM attack and the Axios npm compromise. The techniques keep evolving, but the fundamentals of detection and containment stay the same. If your team has not reviewed your supply chain security posture this month, now is the time. Talk to us about running a pipeline audit before the next wave hits.
