Mini Shai-Hulud: TanStack, OpenAI și Supply Chain npm

Cea mai recentă campanie de atac asupra lanțului de aprovizionare nu s-a limitat doar la compromiterea registrelor open-source. Aceasta a preluat controlul asupra procesului de lansare a versiunilor în cadrul uneia dintre cele mai atente organizații din lume în materie de securitate, iar punctul de intrare a fost o instalare de rutină a unei dependențe npm.

Pe 11 mai 2026, grupul de atacatori TeamPCP a lansat al patrulea val al campaniei sale cu viermele Shai-Hulud, cunoscut acum sub numele de Mini Shai-Hulud. Atacul a compromis 84 de versiuni de pachete malware din 42 de pachete TanStack din registrul npm într-un interval de șase minute, extinzându-se în cele din urmă la peste 170 de pachete din registrele de cod sursă npm și PyPI (Python Package Index), inclusiv spații de nume aparținând Mistral AI, UiPath și OpenSearch. Cel puțin un pachet afectat, @tanstack/react-router, înregistrează aproximativ 12 milioane de descărcări săptămânale.

Aceasta este a patra etapă a unei campanii din ce în ce mai intense. Etapele anterioare includ compromiterea inițială a npm (Shai-Hulud 1.0) și etapa 2.0, care viza datele de autentificare GitHub.

OpenAI a anunțat săptămâna aceasta că două dispozitive ale angajaților au fost compromise. Nu au fost afectate datele utilizatorilor, sistemele de producție sau proprietatea intelectuală, însă măsurile de izolare au necesitat izolarea sistemelor, schimbarea periodică a datelor de autentificare, apelarea la experți externi în criminalistică informatică și o reînnoire completă a certificatelor de semnare a codului pe platformele macOS, Windows, iOS și Android, declanșată de instalarea unei singure dependențe.

• Data atacului: 11 mai 2026

