Shai-Hulud: Atacul supply chain NPM care a compromis 434 de pachete — cum verifici si cum te protejezi in 2026

Pe 4 august 2026, ecosistemul Node.js a primit cea mai mare lovitura supply chain din istoria sa. Un atacator a compromis contul GitHub al mentinatorului pachetului keyv — un utilitar de caching cu aproximativ 127 de milioane de descarcari saptamanale — si a injectat un vierme (worm) care fura credentiale de npm, GitHub si AWS. Viermele s-a auto-propagat catre alte organizatii, inclusiv Deliveroo, Qlik si Picsart. La ora 13:37 CEST, cel putin 434 de pachete (1.381 de versiuni) fusesera compromise, cu peste 2 miliarde de instalari lunare cumulate.

Daca folosesti Node.js, npm sau orice framework JavaScript — React, Vue, Next.js, Astro, Express, NestJS — acest articol te priveste direct.

Ce vei gasi in acest articol:

• Ce s-a intamplat pe 4 august 2026: cronologia completa a atacului
• Cum functioneaza tehnic viermele Shai-Hulud — explicat pe intelesul tuturor
• Tabelul complet cu toate pachetele si versiunile compromise
• Comenzi concrete pentru a verifica daca esti afectat (npm ls, grep, cautare fisiere)
• Pasii imediat daca esti afectat: rotatie token-uri, chei AWS, audit repo-uri
• Cum te protejezi pe viitor: lockfile-uri, ignore-scripts, pinning de versiuni

Ce s-a intamplat — cronologia atacului

Totul a inceput pe 4 august 2026, cand atacatorii au reusit sa compromita contul de GitHub al mentinatorului care controleaza nu doar keyv, ci si un intreg ecosistem de utilitare de caching: cacheable, flat-cache, file-entry-cache, cache-manager, cacheable-request si altele. Mentinerea unui singur cont pentru zeci de pachete populare e o practica comuna in lumea open-source — si exact asta a exploatat atacul.

Fiecare pachet compromis a primit doua fisiere noi — setup.mjs si Math_Symbol.js — plus un camp "preinstall": "node setup.mjs" in package.json. Asta inseamna ca simplul npm install executa automat codul malitios, inainte ca instalarea sa se termine. Nu trebuia sa faci nimic special. Doar sa instalezi sau sa actualizezi un pachet.

Ce a facut atacul si mai periculos: versiunile otravite au fost publicate pe npm cu provenance valida, semnata de GitHub Actions. Asta inseamna ca verificarea provenientei pachetelor — una dintre recomandarile standard de securitate — nu te-a protejat de loc. Semnatura era legitima, doar continutul era compromis.

Viermele nu s-a oprit la pachetele mentinatorului. S-a propagat automat catre organizatii care aveau acces de publicare: @deliveroo/reevent, @or-sdk/invitations, @picsart/ai-sdk, @qlik/embed-runtime, picasso.js. Efectul de domino a fost masiv.

Cum functioneaza tehnic viermele — explicat simplu

Ca sa intelegi de ce atacul asta e atat de grav, hai sa-l descompunem in pasi.

Pasul 1: Dropper-ul setup.mjs. Cand rulezi npm install pentru un pachet compromis, npm executa automat scriptul preinstall din package.json. Acest script lanseaza setup.mjs — un fisier obfuscat (cod scris intentionat ca sa nu poata fi citit usor de un om). Dropper-ul descarca runtime-ul Bun (versiunea 1.3.13) de pe GitHub. Bun e un runtime JavaScript alternativ la Node.js, complet legitim — dar aici e folosit ca vehicul pentru codul malitios.

Pasul 2: Payload-ul Math_Symbol.js. Odata descarcat Bun, dropper-ul ruleaza cu el Math_Symbol.js — un fisier obfuscat de 728 KB care contine adevaratul payload. De ce 728 KB? Pentru ca include tot ce are nevoie: rutine de colectare, criptare, exfiltrare si auto-propagare, toate ambalate ca sa nu fie detectate usor.

Pasul 3: Furtul de credentiale. Payload-ul cauta sistematic:

• Token-uri npm — din ~/.npmrc, validate live printr-un apel la registry.npmjs.org/-/whoami ca sa confirme ca sunt valide
• Token-uri GitHub — PAT-uri (ghp_, gho_, ghs_), token-uri JWT OIDC, din ~/.config/gh/hosts.yml, variabile de mediu si prin scanarea fisierelor din sistem
• Credentiale AWS — din ~/.aws/credentials, variabile de mediu, metadata IMDS (169.254.169.254), ECS metadata (169.254.170.2) si chiar AWS Secrets Manager
• Secret store-ul din GitHub Actions — pe runnerele GitHub Actions, codul citeste direct memoria procesului runner si extrage tot secret store-ul

