If your product was built in the last five years, it almost certainly depends on packages that sat one hop away from this spring's supply chain worms. In May and June 2026, coordinated attacks compromised TanStack, Mistral AI, UiPath, Red Hat's cloud services namespace, and over 170 npm and PyPI packages with a combined 518+ million downloads (Orca Security). The first half of 2026 has already produced 4.5x the malicious package volume of all of 2025 (Phoenix Security).
You don't need to be a developer to understand what this means for your company. That's what this post is for.
What Actually Happened?
Three overlapping campaigns, escalating through the spring:
May 11 — TeamPCP hits TanStack. Attackers compromised the CI pipeline (the automated system that publishes software updates) of TanStack, one of the most widely used JavaScript library families. 84 malicious package versions were published across 42 packages within six minutes. The campaign spread to Mistral AI, UiPath, and beyond — 170+ packages across npm and PyPI.
Late May — Mini Shai-Hulud waves. A self-replicating worm — it steals a maintainer's publishing credentials, republishes infected versions of their packages, and uses those to infect the next maintainer — returned in two further waves, this time with a new initial-access technique requiring no stolen credential at all, and malicious packages carrying valid SLSA provenance (the cryptographic "proof of authenticity" that was supposed to prevent exactly this).
June 1 — Miasma hits Red Hat's namespace. At least 32 packages under @redhat-cloud-services were compromised, with the attacker bypassing code review entirely.
What the malware does once installed: harvests GitHub and npm tokens, CI/CD secrets, cloud credentials, and API keys (Unit 42) — then uses them to spread further and to come back for your infrastructure later.
May 2026 alone saw 14 separate campaigns and 346 malicious packages — the busiest month ever recorded.
Why Should a Founder Care About Someone Else's Hacked Package?
Because your product is mostly other people's code. A typical SaaS application directly imports a few dozen packages, which import hundreds more. You "own" perhaps 5% of the code that runs when a customer clicks a button.
Translate the technical event into business exposure:
- Stolen secrets = breach liability. If a compromised package ran in your build system, your cloud credentials, database keys, and customer-data access tokens may be in an attacker's hands right now, quietly, with no ransomware banner to alert you. The LiteLLM incident in March logged ~500,000 data exfiltrations in roughly two hours.
- Due diligence is watching. Acquirers and investors now routinely ask "show me your dependency inventory and your response to the 2026 worm wave." No answer is itself an answer — and technical DD findings kill or reprice deals.
- The window between "disclosed" and "exploited" is hours. TanStack's 84 malicious versions went live in six minutes. If nobody at your company knows what you depend on, your response time is measured in weeks.
"We're Too Small to Be a Target" — Why That's Backwards
Worms don't choose targets. That's the defining feature of this attack class: it propagates automatically through whoever depends on whatever it infected. A 4-person startup pulling a poisoned TanStack version gets exactly the same payload as a Fortune 500. The only variable is who notices — and small teams without security staff notice last.
The AI-coding era makes this sharper. AI assistants suggest packages liberally, and 19.7% of AI-generated code samples contain at least one hallucinated package name — names that attackers register preemptively with malware inside (the industry calls it "slopsquatting"). More dependencies, chosen faster, by tools that don't check reputations: the attack surface is growing on autopilot. If your product was vibe-coded, this compounds the risks we covered in is your AI-generated code production-ready.
The Founder's 5-Step Response Checklist
You can drive this without writing code. Forward it to whoever maintains your product:
- Get a dependency inventory (today). Ask: "Can we produce a list of every package and version we use, including transitive dependencies?" If the answer is no, that's finding #1. An SBOM (software bill of materials) is the deliverable's formal name — acquirers will ask for it too.
- Check exposure to the named campaigns (this week). Were any TanStack, @redhat-cloud-services, Mistral, or UiPath packages — or anything else on the published IOC lists — installed or built between May 10 and June 5? Build logs answer this.
- Rotate credentials if exposure is plausible (immediately). The payloads steal tokens and keys. Rotation is cheap; a quiet attacker holding your cloud keys is not. While you're at it, check nothing is already exposed: our guide to finding leaked secrets in GitHub.
- Pin and delay updates. Auto-updating to the newest package version used to be hygiene; in worm season it's the infection vector. Pin versions; adopt a 7–14 day cooldown on non-security updates so the ecosystem catches poisoned releases before you ingest them.
- Make it recurring, not heroic. One audit after a scary headline is theater. Dependency review belongs in your regular health check, alongside the items in our code audit checklist.
What Happens to Stolen CI Secrets? The Part After the Headline
The headlines end at "credentials were exfiltrated." For the affected company, that's where the actual incident begins — and understanding the timeline explains why "we'll rotate keys if we hear something" is not a plan.
Hours 0–2: Harvesting. The payload runs inside your build or developer machine and ships out everything it finds: cloud keys, database URLs, GitHub tokens, npm publish tokens, .env files. The LiteLLM compromise logged ~500,000 exfiltrations in roughly two hours — collection is automated and immediate.
Days 1–7: Sorting and resale. Stolen credentials get validated by bots (does this AWS key still work? what can it access?) and sorted by value. High-privilege cloud keys and tokens for other popular packages are kept for direct exploitation; the bulk gets sold on credential markets. This is why worms compound: your npm token becomes the next campaign's initial access.
Weeks 1–8: Quiet exploitation. The common monetizations, roughly in order of frequency: cryptomining on your cloud account (often discovered via a shocking invoice), data exfiltration from reachable databases, and — for the patient attacker — persistence: a new IAM user or deploy key that survives your password reset. The dangerous scenario isn't the loud one; it's the attacker who does nothing detectable until your data is worth more than your compute.
The diligence echo, months later. Acquirers' security questionnaires now ask: "Have you been affected by a software supply chain compromise, and how did you verify you weren't?" A company that can answer with an SBOM, build-log review, and a rotation date reads as governed. A company that answers "we don't believe so" reads as unaudited — and unaudited reads as discount.
The takeaway: rotation within hours costs nearly nothing; discovery via invoice, breach, or due-diligence questionnaire costs somewhere between embarrassing and existential. The entire game is knowing whether you were exposed — which is an inventory problem, not a security-team problem.
What Does Exposure Cost vs. Checking?
A traditional security consultant will quote $10,000+ and a multi-week engagement to answer "what's in our codebase and is any of it dangerous?" That math made sense when audits were rare events. It doesn't when the threat landscape produces a record-breaking campaign month and 37 campaigns in a half-year.
SystemAudit runs the same core inventory — full dependency map, known-vulnerable and known-malicious package flags, exposed secrets scan, architecture risks — from a GitHub link, in under 3 minutes, in business lang