Il problema: la fiducia basata su un nome che può cambiare proprietario

A inizio ottobre 2026 GitHub ha corretto una falla nel sistema npm Trusted Publishing che, secondo la società di sicurezza Bloom Security, lasciava più di 1.500 pacchetti (oltre 10 milioni di download complessivi) esposti a un takeover senza bisogno di rubare alcuna credenziale. Il bug, battezzato SlugFest, è un ottimo caso di studio per chiunque gestisca pipeline CI/CD: mostra come un meccanismo pensato per eliminare i segreti a lunga durata possa comunque fallire se il vincolo di fiducia è ancorato alla cosa sbagliata.

Trusted Publishing è arrivato su npm a luglio 2025 come alternativa ai token di pubblicazione statici. L’idea è elegante: il provider CI/CD (tipicamente GitHub Actions) genera un token OIDC di breve durata ad ogni esecuzione del workflow; npm lo scambia con una credenziale di pubblicazione temporanea solo se il token corrisponde a una configurazione di “trusted publisher” preregistrata sul pacchetto (repository, workflow, ambiente). Niente più NPM_TOKEN salvato nei secret di GitHub, niente più credenziali che restano valide per mesi se qualcuno le intercetta.

Dove si è rotto il modello: lo slug non è un identificatore stabile

Il difetto individuato dal ricercatore Golan Myers di Bloom Security riguarda a cosa è legata la configurazione di trusted publisher. npm vincola il publisher allo slug del repository, cioè alla stringa owner/repository, e non all’ID numerico immutabile che GitHub assegna internamente a ogni repository. Il token OIDC generato da GitHub Actions contiene in realtà anche quell’ID, ma npm lo ignora fino a quando non avviene la prima pubblicazione riuscita da quel repository.

Myers l’ha descritta con un’immagine efficace: è come una serratura che controlla l’indirizzo scritto sulla porta invece di verificare chi sia il legittimo proprietario della casa. Se uno slug si libera — perché il repository viene rinominato, trasferito a un altro account o cancellato — chiunque lo rioccupi su GitHub eredita automaticamente la fiducia che npm aveva associato a quel nome.

La catena d’attacco passo per passo

1. L’attaccante identifica un pacchetto npm con un trusted publisher configurato ma che non ha mai completato una prima pubblicazione tramite quel canale, puntato su uno slug owner/repository ormai libero (repository rinominato, trasferito o rimosso).
2. Crea su GitHub un nuovo repository con esattamente quello slug. GitHub gli assegna un ID numerico diverso da quello originale, ma lo slug torna a esistere.
3. Configura nel repository un workflow di pubblicazione npm (lo stesso nome file che il maintainer originale avrebbe probabilmente usato) e lo esegue tramite GitHub Actions.
4. Il workflow genera un token OIDC che contiene lo slug “riconquistato”. L’attaccante lo invia all’endpoint di scambio di npm.
5. npm confronta solo lo slug con la configurazione registrata, trova corrispondenza e rilascia una credenziale di pubblicazione temporanea senza alcuna verifica aggiuntiva sull’identità del repository.
6. Con quella credenziale l’attaccante pubblica una versione malevola del pacchetto, ereditando reputazione, numero di download e, soprattutto, tutti i progetti che lo dichiarano come dipendenza.

Bloom Security sottolinea un aggravante specifico del 2026: gli agenti AI che risolvono dipendenze in autonomia tendono a scegliere sempre l’ultima versione pubblicata e raramente verificano la provenienza reale di un pacchetto, rendendo questo tipo di attacco alla supply chain ancora più efficace su pipeline automatizzate.

Timeline della scoperta e della correzione

• Luglio 2025 — Trusted Publishing con OIDC diventa generalmente disponibile su npm.
• 6 giugno 2026 — Bloom Security segnala la vulnerabilità a GitHub tramite il programma HackerOne.
• 9 giugno 2026 — GitHub valida la segnalazione.
• 2 ottobre 2026 — GitHub pubblica il changelog con la correzione definitiva.

Come GitHub ha chiuso la falla

La correzione agisce proprio sul punto debole: il periodo in cui una configurazione di trusted publisher esiste ma non è ancora stata “convalidata” da una pubblicazione reale.

• Una nuova configurazione di trusted publisher ora scade dopo 48 ore se non viene usata per completare con successo una prima pubblicazione.
• Dopo quella prima pubblicazione riuscita, la configurazione diventa vincolata all’identità immutabile del repository (l’ID numerico), non più solo al nome.
• Qualsiasi modifica che cambi repository o identità del progetto richiede la creazione di una nuova relazione di fiducia, che riparte da una nuova finestra di 48 ore; le modifiche ordinarie non la riavviano.
• npm ora rifiuta i token di Trusted Publishing generati da eventi issue_comment di GitHub Actions, estendendo una restrizione già esistente su pull_request_target — entrambi trigger storicamente abusati per far eseguire codice a partire da contenuti controllati da terzi (ad esempio un commento su una pull request).

Cosa deve controllare chi mantiene pacchetti npm

Anche con la falla corretta, vale la pena fare un controllo preventivo sulle proprie configurazioni:

• Verificare ogni trusted publisher configurato sui propri pacchetti e confermare che il repository collegato sia ancora effettivamente sotto il proprio controllo.
• Dopo una rinomina, un trasferimento o la cancellazione di un repository, eliminare e ricreare il vincolo di trusted publisher sullo slug corretto, piuttosto che lasciarlo “in sospeso”.
• Preferire trigger di pubblicazione più sicuri — push su tag, release o workflow_dispatch — evitando pull_request_target e issue_comment.
• Bloccare le versioni delle dipendenze dove possibile e controllare con attenzione gli script postinstall, specialmente nei repository dove un agente AI installa pacchetti senza supervisione diretta.
• Monitorare pubblicazioni inattese e verificare le attestazioni di provenance generate automaticamente da npm.

Il caso SlugFest è un buon promemoria generale, non solo per npm: qualsiasi sistema di trust basato su OIDC “federato” (PyPI ha un meccanismo molto simile) deve ancorare la fiducia a un identificatore immutabile, non a un nome che può essere liberato e rivendicato da chiunque. Chi gestisce pipeline di pubblicazione automatizzate, su npm o altrove, farebbe bene a verificare quale dei due modelli stia effettivamente usando.

Fonte: The Hacker News e Cyber Security News.