Un vierme auto-propagant a compromis 444 de pachete npm — inclusiv keyv, o bibliotecă cu 127 de milioane de descărcări săptămânale — după ce atacatorii au preluat contul GitHub al maintainer-ului principal. Semnătura din spatele campaniei, „Shai-Hulud: Here We Go Again", trimite direct la un atac similar din mai 2026, sugerând continuitate operațională, nu un incident izolat.
Cum a fost compromis maintainer-ul
Contul jaredwray, cel care întreține keyv, a fost preluat de atacatori, care au injectat cod malițios direct în depozitele sursă. Cel mai îngrijorător detaliu tehnic: lansările otrăvite au fost publicate prin pipeline-uri CI/CD legitime, cu semnătură validă SLSA, iar unele commit-uri au fost falsificate să pară venite de la contul automat github-actions[bot]. Practic, semnăturile criptografice valide nu au oferit nicio protecție — pentru că infrastructura de semnare fusese ea însăși compromisă.
Cronologia atacului — sub 4 ore, 12 organizații
| Oră (UTC), 4 august | Eveniment |
|---|---|
| 09:02 | Commit nesemnat adaugă fișierele payload în keyv |
| 09:04 | Commit „verificat" (falsificat) adaugă hook-uri IDE |
| 09:35 | Prima versiune otrăvită de keyv publicată |
| 10:12 – 10:46 | 8 organizații compromise în succesiune rapidă |
| 13:18 | Ultima organizație (Umacloud) compromisă |
Printre organizațiile afectate: ServiceTitan (1.082 de versiuni otrăvite), Ornikar (537), OneReach (487), plus Deliveroo, Qlik, Picsart și altele — 2.234 de versiuni malițioase publicate în total, sub 444 de nume de pachete.
Ce fură exact — și cum se ascunde
Payload-ul rulează în două etape: un script preinstall care se declanșează automat la instalarea dependinței, plus fișiere de configurare (.claude/settings.json, .vscode/tasks.json) care execută cod chiar și doar la deschiderea proiectului în editor. A doua etapă e un pachet de 727KB, criptat cu PBKDF2 și AES-256-GCM, care extrage sistematic: chei cloud AWS/GCP/Azure, token-uri GitHub și npm, chei Stripe, credențiale de baze de date (MongoDB, MySQL, PostgreSQL, Redis) și orice cheie privată în format PEM găsită pe disc.
Un „dead man's switch" care complică remedierea
Cel mai periculos element tehnic: un proces care verifică la fiecare 60 de secunde, prin API-ul GitHub, dacă token-urile furate mai sunt valide. În momentul în care un token e revocat — semn că victima a început curățarea —, mecanismul declanșează automat un handler suplimentar. Concret, asta înseamnă că simpla rotație a credențialelor poate activa acțiuni suplimentare malițioase dacă persistența nu e eliminată mai întâi. Datele furate nu ajung pe domenii controlate de atacatori, ci în peste 546 de depozite GitHub create special ca „dead-drop", criptate cu RSA-4096 — tot traficul rămâne, la nivel de rețea, drept trafic obișnuit către infrastructura GitHub.
Ce trebuie să facă dezvoltatorii afectați
Ordinea contează: căutarea și eliminarea mecanismului de persistență (fișiere precum ~/.config/gh-token-monitor/ sau servicii systemd/LaunchAgent similare) trebuie să vină înainte de rotația token-urilor, nu după. Dezactivarea scripturilor de instalare la nivel global (npm config set ignore-scripts true), verificarea versiunilor din lockfile față de lista celor 2.234 confirmate ca malițioase și tratarea oricărui token CI folosit între 09:35 și 13:18 UTC pe 4 august ca fiind compromis rămân pașii esențiali pentru orice echipă care a folosit vreunul dintre pachetele afectate în acea fereastră.
Fii primul care comentează acest articol!