CrowdSec și TanStack: tokenul unui fost angajat
Pe 18 septembrie 2026, CrowdSec a publicat analiza propriului incident: aproximativ 170 de depozite GitHub private ale companiei au fost descărcate pe 22 mai, între 05:52:29 și 06:01:33 UTC. Accesul a venit prin contul GitHub al unui dezvoltator care plecase din companie, dar rămăsese în organizație, folosind un token OAuth care nu mai exista în momentul descoperirii.
Laptopul acelui fost coleg fusese compromis pe 11 mai, în atacul supply chain asupra pachetelor npm TanStack. Între compromiterea inițială și descoperire au trecut aproximativ patru luni: CrowdSec a aflat pe 16 septembrie, când codul a apărut public. Este un lanț cu trei verigi, iar fiecare dintre ele există în majoritatea organizațiilor care scriu cod.
Veriga întâi: pachetul npm publicat cu o identitate legitimă
Conform înregistrării NVD pentru CVE-2026-45321, pe 11 mai 2026, între aproximativ 19:20 și 19:26 UTC, au fost publicate în registrul npm 84 de versiuni malițioase pentru 42 de pachete din familia @tanstack. Fiecare pachet afectat a primit exact două versiuni malițioase, la câteva minute distanță.
Partea importantă nu este volumul, ci cum au fost publicate. Publicările au fost autentificate prin legătura legitimă de trusted publisher OIDC din GitHub Actions pentru TanStack/router, iar workflow-ul de publicare în sine nu a fost modificat. Cu alte cuvinte, controlul care ar fi trebuit să prevină exact acest tip de abuz a fost cel prin care a trecut atacul.
Atacatorul a înlănțuit trei clase cunoscute de probleme: o configurare greșită de tip pull_request_target, care permite codului dintr-un fork să ruleze fără aprobare; otrăvirea cache-ului GitHub Actions peste granița de încredere dintre fork și baza proiectului; și extragerea tokenului OIDC direct din memoria procesului runner-ului. Postmortemul publicat de TanStack descrie concret cum workflow-ul bundle-size.yml folosea pull_request_target, cum payload-ul a otrăvit cache-ul și cum workflow-ul legitim de release l-a restaurat ulterior.
Merită notat și ce a funcționat: compromiterea a fost detectată public în 20–26 de minute de un cercetător de la StepSecurity, toate versiunile au fost marcate ca depreciate în circa o oră și 43 de minute, iar npm a eliminat arhivele în aproximativ patru ore și jumătate. Răspunsul a fost rapid. Cazul CrowdSec arată ce se poate întâmpla oricum în acel interval.
Veriga a doua: ce caută un payload de instalare
Conform postmortemului TanStack, payload-ul rulat la npm install colecta credențiale din locuri previzibile: AWS IMDS și Secrets Manager, metadatele GCP, tokenurile de service account Kubernetes, tokenurile Vault, fișierul .npmrc din directorul utilizatorului și tokenurile GitHub. Le exfiltra, apoi încerca să se propage republicând alte pachete întreținute de utilizatorii compromiși.
Lista aceea este, practic, inventarul a tot ce poate atinge o stație de dezvoltare. Nu este un atac asupra unui server; este un atac asupra contextului în care ruleaza comanda de instalare. De aceea recomandarea TanStack pentru oricine a instalat versiunile afectate pe 11 mai este explicită: rotiți credențialele AWS, GCP, Kubernetes, Vault, GitHub, npm și SSH accesibile de pe gazda pe care s-a făcut instalarea.
Scorul CVSS 3.1 este 9.6, cu vectorul AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Elementul UI:R înseamnă interacțiune necesară din partea utilizatorului, iar acea interacțiune este instalarea pachetului. CISA a adăugat CVE-ul în catalogul Known Exploited Vulnerabilities pe 27 mai, cu termen 10 iunie, iar intrarea consemnează utilizarea în campanii ransomware ca fiind cunoscută, ceea ce este mai rar decât „necunoscut” în majoritatea intrărilor.
Veriga a treia: contul care nu a fost închis
Aici devine cazul CrowdSec instructiv. Dezvoltatorul plecase din companie, dar contul lui rămăsese în organizația GitHub. Credențiala folosită nu a fost o parolă și nici un personal access token, ci un token OAuth, adică o autorizare acordată cândva unei aplicații, de tipul celor care nu apar pe lista obișnuită de verificat la plecarea unui om.
CrowdSec precizează că tokenul nu mai exista în momentul descoperirii incidentului, ceea ce înseamnă că reconstituirea a trebuit făcută din altă parte. Datele Git au arătat activitate dintr-o adresă IP din Toronto, Canada. Fereastra este strânsă: nouă minute, pe 22 mai. Compania numește un actor legat de BreachForums; nu reproducem identificatorul aici, iar numirea aparține victimei, nu unei confirmări independente.
Ce s-a copiat, conform declarației CrowdSec din 17 septembrie: codul sursă al consolei SaaS, câteva rutine AWS Cloud, conectori și automatizări. Relatările despre comunicarea mai amplă descriu suplimentar scripturi și modele de data science, unelte de deployment și algoritmul de consens pentru listele de blocare.
Ce nu s-a întâmplat, conform companiei: contul a fost folosit doar pentru a copia cod, infrastructura de producție și bazele de date nu au fost accesate, iar codul și pipeline-ul CI/CD nu au fost modificate; contul expus a executat doar operațiuni de fetch. CrowdSec spune că a căutat orice token, credențială sau scurgere care ar permite mișcare laterală și a găsit, citez, „none so far”, și că a rotit imediat toate tokenurile și credențialele necesare. Sunt afirmații ale victimei despre propriul mediu, nu constatări verificate independent, iar acel „deocamdată” este al lor, nu al nostru.
O neconcordanță care merită semnalată
CrowdSec a publicat două materiale la o zi distanță, iar ele nu spun exact același lucru. Declarația din 17 septembrie afirmă că nu au fost scurse date de client, date de autentificare, nume, organizații sau altceva. Relatările despre comunicarea din 18 septembrie descriu, în schimb, adrese de email ale 83 de utilizatori CrowdSec și nume, adrese de email și context de investiție pentru 51 de potențiali investitori din 2020.
Nu am putut reconcilia cele două formulări din paginile primare pe care le-am citit, așa că le prezentăm pe amândouă, cu sursa fiecăreia. Este posibil ca a doua comunicare să fi extins evaluarea inițială; este posibil și ca „date de client” să însemne pentru companie altceva decât adresele din depozite. Nu speculăm care.
Motivul pentru care merită menționat nu este să prindem pe cineva pe picior greșit. Este că, într-o evaluare proprie de incident, prima comunicare aproape întotdeauna subestimează, iar echipa care o citește trebuie să știe de la ce dată este afirmația pe care o folosește.
Ce verifici în propria organizație
- ▸Enumeră identitățile pe care le are un plecat în sistemele externe, nu doar în directorul corporativ: organizația GitHub sau GitLab, npm, registrul de containere, furnizorul cloud, unelte SaaS de dezvoltare. Dezactivarea contului din Active Directory nu atinge niciuna dintre ele.
- ▸Caută separat autorizările OAuth, nu doar tokenurile personale. O aplicație autorizată cândva de un utilizator rămâne valabilă independent de parola lui și de MFA, iar acesta este exact tipul de credențială din cazul de față.
- ▸Verifică dacă organizația ta cere apartenență activă pentru accesul la depozitele private și dacă există o revizuire periodică a membrilor. Un cont rămas în organizație este acces, chiar dacă nimeni nu îl mai consideră angajat.
- ▸Dacă ai instalat vreodată pachete afectate în perioada relevantă, verifică dacă rotația recomandată a fost făcută efectiv pe toate gazdele, inclusiv pe laptopuri și pe runnerele de CI, nu doar în producție. Cazul acesta arată ce rămâne deschis când rotația se oprește la servere.
- ▸Tratează stațiile de dezvoltare ca sisteme cu acces privilegiat, pentru că asta sunt. Ele conțin tokenuri către cod, registre, cloud și orchestrare, iar o instalare de dependență le atinge pe toate.
- ▸Notează cât timp îți păstrezi logurile de audit din GitHub sau echivalent. CrowdSec a putut reconstitui o fereastră de nouă minute de acum patru luni; întrebarea utilă este dacă tu ai putea.
Dovada minimă pentru închidere
Awarely Monitor ajută la urmărirea expunerilor, a responsabililor, a excepțiilor și a dovezilor deciziilor până la închidere. Nu gestionează conturi GitHub, nu revocă tokenuri, nu inventariază dependențe și nu detectează cod malițios în pachete. Offboardingul, revizuirea autorizărilor și rotația credențialelor rămân în platforma de identitate, în procesul de dezvoltare și în controalele furnizorilor.
- ▸Procedura de offboarding cu lista completă a sistemelor externe acoperite și dovada execuției pentru plecările recente.
- ▸Inventarul autorizărilor OAuth active la nivel de organizație, cu revizuirea periodică și responsabilul.
- ▸Rezultatul verificării apartenenței la organizațiile de cod: cine mai are acces și pe ce bază.
- ▸Domeniul rotației de credențiale după orice compromitere de dependență: ce a fost rotit, pe ce gazde, când și ce a rămas conștient nerotit, cu motivul.
- ▸Retenția logurilor de audit pentru platformele de cod și perioada pe care o poți efectiv reconstitui.
- ▸Legătura dintre incidentul de supply chain, activele afectate, responsabil și dovezile păstrate până la închiderea revizuirii.
Offboardingul se termină în sistemele externe
Awarely Monitor ajută la urmărirea expunerilor, responsabililor și dovezilor deciziilor. Revizuirea autorizărilor, revocarea accesului și rotația credențialelor rămân în platforma ta de identitate și în procesul de dezvoltare.