Pasul 4: Exfiltrare criptata. Datele furate sunt criptate si trimise intr-un repository public GitHub a carui descriere este „Shai-Hulud: Here We Go Again” — de unde vine si numele atacului.

Pasul 5: Propagare (worm). Payload-ul are functionalitate de vierme: daca ai acces de publicare la alte pachete npm, infecteaza automat si acele pachete. De aceea atacul s-a extins atat de repede de la pachetele mentinatorului la pachetele altor organizatii.

Pachetele compromise — lista completa

Mai jos sunt pachetele compromise direct de mentinator, plus cele infectate prin propagarea viermelui.

Pachete ale mentinatorului compromis

Pachete infectate prin propagarea viermelui

Cum verifici daca esti afectat

Verificarea daca proiectul tau contine pachete compromise e rapida. Iata patru metode, de la cea mai simpla la cea mai completa.

Metoda 1: Verificare rapida in package-lock.json

Cauta direct in fisierul package-lock.json daca ai versiunile compromise:

# Cauta in package-lock.json toate pachetele afectate
grep -E '"(keyv|flat-cache|file-entry-cache|cacheable-request|cacheable|cache-manager|@cacheable/[^"]+|ecto)"' package-lock.json

Daca gasesti oricare dintre aceste pachete cu versiunile mentionate mai sus, esti afectat.

Metoda 2: npm ls pentru arborele de dependente

# Verifica daca keyv apare in dependente
npm ls keyv 2>/dev/null

# Verifica cache-manager
npm ls cache-manager 2>/dev/null

# Verifica toate pachetele afectate deodata
npm ls keyv flat-cache file-entry-cache cacheable-request cacheable cache-manager ecto 2>/dev/null

Nu te ingrijora daca apar ca dependente indirecte — asta inseamna ca un alt pachet le foloseste si trebuie actualizat.

Metoda 3: Cauta fisierele malitioase in node_modules

# Cauta setup.mjs — dropper-ul
find node_modules -name "setup.mjs" -type f 2>/dev/null

# Cauta Math_Symbol.js — payload-ul
find node_modules -name "Math_Symbol.js" -type f 2>/dev/null

