Klokken 19:20 UTC mandag 11. mai begynte 84 ondsinnede versjoner å lande i npm-registeret, fordelt over 42 @tanstack/*-pakker. Tanner Linsley og TanStack-teamet publiserte 2026-05-11 en detaljert postmortem som dokumenterer hele angrepskjeden. Det stjålne var ikke npm-tokens; angriperen utnyttet at GitHub Actions-konfigurasjonen lot fork-PRer mate poisoned cache inn i hovedrepoet, og at release-workflowen senere hentet tilbake nøyaktig den cachen ved publisering til main.
Kjeden er tre svakheter koblet sammen: pull_request_target «Pwn Request»-mønsteret i bundle-size.yml, GitHub Actions cache-forgiftning over fork-til-base-grensen, og runtime-uthenting av et OIDC-token fra Actions-runner-prosessen. Ingen av delene er TanStack-spesifikke. Adnan Khan dokumenterte cache-poisoning-klassen i 2024, og OIDC-uthentingen brukte verbatim Python-skript fra tj-actions/changed-files-kompromisset i mars 2025. Angriperen kombinerte publisert forskning.
«Det utløsende tastetrykket var et force-push på en PR 11. mai 11:11. Cachen ble lagret 11:29, og overlevde i åtte timer til release.yml hentet den ned igjen klokken 19:20.» — TanStack, postmortem 2026-05-11
Måten OIDC-tokenet ble plukket fra runnerens minne på er det praktisk dødelige. release.yml deklarerer id-token: write legitimt for npm trusted publishing. Når poisoned pnpm-store ble restaurert på runneren, lå angriper-binærene allerede der og ble kalt under build-steget. De minet ut OIDC-tokenet fra Actions-runner-prosessen og POSTet rett til registry.npmjs.org med trusted-publisher-binding for TanStack/router release.yml@refs/heads/main. Publiseringen kom altså ikke fra det definerte Publish Packages-steget; det ble hoppet over fordi testene feilet. Den kom fra malware som kjørte under test/cleanup-fasen.
Eksterne forskere oppdaget angrepet innen 20 minutter. ashishkurmi hos StepSecurity åpnet issue #7383 rundt 19:50 UTC med full analyse, og Socket.dev ringte Tanner like etter. npm har deprekert alle 84 versjoner og pull av tarballs er pågående. Hardening-PR er merget: bundle-size.yml er restrukturert, repository_owner-guards lagt til, og third-party action-refs pinnet til SHA-er.
Hva bør du gjøre?
- Sjekk lockfile-historikken din for installasjon av @tanstack/*-versjoner publisert mellom 19:20 og 19:26 UTC 11. mai. Den fullstendige listen ligger i GHSA-g7cv-rxg3-hmpx på GitHub.
- Roter legitimasjon fra install-hosten hvis du fant treff. AWS-, GCP-, Kubernetes-, Vault-, GitHub-, npm- og SSH-credentials som var nåbare fra maskinen, må anses som kompromittert. Payloaden kjørte som del av
npm install-livssyklusen. - Pin third-party Actions til SHA-er i egne workflows.
uses: noen/action@v1lar publisher endre koden under deg.uses: noen/action@<40-tegns-sha>gjør det. Og unngåpull_request_targetfor noe annet enn å lese metadata.
Bakgrunn
pull_request_target ble lagt til av GitHub fordi vanlig pull_request ikke har tilgang til hemmeligheter, noe som blokkerte legitime brukstilfeller som å kommentere en PR med build-resultater. Trade-offen er at workflowen kjører med base-repoets rettigheter mot fork-koden. Den klassen feil har vært dokumentert siden 2020, men dukker fortsatt opp i store prosjekter fordi konfigurasjonen ofte starter som «pull_request» og blir oppgradert til «pull_request_target» når noen oppdager at hemmeligheter mangler. TanStack-saken er en påminnelse om at OSS-supply-chain-angrep nå rutinemessig kjeder kjent CI-svakheter sammen.