This article details a sophisticated npm supply chain attack where threat actors published 84 malicious versions across 42 `@tanstack/*` packages by exploiting the `pull_request_target` event, GitHub Actions cache poisoning, and OIDC token extraction. The malicious packages, which carried valid SLSA provenance and were live for roughly four hours, exemplify a trend of frequent, automated attacks targeting npm's ecosystem. The author emphasizes the necessity of building dedicated threat-hunting pipelines using AI-assisted research to aggregate scattered technical details from various security labs and advisories.
Fortress AI Building AI-assisted threat hunting for npm supply chain attacks After TanStack: Real detection queries, sensor pitfalls, and the AI-generated playbook trap behind a working npm hunt. Rotimi Akinyele May 13, 2026 3 Share If you spent yesterday sweeping build pipelines, GitHub Actions runs, SCA alerts, endpoint telemetry, and server logs looking for malicious npm activity, you are not alone. On 11 May 2026, between 19:20 and 19:26 UTC, a threat actor known as TeamPCP published 84 malicious versions across 42 @tanstack/* npm packages by chaining a pull_request_target "Pwn Request" with GitHub Actions cache poisoning and runtime OIDC token extraction from a runner process. The malicious tarballs were indistinguishable from legitimate ones because they carried valid SLSA provenance. They were live for roughly four hours. @tanstack/react-router alone gets over 12 million weekly downloads. TanStack is not an isolated event. It is the fourth wave of Mini Shai-Hulud in six weeks, after Aqua Security's Trivy in March, Bitwarden's CLI in April, and SAP and Intercom packages on 1 May. We are now averaging a major npm supply chain incident every fortnight, and I do not think this will slow down. The economics have changed: one compromised maintainer or one misconfigured workflow buys access to the entire downstream consumer base, and worm-style payloads self-propagate without operator interaction. If your threat-hunting programme does not have a dedicated npm pipeline, this is the moment to fix that. I want to walk through how we built ours, including the queries that compose it, what the first version got wrong, and what the corrected version looks like. One thing up front. This article is not really about the queries. The queries are illustrative and they target CrowdStrike NGSIEM (LogScale) syntax. The structure ports to Splunk SPL, Elastic ES|QL, or Sentinel KQL, though field names and join semantics differ. What I actually want to walk through is the methodology. Step 1. Use AI deep research to build the corpus Most threat-hunting programmes start with a vendor playbook or a SIGMA rule someone shared on X. That is fine for known ground. It is useless for anything novel, and npm supply chain attacks are nothing if not novel. New packages, new techniques, new actors, sometimes a three-hour exposure window before a malicious version is yanked. Before you can hunt, you need to understand what you are hunting. For npm, the technical detail is public but scattered across Datadog Security Labs, Elastic Security Labs, Google Threat Intelligence Group, Socket, Wiz, StepSecurity, Snyk, and a long tail of GitHub advisories. Aggregating it manually takes half a day. Run this in Claude, Gemini, or ChatGPT with deep research enabled. The output you get is a structured technical document covering the complete kill chain for each attack: exact commands, exact file paths, exact process relationships. Save it as MD or PDF. That document becomes the input for the next step. The prompt we used ( now modified to include most recent waves) : You are a threat intelligence analyst specialising in software supply chain security. Conduct a comprehensive analysis of the most significant npm supply chain attacks of the last 18 months, focusing on the technical execution chain for each attack. For each attack provide: 1. Attack name, date, threat actor (if attributed), and affected packages with download counts. 2. The complete process execution chain from npm install through to payload execution. Cite the primary source for each chain (Datadog Security Labs, Elastic Security Labs, GTIG, Wiz, Socket, StepSecurity, Huntress). 3. Persistence mechanisms (registry keys, cron jobs, LaunchAgents, profile files). 4. C2 infrastructure patterns (protocols, ports, beacon intervals). 5. Anti-forensics and evasion techniques (self-cleanup, lifecycle filtering, sandbox checks). 6. What EDR/SIEM telemetry would capture this on each platform (specific event types and field values). 7. The primary attacker objective (credential theft, persistence, cryptomining, propagation). 8. MITRE ATT&CK technique mapping. Include attacks that represent distinct technique families: Axios (Mar 2026, Sapphire Sleet / UNC1069), ua-parser-js, coa/rc, event-stream, eslint-scope, colors/faker, Ledger Connect Kit, Shai-Hulud (Sept 2025), Shai-Hulud 2.0 (Nov 2025), Mini Shai-Hulud waves (TeamPCP, Mar-May 2026 including Trivy, Bitwarden, SAP, Intercom, TanStack), and dependency confusion variants. Where a claim is uncertain, flag it. Do not invent process names, paths, or hashes. If a field is not reported in primary sources, say so explicitly. Format the output as a structured technical document, one section per attack. The last paragraph is the part that matters. AI deep research tools will happily produce a confident-looking kill chain with a fabricated process name if you let them. Without that constraint, you get plausible-sounding /tmp/loader.sh paths and 185.92....