keyv și cacheable, deturnate pe npm: comenzile prin care verifici dacă ești afectat — și protecțiile care chiar funcționează
Compromiterea unui cont de mainteneur pe 4 august a pus pe npm versiuni malițioase de keyv, cacheable, flat-cache și file-entry-cache — pachete descărcate de sute de milioane de ori pe lună. Payload-ul e un worm care s-a răspândit deja în peste 400 de pachete și a fost publicat cu semnături de provenance valide. Iată comenzile exacte de verificare și controalele care l-ar fi oprit.
Pe 4 august 2026, contul npm din spatele a două dintre cele mai descărcate familii de biblioteci de caching din ecosistemul JavaScript a fost compromis. Versiuni malițioase de keyv, cacheable, flat-cache, file-entry-cache și alte câteva pachete înrudite au fost publicate la câteva minute una de alta. Payload-ul e un worm — până când cercetătorii și-au publicat analizele, se propagase deja în peste 400 de pachete npm distincte.
Amploarea e incomodă. Numai keyv are aproximativ 127 de milioane de descărcări săptămânal; flat-cache și file-entry-cache depășesc fiecare 550 de milioane de descărcări pe lună. Aproape nimeni nu le instalează intenționat — ajung ca dependențe tranzitive ale ESLint și ale altor sute de unelte de build. Dacă ai un proiect Node.js, o versiune a acestor pachete e aproape sigur în arborele tău.
Versiunile malițioase, exact
Doar anumite release-uri punctuale sunt malițioase. Dacă ești pe o versiune major mai veche, nu ai fost niciodată în raza atacului. Acestea sunt versiunile de vânat:
- keyv 6.0.0
- cacheable 2.5.1
- cacheable-request 13.0.20
- cache-manager 7.2.10
- flat-cache 6.1.24
- file-entry-cache 11.1.6
- @cacheable/memory 2.2.1 · @cacheable/node-cache 3.1.2 · @cacheable/utils 2.5.1 · @cacheable/net 2.1.1
- ecto 5.0.1
De ce provenance-ul valid a înrăutățit lucrurile, nu le-a îmbunătățit
Atacatorul nu a strecurat un tarball în registry. A împins fișiere malițioase direct în branch-ul main al fiecărui repository și a tăiat imediat un release. Pachetele au fost apoi construite și publicate de propriul pipeline GitHub Actions al proiectului — ceea ce înseamnă că poartă semnături de provenance legitime, valide criptografic.
Detaliul acesta merită să schimbe modul în care echipele gândesc asigurarea lanțului de aprovizionare. Provenance-ul răspunde la întrebarea „a fost acest pachet construit de pipeline-ul pe care îl invocă?". Nu răspunde la „a fost autorizat codul care a intrat în acel pipeline?". Un atacator care deține contul mainteneurului satisface perfect prima întrebare, eșuând complet la a doua. Orice control care tratează o bifă verde de provenance drept dovadă de siguranță tocmai a validat acest atac.
Payload-ul în sine e un descendent al familiei de malware „Mini" Shai-Hulud. Rulează dintr-un hook preinstall — adică se execută în timpul instalării, înainte să ruleze vreo linie din codul tău — și recoltează credențiale cloud, secrete de infrastructură, credențiale de developer, fișiere de configurare AI și portofele crypto, cu atenție specială pentru variabilele de mediu din CI/CD. Își obține dinamic domeniile de comandă-și-control prin contracte inteligente Ethereum, ceea ce face inutile simplele liste de blocare a domeniilor.
Pasul 1 — verifică dacă versiunile rele sunt în arborele tău
Rulează asta în fiecare proiect. Listează ce familii de pachete afectate ai și la ce versiuni, inclusiv cele tranzitive:
npm ls keyv cacheable cacheable-request cache-manager flat-cache file-entry-cache ectoPasul 2 — compară cu versiunile IOC exacte
Comanda de mai sus îți spune ce ai. Aceasta răspunde la singura întrebare care contează — ai o versiune malițioasă? Lipsa oricărui rezultat înseamnă că ești curat:
npm ls --all 2>/dev/null | grep -E "keyv@6\.0\.0|cacheable@2\.5\.1|cacheable-request@13\.0\.20|cache-manager@7\.2\.10|flat-cache@6\.1\.24|file-entry-cache@11\.1\.6|ecto@5\.0\.1"Verificare fără a instala nimic
Dacă node_modules nu există — sau pur și simplu nu vrei să rulezi o instalare pe o mașină pe care încerci s-o verifici — citește direct lockfile-ul. Comanda afișează fiecare versiune rezolvată a familiilor afectate:
grep -oE '/(keyv|cacheable|cacheable-request|cache-manager|flat-cache|file-entry-cache|ecto)/-/[a-z@-]+-[0-9.]+\.tgz' package-lock.json | sort -uEchivalente pentru pnpm și yarn
pnpm why keyv flat-cache file-entry-cache
yarn why keyv
yarn info keyv versionDacă găsești o potrivire: presupune că secretele s-au dus
Un hook preinstall malițios executat pe mașină înseamnă că mediul din momentul instalării trebuie tratat ca fiind compromis — mai ales în CI, unde credențialele stau de regulă în variabile de mediu. Curățarea arborelui de dependențe e partea ușoară; rotația credențialelor e partea care contează cu adevărat.
- Rotește fiecare credențial accesibil din acel mediu: chei cloud, token-uri GitHub/GitLab, token-uri npm, chei SSH, configurări Kubernetes, parole de baze de date
- Revocă sesiunile și token-urile, nu doar schimba parolele — un token emis supraviețuiește unei resetări de parolă
- Analizează logurile de audit din cloud și din controlul versiunilor pentru accese neautorizate începând din momentul instalării
- Reconstruiește agenții de build afectați, în loc să îi cureți pe loc
- Dacă instalarea a rulat în CI, verifică dacă vreun pachet a fost publicat ulterior din acel pipeline — așa se răspândește worm-ul
rm -rf node_modules
npm cache clean --force
npm ci # reinstalare strict din lockfileSingurul control care ar fi blocat asta
Malware-ul rulează dintr-un hook preinstall. Dezactivează scripturile de instalare și payload-ul nu se execută niciodată, chiar dacă descarci tarball-ul otrăvit:
- Precizare onestă: unele pachete legitime au nevoie de scripturile lor de instalare (esbuild, sharp, module native). Activarea globală poate strica build-uri — pune pe allowlist pachetele care chiar au nevoie de scripturi, în loc să renunți complet
- E schimbarea cu cea mai mare pârghie disponibilă azi, pentru că neutralizează întreaga clasă de atacuri supply chain din momentul instalării, nu doar pe acesta
npm ci --ignore-scripts
# sau fă-l implicit pentru mașină / runner-ul de CI:
npm config set ignore-scripts trueProtecții pe straturi de implementat săptămâna asta
- Folosește npm ci în CI, niciodată npm install — ci instalează strict din lockfile și eșuează dacă package.json și lockfile-ul nu se potrivesc, deci o versiune malițioasă proaspăt publicată nu poate fi trasă în tăcere
- Introdu o perioadă de așteptare înainte de a adopta release-uri noi. Majoritatea acestor atacuri sunt detectate și retrase în câteva ore, deci o scurtă întârziere elimină aproape toată fereastra de expunere
- Comite lockfile-urile și tratează modificările lor din pull request-uri ca diff-uri relevante pentru securitate, nu ca zgomot
- Restricționează credențialele de CI: token-uri cu viață scurtă, privilegiu minim, fără chei cloud de lungă durată stând în variabile de mediu de unde le poate citi un hook preinstall
- Aplică filtrare de egress pe runner-ele de build — payload-ul trebuie să-și atingă C2-ul ca să fie util, iar agenții de build rareori au nevoie de acces arbitrar la internet
- Menține un SBOM și monitorizează-l continuu, ca întrebarea „suntem afectați?" să dureze minute, nu o după-amiază
Perioada de așteptare, concret
pnpm suportă nativ o vechime minimă a release-ului. Pentru npm, fixarea unei instalări la o dată anterioară incidentului obține un efect similar pentru o verificare punctuală:
# pnpm: refuză pachetele publicate în ultimele 24h (valoare în minute)
pnpm config set minimumReleaseAge 1440
# npm: rezolvă așa cum arăta registry-ul înainte de o dată dată
npm install --before=2026-08-03Ce spune NIS2 despre asta
Sub NIS2 — transpusă în România prin OUG 155/2024 — securitatea lanțului de aprovizionare e o obligație explicită de management al riscului, iar asta include software-ul cu care construiești, nu doar furnizorii cu care semnezi contracte. O dependență open-source publicată de un mainteneur compromis e exact scenariul la care directiva se așteaptă ca entitățile esențiale și importante să se fi gândit din timp.
În practică, asta înseamnă că trei lucruri trebuie să existe înainte de incident, nu după: un inventar al lucrurilor de care depinzi cu adevărat, un proces documentat de reacție la o componentă compromisă și dovada că ambele au fost menținute. Awarely Monitor acoperă jumătatea de urmărire — monitorizare continuă a NVD, CISA KEV, EUVD și GitHub Advisories, potrivită cu propriul tău inventar de active, cu audit trail imutabil și rapoarte aliniate NIS2 care arată ce știai și când ai acționat.
Surse verificate
Awarely Monitor
Vezi platforma în acțiune
Alte articole
Awarely Monitor · 5 august 2026
CISA adaugă Langflow, N-central și Tomcat în KEV — termen federal 7 august, iar una dintre ele a alimentat deja un atac ransomware condus de AI
Awarely Learning · 5 august 2026
Analog Devices, ExfilSquad și cele 570.000 de înregistrări pe care nu le-a verificat nimeni: cum se citește o revendicare de breșă