npm Trusted Publishing: breșa SlugFest expunea 1.500 de pachete

Cercetătorii de la Bloom Security au descoperit că Trusted Publishing, mecanismul npm care înlocuiește tokenurile de publicare cu durată lungă, permitea publicarea de versiuni noi ale unui pachet străin fără a fura vreo credențială: era suficient să înregistrezi pe GitHub numele unui repository lăsat liber de întreținător. Potrivit Bloom, pachetele expuse erau peste 1.500. Vulnerabilitatea, numită SlugFest, a fost corectată de GitHub, proprietarul npm, printr-o modificare anunțată pe 2 octombrie 2026. Au scris despre ea, pe 13 octombrie, Help Net Security, CSO Online și The Hacker News.

Ce s-a întâmplat

Trusted Publishing, disponibil pentru toți din iulie 2025, se bazează pe OpenID Connect: întreținătorul îi indică lui npm ce repository GitHub și ce fișier de workflow pot publica pachetul. Când workflow-ul rulează, GitHub îi emite un token de identitate semnat, pe care npm îl schimbă cu o credențială de publicare valabilă câteva minute.

Problema, potrivit Bloom, era în felul în care npm verifica repository-ul: doar după numele lizibil owner/repo (slug-ul) și numele fișierului de workflow. GitHub atribuie fiecărui repository și fiecărui proprietar și un identificator numeric permanent, care nu se schimbă la redenumiri și transferuri și care este deja prezent în token, dar npm nu îl verifica.

Bloom a demonstrat atacul de la un capăt la altul pe un pachet și pe repository-uri aflate sub propriul control, publicând o versiune nouă din repository-ul unei alte organizații care ocupase numele eliberat. Potrivit CSO Online, cercetătorii spun că nu au observat exploatări reale; pentru Help Net Security au precizat că nu se știe dacă cineva a folosit vulnerabilitatea.

Detalii tehnice

Lanțul descris de surse este următorul:

1. întreținătorul redenumește, transferă sau șterge repository-ul legat de pachet, sau redenumește ori șterge contul proprietar, fără a elimina configurația Trusted Publishing;
2. vechiul slug redevine disponibil;
3. atacatorul creează un repository cu acel nume și adaugă un workflow GitHub Actions cu același nume de fișier prevăzut de configurație;
4. npm acceptă tokenul și emite credențiala de publicare: atacatorul publică o versiune nouă a pachetului.

Nu sunt necesare compromiterea contului GitHub sau npm al întreținătorului și nici furtul de credențiale. Versiunea publicată astfel are și o atestare de proveniență validă, semnată, care indică însă repository-ul atacatorului. O versiune malițioasă poate conține un script postinstall, pe care npm îl rulează automat pe fiecare mașină care instalează actualizarea, inclusiv în pipeline-urile de CI.

Potrivit Help Net Security, GitHub retrage deja numele repository-urilor cu peste 100 de clonări în săptămâna dinaintea redenumirii sau ștergerii contului proprietar: acest lucru proteja o parte dintre pachete, iar Bloom spune că a ținut cont de el, numărând doar slug-urile care puteau fi efectiv înregistrate.

Cifrele Bloom: peste 1.500 de pachete, peste 10 milioane de descărcări în total și peste un milion pe lună. Potrivit CSO Online, un singur pachet depășea 200.000 de descărcări lunare, iar printre pachetele expuse se află scanere de securitate, instrumente de autentificare și biblioteci criptografice. Bloom nu publică numele pachetelor. Tot potrivit Bloom, informație relatată doar de Help Net Security, și integrarea Trusted Publishing cu GitLab are aceeași slăbiciune.

În lectura noastră, tehnica MITRE ATT&CK relevantă este T1195.001 (Compromise Software Dependencies and Development Tools).

Corecția și calendarul

Potrivit celor relatate de Bloom pentru Help Net Security, raportul a fost trimis prin programul de bug bounty al GitHub pe HackerOne pe 6 iunie și validat pe 9 iunie; ultimul răspuns primit datează din 8 iulie, iar șase reveniri ulterioare, inclusiv o cerere de mediere către HackerOne, au rămas fără răspuns.

Modificările, potrivit GitHub și documentației npm citate de surse:

• configurațiile Trusted Publishing nevalidate expiră după 48 de ore de la creare și nu mai autorizează publicări;
• prima publicare reușită leagă configurația de identitatea imuabilă a repository-ului;
• potrivit CSO Online, npm respinge acum și tokenurile emise de workflow-uri declanșate de evenimentul issue_comment, pe lângă restricția deja existentă pentru pull_request_target.

Help Net Security observă că declarația GitHub nu clarifică dacă configurațiile care publicaseră deja înainte de modificare au fost legate retroactiv de identitate. De aceea Bloom le cere întreținătorilor să își revizuiască oricum configurațiile existente.

Impactul pentru companiile europene și italiene

npm este registrul de referință pentru JavaScript și TypeScript: îl folosesc aplicații web, instrumente de dezvoltare și pipeline-uri de build în aproape toate companiile care dezvoltă software. Un pachet deturnat rulează cod pe stațiile dezvoltatorilor și pe runnerele de CI, unde se află tokenuri, chei și accese la sistemele de producție.

Bloom subliniază rolul agenților IA de programare: pe baza datelor colectate în câteva zeci de organizații, estimează aproximativ 70 de pachete instalate de agenți în fiecare lună pe endpoint și aproximativ 350 pe mașinile dezvoltatorilor, fără a număra dependențele, de obicei fără vreo verificare a pachetului sau a întreținătorului său.

Pentru entitățile NIS2, securitatea lanțului de aprovizionare și a dezvoltării este una dintre măsurile cerute: un caz ca acesta trebuie luat în considerare atât pentru software-ul pe care compania îl publică pe npm, cât și pentru cel pe care îl folosește.

Ce trebuie făcut imediat

1. Dacă publici pachete cu Trusted Publishing: rulează npm trust list și verifică dacă fiecare repository indicat mai există și este sub controlul tău. Șterge și recreează configurațiile care indică repository-uri redenumite sau transferate și elimină configurația înainte de a șterge un repository sau de a redenumi un cont.
2. Verifică istoricul versiunilor pachetelor tale: versiunile pe care nu le recunoști, sau cu o atestare de proveniență care indică alt repository decât al tău, trebuie retrase și raportate.
3. Dacă folosești pachete npm: neavând o listă cu care să compari, verifică dacă atestarea de proveniență a versiunilor noi indică repository-ul din care ar trebui să provină proiectul.
4. Redu impactul scripturilor de instalare: fixează versiunile cu fișierul de lock și, unde este posibil, dezactivează scripturile de instalare în pipeline-uri (--ignore-scripts).
5. Controlează instalările făcute de agenții IA, așa cum recomandă Bloom: stabilește ce pot instala dezvoltatorii și agenții și ține un inventar al dependențelor și instrumentelor folosite.

Cum ajută ARXDOME

ARX Sentry colectează inventarul de software și procese al computerelor și serverelor: te ajută să știi unde rulează instrumentele de dezvoltare și runnerele care trebuie verificate. Dacă o mașină a instalat o versiune suspectă, ARX Shield îți permite să o izolezi de rețea până la finalizarea verificărilor și a rotației secretelor.

Ultima actualizare: 13 octombrie 2026