How a Trust-Signing Worm Turned TanStack's Own Pipeline Into the Attack
"The survival of cuckoo chicks depends on the ignorance of other species." — Clifford Stoll, The Cuckoo's Egg
Security researchers had already flagged the exposure. Instead of a fix, the industry got a conference agenda. On May 11, more than 170 packages turned out to have been compromised — discovered not by the people who'd been warning about it, but by outside researchers.
Nothing was broken into in the conventional sense. The intrusion simply exploited the gap between a warning that had been documented and an organization that never converted it into action.
Within a day, 84 malicious versions of TanStack packages had been published to npm, reaching downstream users including Mistral AI, UiPath, OpenSearch, and Guardrails AI.
From there the scope only grew: more than 170 packages affected, 518 million cumulative downloads exposed, and a payload built for something more durable than a smash-and-grab credential theft.
The malware wrote itself into Claude Code's settings file and embedded a dead-man's switch: revoking the stolen token triggers an attempt to wipe the victim's home directory. It was engineered to outlast uninstalls, outlast reboots, and outlast the incident-response call where someone inevitably says it's probably fine.
None of this should have been a surprise. The warning had been on record before the confirmation arrived.
The real question isn't whether the risk was flagged — it's why the flag and the incident never seemed to occupy the same room.
In 1986, Clifford Stoll spent ten months chasing down a 75-cent accounting discrepancy and proved it led back to the KGB.
Federal investigators initially waved him off, telling him the dollar amount was too trivial to pursue. He turned out to be right, and they turned out to be wrong.
An intruder had already been living inside the network for months, studying it, operating comfortably under every alert threshold anyone had bothered to configure — and stayed there long before a single agency treated the discovery as credible.
The technology changes. This particular failure mode doesn't.
The attacker didn't need anyone's belief to succeed — only the defenders' attention, which raises the question of who the warning was actually written for.
The Roadshow That Skipped the Fine Print
Picture a document that made the rounds across the industry in early 2026 — polished layout, a credible-looking logo, a title indistinguishable from a hundred other "responsible AI" whitepapers.
It urged organizations to wire their legal teams, deal pipelines, and communications systems into AI tooling, framed the exercise as digital transformation, and came complete with a maturity matrix for tracking progress.
What it left out was any mention that the very protocol it was promoting had already been compromised for roughly a year before the document was even published.
Executives forwarded it. Teams studied it. Conference tracks were built around its recommendations.
Sometime in spring 2026, in hotel ballrooms with polished lighting and forgettable coffee, a slide deck titled something like "AI Skills Adoption: A Practical Roadmap" made its rounds. Breakout sessions filled up. The keynote had a waitlist.
Attendees left with notes on how to connect more of their organization to more tooling, faster — because the pitch was framed entirely around productivity, and productivity was the only number anyone was tracking.
Meanwhile, Trend Micro had already published research pointing the other direction.
The report identified AI skills as a live, present-tense attack surface, not a hypothetical for some future date.
Its argument was specific: compromising an AI skill doesn't just hand an attacker credentials.
It hands them insight into how an organization actually makes decisions — its thresholds, its automated workflows, its operational logic — and that knowledge doesn't evaporate once the session is over.
The numbers backed up the concern. Agentic AI CVEs rose 255% between 2024 and 2025, while MCP servers went from zero recorded vulnerabilities to 95 in the space of a single year.
The Akto State of Agentic AI Security report found that 79% of enterprises had blind spots where AI agents invoked tools or accessed data outside security teams' visibility, and that only 21% of executives had full visibility into agent permissions, tool usage, and data-access patterns.
A conference built around scaling adoption addresses how to expand — not whether the existing footprint is already secure. It's the maturity matrix's live-event equivalent.
Stoll gave up sleep in a proper bed because an anomaly wouldn't let him rest. Conference attendees, by contrast, slept just fine.
That contrast — between someone who can't stop noticing a problem and an institution structured around not noticing it — isn't a matter of intelligence. It's structural: systems built to reward new connections rarely bother measuring the exposure those connections create.
Cisco found that 83% of organizations planned to deploy agentic AI in 2025, while only 29% felt genuinely prepared to do so securely.
The maturity matrix was never built to measure blind spots — only to encourage more connections.
By the time that conference wrapped, someone else had already stopped scoping and started building.
When an institution sends its most alert employee off to a seminar on connecting more systems, while an attacker already understands exactly what that connectivity costs, it's worth asking who's actually being taught something.
A Perimeter That No Longer Ends at Installation
For years, incident response began with one straightforward question: what did you install?
That question made sense in a world where the malicious code lived inside the package itself — where running npm uninstall was a legitimate first move.
That world ended on May 11, and it ended fast — within six minutes, before anyone was positioned to intervene.
The perimeter itself shifted.
Shai-Hulud didn't wait for victims to install infected packages — it compromised the repository itself and waited for someone to simply open it.
A persistence hook embedded in .claude/settings.json re-executes every time Claude Code opens that repository — on any machine, for any developer who later clones it.
The infection no longer lives in what gets installed. It lives in the environment you work inside. The very tools developers use to build software became the delivery mechanism.
The relevant question has shifted from "what did you install" to "what repositories do you open, with what tooling, and did anything ever in that dependency chain leave something behind that neither npm nor an uninstall command ever touched."
The old threat model assumed the attack surface stopped at whatever code you deliberately chose to run. Shai-Hulud showed that the surface now extends to everything that runs you.
This is a genuine step-change — not a bigger version of an old threat, but a fundamentally different shape.
The earlier generation of threats was malicious code that fired on install. This one is a persistent modification of the environment's behavior itself — surviving the package's removal, surviving credential rotation, and sitting quietly inside the config file of a tool developers use every single day, re-triggering on every session and waiting for the next secret to pass through.
Trend Micro had already named this shift before it materialized.
AI skills — the config files, settings, and behavioral instructions that govern how AI tools operate — were flagged as a rising attack surface not for what data they store, but for what they encode about how a system behaves.
Compromising one doesn't just expose whatever secrets currently sit in an environment. It teaches an attacker how that environment reacts — its thresholds, its automation rules, its decision patterns.
Shai-Hulud turned that theory into an operational fact: .claude/settings.json and .vscode/tasks.json were targeted not because they contained secrets, but because they control how a developer's environment responds to everything that follows. That control persists even after the malicious package is gone. Remove the package, and the hook stays behind.
There's a specific chill to this detail: a developer who ran the uninstall, rotated their credentials, filed the ticket, and closed it out may still be executing the hook on every session.
Every repository opened in Claude Code re-triggers the payload. Every collaborator who clones that repository inherits it.
The infection doesn't spread through a deliberate install — it spreads through the mundane act of doing the job: opening a file, starting a session, reaching for the tool meant to help.
The conference had spent its time teaching people how to weave more AI tooling into their workflows. Shai-Hulud demonstrated that the workflow itself had already become the attack surface.
Those two realities belong in the same conversation. In most organizations, they still haven't met.
That unclosed gap between the conference's answer and the threat's actual question is exactly where the next incident is being assembled.
If an infection can survive an uninstall, outlast an incident-response process, and re-fire every time a developer opens their tools, at what point does the word "remediated" stop meaning anything?
Borrowing a Nest That Already Existed
Markus Hess never announced his presence.
He moved through a preexisting hole in the system, carrying credentials that appeared legitimate, traveling through infrastructure that had no reason to flag a trusted node as hostile.
He was deliberate and unobtrusive, connecting only briefly each time — never long enough to trip alert thresholds that hadn't been set anyway — and leaving no trace anyone thought to look for, until one astronomer refused to let a 75-cent discrepancy go unexplained.
The account behind Shai-Hulud was registered on March 19, 2026.
It sat dormant for nearly eight weeks before pushing a single commit to a fork of TanStack's router repository — not to the main branch, and not in any way designed to draw attention.
The commit was orphaned, carrying a 2.3 megabyte payload tucked inside a file whose name blended in as if it belonged there.
Breaking into TanStack's build pipeline directly was never the goal. The goal was getting TanStack's own pipeline to execute the attacker's code with TanStack's own secrets attached.
It worked.
The resulting packages carried valid SLSA Build Level 3 provenance attestations — making this the first documented npm worm capable of producing malicious packages that pass provenance checks legitimately.
By every formal signal, the packages looked exactly like TanStack's own output, sitting exactly where TanStack's output should sit. Nothing about them prompted a second look.
The campaign took its name from Dune's sandworm, Shai-Hulud — a creature that moves unseen beneath the surface until the moment it breaches it.
Branch names inside the exfiltration repositories kept the theme going: atreides, fremen, harkonnen, sandworm, sardaukar, stillsuit, melange — pulled from a full Dune-themed wordlist and formatted to mimic Dependabot's own branch-naming conventions, so the malicious commits read as routine automated updates.
There's something pointed about naming your infrastructure after a creature famous for staying hidden until it's already struck — an ecosystem that has learned to watch for the warning signs and still can't stop it in time. The naming wasn't accidental. It was fitting.
This wasn't TeamPCP's first run at this playbook, either.
Each incident showed the same patience, the same technique of borrowing existing trusted infrastructure rather than breaking it outright, and the same widening blast radius as each victim's stolen publishing credentials became the vector for the next.
The damage extended well past individual developer machines. OpenAI confirmed that two employee devices inside its corporate environment were compromised, and that the affected source-code repositories included code-signing certificates covering its products on iOS, macOS, and Windows.
As a result, every macOS user running ChatGPT, Codex, or Atlas now faces a firm deadline: update by June 12, 2026, or the application stops functioning. The compromise traveled from a developer's dependency tree all the way to an ordinary consumer's desktop — nobody who clicked "update" on their ChatGPT app ever installed a TanStack package themselves.
OpenAI also disclosed that the incident happened mid-rollout of new security controls, and that the two affected employee devices simply hadn't yet received the updated configuration that would have blocked the download.
The fix already existed. It just hadn't finished deploying. That gap between having a solution and having it everywhere is exactly where the attack found room to land.
Shai-Hulud wasn't a fully formed threat that appeared overnight on May 11 — it had been developing inside the ecosystem for months, quietly mapping it and staying under every threshold that might have triggered scrutiny.
The pattern mirrors 1986 almost exactly. Only the network has changed.
Stoll compared his adversary to a cuckoo bird — a species that lays its egg in another bird's nest, letting the host raise offspring that was never its own, exploiting a behavioral gap rather than a technical one.
The host bird isn't careless. It simply isn't wired to suspect the eggs already sitting in its own nest.
That kind of innocence is structural. It can't be patched — only replaced by a posture that treats familiarity as grounds for scrutiny rather than trust.
The account that seeded this campaign was under two months old. The packages it compromised had racked up 518 million downloads between them.
Roughly eight weeks of patience was enough to defeat years of accumulated trust.
That mismatch — how little time it takes to weaponize trust compared to how long it takes to build — is simply the operating reality now.
It was the operating reality in 1986 too. Institutions didn't absorb the lesson then.
Whether the industry absorbs it now, or waits for another twenty-foot printout before anyone takes a warning seriously, remains the open question.
If patience measured in weeks is enough to defeat years of trust, what defense actually holds against patience?
Two Roads That Lead to the Same Failure
There are really only two ways an organization ends up in this position.
The first is genuine ignorance — the team simply hasn't read the reports.
They don't understand what an AI skill encodes, don't know what a persistence hook is or why it can outlive an uninstall, and haven't seen the data showing that 79% of enterprises have blind spots where agents touch data outside security's view.
They attended the conference in good faith, wired up their stack in good faith, and followed guidance from people they had every reason to trust. From where they stood, it looked like progress.
That describes most of the industry. It isn't a moral lapse — it's an information gap dressed up in transformation language.
The second path is less comfortable to name, so it's worth being precise about it.
The warning existed. It was specific, sourced, and dated.
It reached the right inbox. The concerns were raised in the right meeting. The room nodded — the kind of nod that signals "acknowledged" rather than "acted on," filed somewhere between the quarterly review and the next sprint — and then the conference registration went through anyway.
Not out of recklessness, but because the productivity case was concrete and immediate, while the risk case remained abstract. In practically every organization, the concrete wins out over the abstract, until the abstract shows up in a form that can no longer be argued away.
Ignorance and willful deferral produce nearly identical post-mortems.
The only real difference is what the paper trail shows, and who ends up writing the section describing what was known and when.
France constructed the Maginot Line with real engineering sophistication — concrete fortifications, interlocking fields of fire, built by people who understood the previous war intimately and were determined not to repeat its mistakes.
It was technically impressive. It was also strategically irrelevant.
The invasion came through Belgium, via the Ardennes forest — terrain planners had judged too difficult to cross and therefore not worth fortifying.
The Line itself held. The country fell regardless.
Crypto and tech built an equivalent defense: formal verification, multi-sig, timelocks, bug bounties with seven-figure payouts.
That's a genuinely sophisticated immune system for one category of threat, standing wide open to everything approaching from a different direction.
A smart contract audit doesn't touch the package manager. A bug bounty program doesn't cover the CI/CD pipeline. Multi-sig doesn't protect the settings file dictating how an AI agent behaves.
The fortification is real. So is the gap beside it — and an attacker patient enough to wait for the right fork doesn't need to breach the Line at all.
Gravitee found that 88% of organizations reported confirmed or suspected AI agent security incidents over the prior year.
Meanwhile, 82% of executives reported confidence that existing policy already protected them against unauthorized agent actions.
Those two figures aren't contradictory — they describe the same industry, one that has mistaken the sophistication of its defenses for their completeness.
The FBI dismissed Stoll's 75-cent loss as immaterial. They weren't wrong about the amount. They were wrong about what it signified.
The anomaly itself wasn't the threat — it was the fingerprint of a threat that had already been inside the system for months and would remain there for ten more, patient in a way institutional review cycles simply aren't built to match.
The Maginot Line was engineered for the war France already understood. Germany fought a different one entirely.
The distance between a defense and the threat it's meant to stop isn't a design flaw here — it is the design.
When real defenses exist but the threat has simply walked around them, what does "taking security seriously" actually mean?
Defaulting to Suspicion
Being paranoid by default isn't a personality trait, and it isn't the anxious instinct of whoever keeps raising uncomfortable questions about attack surfaces in the back of the conference room.
It's a professional discipline — the posture that develops after reading enough post-mortems to recognize a single recurring failure dressed in different clothing each time, arriving on a schedule the industry keeps mistaking for a surprise.
Existing tools don't assume betrayal, and that's not a criticism — it's a description of how they were designed, and there were reasons for those choices.
npm installs packages without verifying them because verification at that scale remains an unsolved problem, and the ecosystem was built around the assumption that most packages, most of the time, are exactly what they claim to be.
GitHub Actions' pull_request_target workflow executes fork code in a context carrying the base repository's secrets because the productivity that architecture unlocks is real, and for a long stretch of time, the risk it created stayed theoretical.
SLSA Build Level 3 provenance attestation was built to confirm an artifact came from its expected pipeline — not to guarantee that pipeline hadn't been turned against itself, because that particular attack hadn't yet been documented.
Every one of these design choices was reasonable given what was known at the time.
None of them assumed betrayal. Shai-Hulud did.
The modern developer stack, broadly, is architected around an assumption of good faith.
Defaulting to paranoia is simply supplying the caution the architecture leaves out.
Stoll defaulted to suspicion not out of some fixed disposition — he was an astronomer who normally thought about gravitational waves — but because a 75-cent discrepancy wouldn't let him move on, and he followed it into territory the institutions around him had already decided wasn't worth the effort.
He slept in his office, borrowed fifty printers from colleagues, and called the FBI, NSA, CIA, and Air Force — and when none of them bit, he kept going anyway, because the anomaly was real, it had a source, and that source was operating inside a system everyone else had already dismissed as fine.
That's what defaulting to paranoia actually looks like. Not disorder — discipline.
The industry has built up a specific resistance to that posture, usually under the banner of the productivity argument, which isn't wrong on its own terms: AI tooling genuinely does speed up work, integrations genuinely do cut friction, and conference sessions genuinely do teach usable skills.
None of that is being disputed here.
What's in dispute is sequencing. You cannot secure infrastructure you haven't mapped. You cannot spot an anomaly without a baseline. You cannot govern a workflow whose existence you don't even know about.
The audit needs to happen before the next deployment — before the next AI skill gets wired into a wallet, a Slack channel, or a private key — not because connectivity itself is dangerous, but because connecting anything unaudited in an ecosystem where verification systems have already been shown to be defeatable looks a lot less like a calculated risk and a lot more like an open invitation.
Defaulting to suspicion means asking what a package actually does before running it — not after the incident report is filed.
It means treating a persistence hook inside a settings file with the same wariness you'd apply to an unsigned transaction, and understanding that provenance attestation only confirms where something was built, not whether the build process itself stayed clean.
It means recognizing that an attacker willing to wait nearly eight weeks for the right moment to push one single commit isn't going to be stopped by a quarterly AI-tooling review buried below the roadmap update on someone's meeting agenda.
There's usually someone in the room who spots the pattern first — who writes it up, documents the red flags, and backs the argument with sourced claims and precise timestamps. In a rational institution, that should be enough.
Instead the room nods, and the conference registration clears anyway.
Then, at some future moment, the same anomaly resurfaces — this time in a form too large to file away and move past.
The person who sounded paranoid wasn't the problem. They were just early.
Nobody built this exposed attack surface on purpose. The mistake was extending it trust without checking first.
Private keys keep leaking, and the industry still doesn't fully understand every mechanism behind it.
The stack keeps getting deeper — more packages, more integrations, more skills wired into more of the organization — often without a full audit before the next layer gets added on top.
Years of unresolved private-key losses across the industry, still without clear origin stories in many cases, sit inside the same unexamined gap that Shai-Hulud walked through in six minutes on a Monday evening.
Somewhere in that space between what's been connected and what's actually been checked — between a warning that was written down and a conference that got booked anyway — the next incident is likely already taking shape, courtesy of someone with nearly two months of patience and a clear read on exactly what the verification systems can't see.
Stoll needed ten months to prove what a 75-cent error actually meant. The institutions around him spent that same stretch of time finding reasons to look away.
Both things were happening in the same system at the same time. Only one of them ended up mattering.
The industry is currently running the same experiment again, just with a bigger stack, a shorter timeline, and an attacker who has already shown that the systems built to confirm trust can be made to confirm betrayal instead.
The survival of cuckoo chicks still depends on the ignorance of other species.
The knowledge is already out there. The remaining question is whether the industry acts on it, or keeps filing the anomaly under "next quarter," keeps sending its most alert people off to conferences, and keeps letting the stack deepen and the keys leak until the printout finally grows too long to dismiss.
The next conference is still on the calendar. The content hasn't changed.
The only question that has ever mattered is whether anyone in the room is actually listening this time.
Get new scam files the moment we publish them — usually 2–3 emails a week.