• Pachete compromise: 84 de versiuni rău intenționate în 42 de pachete @tanstack/*; peste 170 în total în registrele npm și PyPI

• CVE: CVE-2026-45321, scor CVSS 9,6 (Critic)

• Sursă: TeamPCP (cunoscut și sub numele de PCPcat, UNC6780)

• Mecanism: Trei vulnerabilități interconectate în GitHub Actions – Pwn Request, contaminarea cache-ului, extragerea token-urilor OIDC (OpenID Connect) din memoria procesului runner

• Victimă notabilă: OpenAI – două dispozitive ale angajaților au fost compromise; au fost sustrase secrete, printre care certificate de semnare a codului pentru macOS, iOS, Windows și Android, din depozitele interne de cod sursă

• Versiunile anterioare: Shai-Hulud 1.0 (septembrie 2025), 2.0 (noiembrie 2025) și 3.0 (decembrie 2025)

• Impact: Medii de dezvoltare și CI/CD compromise , conturi ale administratorilor și pachete preluate, iar proveniența SLSA și versiunile semnate nu mai sunt „sigure în mod implicit”

• Riscuri principale: pachete rău intenționate care trec de certificarea de proveniență SLSA (Supply-chain Levels for Software ) de nivel trei

Mini Shai-Hulud Wave Four este cea mai sofisticată versiune a acestei campanii de până acum din punct de vedere tehnic. În timp ce etapele anterioare se bazau pe conturi de administratori compromise pentru a publica direct pachete rău intenționate, Wave Four a combinat trei vulnerabilități ale GitHub Actions pentru a deturna chiar canalul legitim de lansare.

Secvența atacului:

1. Fork și camuflaj: Atacatorul a creat un fork al depozitului TanStack/router, redenumindu-l zblgg/configuration, astfel încât acesta să nu apară ca un fork evident în listele de fork-uri de pe GitHub.
2. Declanșarea fluxului de lucru: a fost deschisă o cerere de preluare care a declanșat un flux de lucru de tip „pull_request_target” – modelul „Pwn Request”, care acordă fluxului de lucru acces la codul bifurcat
3. Contaminarea cache-ului: codul ramificat al atacatorului a scris o intrare contaminată de 1,1 GB pentru pnpm-store în cache-ul GitHub Actions, configurată astfel încât fluxul de lucru de lansare să o restabilească ulterior
4. Ștergerea urmelor: cererea de extragere rău intenționată a fost apoi forțată să treacă într-o stare inactivă și a fost închisă pentru a ascunde dovezile compromiterii
5. Așteptați declanșarea: atunci când administratorii autorizați ai TanStack au fuzionat cereri de extragere fără legătură între ele în ramura principală, fluxul de lucru pentru lansare s-a declanșat și a restabilit cache-ul corupt
6. Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
7. Publicare prin intermediul canalului de lansare: Aceste token-uri au fost utilizate pentru a publica 84 de versiuni de pachete rău intenționate în registrul npm prin intermediul canalului de lansare legitim al TanStack.
8. Rezultatul: pachete care conțin atestări de proveniență valabile de nivel trei SLSA Build Level, atestări Sigstore valabile și semnături GitHub Actions autentice, generate de fluxul de lansare oficial, dar care conțin programe malware destinate furtului de date de autentificare. Așa cum a confirmat TanStack în analiza sa post-incident, din perspectiva dezvoltatorului, pachetele păreau autentice din punct de vedere criptografic, fără niciun indiciu vizibil de compromitere.

Secretele au fost dezvăluite: încărcătura malware a sustras informații confidențiale – date de autentificare și tokenuri care erau accesibile în mod activ pe sistemele compromise – prin trei canale redundante: un domeniu de tip typosquat (git-tanstack[.]com), rețeaua descentralizată de mesagerie Session și puncte API GitHub, folosind tokenuri furate. Datele de autentificare vizate au inclus token-uri GitHub, secrete cloud de la AWS, GCP și Azure, materiale de autentificare CI/CD, date de autentificare Kubernetes, Vault HashiCorp Vault și chei SSH.

Pe computerele dezvoltatorilor, programul malware a instalat un demon persistent numit „gh-token-monitor” (prin intermediul macOS LaunchAgent sau Linux systemd), care interoga GitHub la fiecare 60 de secunde. La primirea unei erori 40X cauzate de revocarea tokenului, demonul încerca să execute comanda „rm -rf ~/”, ștergând directorul de bază al utilizatorului. Demonul se închidea automat după 24 de ore.

Declarația OpenAI oferă detalii precise cu privire la datele sustrase: informații limitate privind datele de autentificare dintr-un subset de depozite interne de cod sursă accesibile celor doi angajați vizați, inclusiv certificate de semnare a codului pentru produsele macOS, iOS, Windows și Android. OpenAI a confirmat că nu există dovezi că aceste certificate au fost utilizate pentru a semna software rău intenționat, dar le înlocuiește pe toate din precauție și solicită utilizatorilor de macOS să își actualizeze aplicațiile înainte de 12 iunie 2026, după care aplicațiile semnate cu vechile certificate ar putea înceta să funcționeze.

Există un al doilea detaliu în comunicatul OpenAI care merită atenție. Cele două dispozitive compromise nu primiseră încă configurațiile actualizate ale sistemului de gestionare a pachetelor, inclusiv măsuri precum verificarea vechimii minime a versiunilor și validarea provenienței pachetelor, care erau în curs de implementare în întregul mediu al organizației. Atacul a avut loc chiar în perioada respectivei implementări.

Aceasta descrie o vulnerabilitate reală și frecventă. Măsurile de securitate sunt implementate treptat. În timpul oricărei implementări etapizate, o parte din sisteme este expusă unui risc mai mare. Campania TeamPCP s-a desfășurat neîntrerupt timp de câteva săptămâni, publicând pachete malware în registre și așteptând ca acestea să fie instalate. Momentul ales nu a fost întâmplător.

Pentru orice organizație care ar fi putut instala pachetele afectate în perioada Mini Shai-Hulud:

1. Verificați dacă există serviciul gh-token-monitor înainte de a revoca tokenurile: izolați și faceți o imagine a sistemelor afectate mai întâi; revocarea prematură declanșează ștergerea datelor.
2. Schimbați periodic datele de autentificare expuse: codurile PAT de pe GitHub, tokenurile npm, cheile SSH și datele de autentificare în cloud pentru orice dezvoltator sau pipeline care a instalat pachete în perioada afectată; activați autentificarea cu două etape (MFA).
3. Eliminați pachetele compromise: goliți memoria cache npm și directorul node_modules; fixați versiunile pachetelor la cele publicate după 12 mai 2026.
4. Verificați acțiunile GitHub și fluxurile de lucru CI/CD: căutați evenimente de publicare neașteptate, fluxuri de lucru noi sau conexiuni de ieșire către puncte finale necunoscute.
5. Consolidați conductele: restricționați scripturile ciclului de viață, limitați accesul la rețeaua externă și minimizați domeniul de aplicare al token-urilor.
6. Combinați verificările provenienței cu inspecția conținutului: o proveniență validă indică originea fluxului de lucru, nu integritatea acestuia; utilizați scanarea împotriva programelor malware împreună cu verificarea atestării.