# Cauta preinstall script in package.json-urile din node_modules
grep -r '"preinstall".*setup.mjs' node_modules/*/package.json 2>/dev/null

Daca gasesti oricare dintre aceste fisiere, nu rula nimic. Sterge imediat node_modules si package-lock.json.

Metoda 4: Verifica-ti credentialele

# Verifica daca ai token-uri npm stocate
cat ~/.npmrc

# Verifica daca ai token-uri GitHub stocate
cat ~/.config/gh/hosts.yml 2>/dev/null

# Verifica variabilele de mediu AWS
echo $AWS_ACCESS_KEY_ID
echo $AWS_SECRET_ACCESS_KEY
echo $AWS_SESSION_TOKEN

Ce faci imediat daca esti afectat

Daca ai gasit orice semn ca proiectul tau a folosit un pachet compromis, urmeaza pasii astia in ordine. Nu sari peste niciunul.

Pasul 1: Sterge si reinstaleaza curat

# Sterge node_modules si lockfile-ul
rm -rf node_modules package-lock.json

# Reinstaleaza cu versiuni sigure
npm install

Atentie: daca in package.json ai specificat versiuni exacte ("keyv": "6.0.0"), schimba-le intai la o versiune sigura sau elimina dependenta temporar.

Pasul 2: Roteste TOATE token-urile si cheile

Token-uri npm:

• Intra pe npmjs.com/settings/tokens
• Sterge toate token-urile existente
• Genereaza un token nou cu 2FA activat
• Actualizeaza-l in CI/CD si local

Token-uri GitHub:

• Intra pe github.com/settings/tokens
• Revoca toate PAT-urile (ghp_, gho_, ghs_)
• Genereaza token-uri noi
• Verifica si token-urile OIDC din GitHub Actions

Chei AWS:

• Intra in AWS Console → IAM → Users → Security credentials
• Dezactiveaza si sterge toate cheile de acces suspecte
• Roteste cheile existente
• Verifica Secrets Manager pentru acces neautorizat
• Verifica CloudTrail pentru activitate suspecta din ultimele 24-48 de ore

Pasul 3: Audit pe repository-uri GitHub

• Verifica daca au fost create repository-uri noi pe contul tau (in special cu nume „Shai-Hulud”)
• Verifica daca exista commit-uri necunoscute in repo-urile tale
• Revizuieste accesul la organizatie si membrii noi
• Verifica webhook-urile si deploy key-urile

Pasul 4: Verifica CI/CD

• Daca folosesti GitHub Actions, roteste toate secretele din workflow-uri
• Verifica daca runnerele self-hosted au fost compromise
• Verifica logurile de build pentru activitate suspecta

Pasul 5: Verifica infrastructura

• Daca ai credentiale AWS expuse, verifica ca nimeni nu a lansat resurse noi (EC2, Lambda, S3)
• Verifica billing-ul AWS pentru activitate neasteptata
• Verifica VPC flow logs si CloudTrail

Cum te protejezi pe viitor — masuri concrete

Atacul Shai-Hulud demonstreaza ca verificarea provenientei pachetelor nu mai e suficienta. Iata ce poti face concret pentru a reduce riscul.

Dezactiveaza script-urile automate

# Dezactiveaza script-urile la instalare pentru proiectul curent
npm config set ignore-scripts true

# Sau foloseste flag-ul direct
npm install --ignore-scripts

Asta impiedica rularea automata a scriptului preinstall, postinstall etc. Atentie: unele pachete au nevoie de scripturi post-install pentru a functiona (ex: compilare binare native). Verifica manual aceste pachete si ruleaza scripturile separat daca e nevoie.

Foloseste lockfile-uri si npm ci

# In CI/CD, foloseste intotdeauna npm ci in loc de npm install
npm ci

npm ci instaleaza exact versiunile din package-lock.json. Daca lockfile-ul e curat si commit-uit, npm ci nu va adauga versiuni noi compromise.

Pin-uieste versiunile

In package.json, evita range-uri largi:

// Rau — accepta orice versiune 6.x
"keyv": "^6.0.0"

// Mai bine — exact o versiune
"keyv": "5.2.3"

Foloseste npm shrinkwrap sau tine package-lock.json sub controlul versiunilor (nu-l adauga in .gitignore).

Restrictioneaza permisiunile in GitHub Actions

# In workflow-ul tau, seteaza permisiuni minimale
permissions:
  contents: read
  packages: write  # doar daca publici pachete

Nu da contents: write sau secrets: read daca nu ai nevoie. Cu cat runner-ul are acces la mai putine secrete, cu atat un atacator poate fura mai putin.

Foloseste npm audit regulat

# Ruleaza audit inainte de fiecare deploy
npm audit --audit-level=moderate

# Sau automatizeaza cu Dependabot sau Renovate

Evalueaza dependentele inainte sa le instalezi

Inainte sa adaugi un pachet nou, verifica:

• Cati mentinatori are? (un singur mentinator = risc mare)
• Cand a fost ultimul update?
• Cate descarcari are?
• Are semnari de commit-uri?

De ce conteaza pentru dezvoltatorii si firmele din Romania

Multi dezvoltatori romani folosesc Node.js si npm zilnic — fie ca lucreaza la startup-uri, la corporatii sau ca freelanceri. Un atac de genul asta nu e doar „o problema a altora”.

Daca lucrezi la o firma care are aplicatii in productie cu Node.js, e foarte probabil ca cel putin unul dintre pachetele compromise sa fi fost in dependentele tale. keyv are 127 de milioane de descarcari saptamanale — e folosit direct sau indirect de mii de proiecte. Si nu doar el: flat-cache, file-entry-cache si cache-manager sunt pachete care apar in foarte multe tool-uri de build si framework-uri.

Daca esti freelancer si ai livrat proiecte clientilor, verifica si acele proiecte. S-ar putea ca serverele clientilor sa ruleze acum cod compromis fara ca nimeni sa stie.

Daca firma ta foloseste GitHub Actions cu secrete (chei AWS, token-uri de deploy, baze de date), un singur npm install compromis putea extrage tot secret store-ul de pe runner. Asta inseamna acces la infrastructura, baze de date, medii de productie.

Atacul asta reaminteste ca securitatea ecosistemului npm nu e doar responsabilitatea echipei npm sau a mentinatorilor. Fiecare dezvoltator trebuie sa-si protejeze propriile proiecte prin lockfile-uri, verificari periodice si restrictii de scripturi.

Vezi si articolele noastre despre malware in 10.000 de repo-uri GitHub, valul de malware din AUR pe Arch Linux si cum a fost pacalit agentul AI de la GitHub sa scurga repo-uri private — toate arata ca atacurile supply chain sunt in crestere si trebuie luate in serios.

Daca vrei sa intelegi mai bine cum functioneaza exploatarile si cum poti proteja infrastructura, citeste si ghidul nostru despre zero-day-uri publicate pe GitHub. Si daca folosesti agenti AI de coding, un studiu publicat pe 5 august 2026 arata ca ratezi 1 din 3 comenzi periculoase cand aprobi actiunile agentilor — exact genul de npm run compromis care a stat la baza atacului Shai-Hulud.

Intrebari frecvente