SlugFest: o vulnerabilitate în publicarea de încredere npm a expus peste 1.500 de pachete preluării, fără nicio credențială furată

Mecanismul de trusted publishing din npm a fost creat ca să elimine token-urile de publicare cu durată lungă. O vulnerabilitate dezvăluită recent arată că, pentru un număr mare de pachete, a înlocuit o problemă de încredere cu alta: registrul avea încredere în numele unui repository, nu în repository-ul propriu-zis. GitHub a schimbat acum modul în care funcționează noile configurații de publisher de încredere.

Ce s-a întâmplat

Cercetătorii Bloom Security au descoperit că npm lega configurația de publisher de încredere de slug-ul GitHub al repository-ului (owner/repository) și ignora ID-ul numeric permanent atribuit de GitHub, până la prima publicare reușită din acel repository.

Această breșă contează ori de câte ori un slug devine din nou disponibil: un maintainer redenumește, transferă sau șterge un repository. Oricine poate înregistra slug-ul eliberat poate:

Crea un repository nou la vechea cale owner/repository (GitHub îi atribuie un ID nou).
Adăuga un workflow de publicare npm și să-l ruleze, generând un token OIDC GitHub Actions pentru acel slug.
Schimba token-ul la npm. Slug-ul se potrivește cu configurația salvată, așa că npm emite o credențială de publicare de scurtă durată.
Publica o versiune nouă, malițioasă, a unui pachet pe care nu l-a deținut niciodată.

Tehnica, numită SlugFest, nu necesită credențiale furate, acces din interior sau condiții de cursă. Singura condiție este o legătură de publisher de încredere care indică un slug ce poate fi revendicat și care nu a fost folosită niciodată pentru publicare. Versiunea malițioasă moștenește numele pachetului, istoricul de descărcări și pachetele dependente.

Bloom Security spune că a identificat peste 1.500 de pachete expuse, descărcate în total de peste 10 milioane de ori. Problema a fost raportată către GitHub pe 6 iunie 2026.

Remedierea GitHub

GitHub a făcut trei modificări:

Fereastră de validare de 48 de ore. O configurație nouă de publisher de încredere trebuie să finalizeze o publicare reușită în maximum două zile. Prima publicare o leagă de ID-ul imuabil al repository-ului, iar configurațiile nevalidate expiră. Schimbarea identității repository-ului sau a proiectului pornește o fereastră nouă. Editările obișnuite nu.
issue_comment blocat. npm nu mai acceptă token-uri de trusted publishing provenite din evenimente GitHub Actions issue_comment. Restricția se adaugă celei existente pentru pull_request_target.
Ancorarea identității. După validare, legătura urmărește ID-ul imuabil al repository-ului, nu numele lizibil.

De ce contează

Trusted publishing (bazat pe OIDC, introdus în npm în iulie 2025) este un progres real față de token-urile statice și stă la baza atestărilor de proveniență. SlugFest ne amintește că orice sistem de încredere este la fel de solid ca legătura dintre un identificator și obiectul pe care îl numește. Dacă o simplă redenumire de repository poate rupe această legătură, se rupe și garanția.

Riscul crește odată cu automatizarea. Agenții AI de programare și pipeline-urile CI nesupravegheate tind să descarce cea mai nouă versiune a unei dependențe fără să verifice de unde provine, așa că o versiune compromisă poate rula fără niciun om în buclă. Un singur pachet preluat, cu un arbore larg de dependențe, ajunge pentru a declanșa o compromitere în cascadă, de tip vierme, ca cele pe care ecosistemul le-a mai văzut deja.

Este aceeași clasă de problemă ca în cercetarea anterioară Bloom Security, „Extension Resurrection”, în care namespace-uri nerevendicate, referite de pachete de extensii din Open VSX și VS Code Marketplace, puteau fi revendicate și umplute cu cod malițios.

Ce trebuie făcut

Dacă întrețineți pachete npm:

Auditați fiecare legătură de publisher de încredere. Confirmați că fiecare owner/repository listat duce încă la un repository pe care îl controlați.
Refaceți legătura după orice redenumire, transfer sau ștergere. Ștergeți legătura veche și creați una nouă către slug-ul actual. Includeți acest pas în procedura de redenumire a repository-urilor.
Publicați o dată pentru validare. Pentru orice legătură nouă, finalizați o publicare în fereastra de 48 de ore a GitHub, ca să fie fixată pe ID-ul imuabil al repository-ului.
Monitorizați publicările neașteptate. Setați alerte pentru orice versiune npm care nu corespunde unui build etichetat și revizuit din pipeline-ul vostru.
Verificați declanșatoarele workflow-urilor. Nu publicați din workflow-uri declanșate de comentarii sau de fork-uri.

Dacă folosiți pachete npm:

Fixați versiunile și folosiți lockfile-uri, iar modificările lockfile-ului să fie revizuite, nu acceptate automat.
Verificați proveniența (npm audit signatures) și tratați ca semnal de alarmă orice schimbare bruscă a sursei de publicare a unui pachet.
Puneți limite agenților AI și sistemelor CI. Restricționați ce pot instala uneltele automate fără revizuire și rulați build-urile cu privilegii minime, fără secrete de lungă durată.
Cartografiați lanțul de aprovizionare. Știți de ce pachete terțe depind sistemele de producție, ca să puteți reacționa rapid când unul este compromis.

Subiect relatat inițial de The Hacker News. Cercetare realizată de Bloom Security. Rezumat și analiză 4Tify.