npm Trusted Publishing: falla SlugFest esponeva 1.500 pacchetti

I ricercatori di Bloom Security hanno scoperto che Trusted Publishing, il meccanismo di npm che sostituisce i token di pubblicazione a lunga durata, permetteva di pubblicare nuove versioni di un pacchetto altrui senza rubare nessuna credenziale: bastava registrare su GitHub il nome di un repository lasciato libero dal manutentore. Secondo Bloom i pacchetti esposti erano più di 1.500. La vulnerabilità, chiamata SlugFest, è stata corretta da GitHub, proprietaria di npm, con una modifica annunciata il 2 ottobre 2026. Ne hanno scritto il 13 ottobre Help Net Security, CSO Online e The Hacker News.

Cosa è successo

Trusted Publishing, disponibile per tutti da luglio 2025, si basa su OpenID Connect: il manutentore indica a npm quale repository GitHub e quale file di workflow possono pubblicare il pacchetto. Quando il workflow gira, GitHub gli rilascia un token di identità firmato, che npm scambia con una credenziale di pubblicazione valida per pochi minuti.

Il problema, secondo Bloom, era nel modo in cui npm verificava il repository: solo con il nome leggibile owner/repo (lo slug) e il nome del file di workflow. GitHub assegna a ogni repository e a ogni proprietario anche un identificativo numerico permanente, che non cambia con rinomine e trasferimenti e che è già presente nel token, ma npm non lo controllava.

Bloom ha dimostrato l’attacco dall’inizio alla fine su un pacchetto e su repository sotto il proprio controllo, pubblicando una nuova versione dal repository di un’altra organizzazione che aveva occupato il nome liberato. Secondo CSO Online, i ricercatori dicono di non aver osservato sfruttamenti reali; a Help Net Security hanno precisato che non è noto se qualcuno abbia usato la falla.

Dettagli tecnici

La catena descritta dalle fonti è questa:

1. il manutentore rinomina, trasferisce o cancella il repository collegato al pacchetto, oppure rinomina o cancella l’account proprietario, senza togliere la configurazione di Trusted Publishing;
2. il vecchio slug torna disponibile;
3. l’attaccante crea un repository con quel nome e aggiunge un workflow di GitHub Actions con lo stesso nome di file previsto dalla configurazione;
4. npm accetta il token e rilascia la credenziale di pubblicazione: l’attaccante pubblica una nuova versione del pacchetto.

Non servono la compromissione dell’account GitHub o npm del manutentore né il furto di credenziali. La versione pubblicata in questo modo ha anche un’attestazione di provenienza valida, firmata, che però indica il repository dell’attaccante. Una versione malevola può contenere uno script postinstall, eseguito automaticamente da npm su ogni macchina che installa l’aggiornamento, comprese le pipeline di CI.

Secondo Help Net Security, GitHub ritira già i nomi dei repository con più di 100 clonazioni nella settimana prima della rinomina o cancellazione dell’account proprietario: questo proteggeva una parte dei pacchetti, e Bloom dice di averne tenuto conto contando solo gli slug effettivamente registrabili.

I numeri di Bloom: oltre 1.500 pacchetti, più di 10 milioni di download complessivi e più di un milione al mese. Secondo CSO Online uno solo superava i 200.000 download mensili, e tra i pacchetti esposti ci sono scanner di sicurezza, strumenti di autenticazione e librerie crittografiche. Bloom non pubblica i nomi dei pacchetti. Sempre secondo Bloom, riportato solo da Help Net Security, anche l’integrazione di Trusted Publishing con GitLab ha la stessa debolezza.

Nella nostra lettura la tecnica MITRE ATT&CK pertinente è T1195.001 (Compromise Software Dependencies and Development Tools).

La correzione e i tempi

Secondo quanto Bloom ha riferito a Help Net Security, la segnalazione è arrivata tramite il programma di bug bounty di GitHub su HackerOne il 6 giugno ed è stata validata il 9 giugno; l’ultima risposta ricevuta risale all’8 luglio, e sei solleciti successivi, compresa una richiesta di mediazione a HackerOne, sono rimasti senza risposta.

Le modifiche, secondo GitHub e la documentazione di npm citate dalle fonti:

• le configurazioni di Trusted Publishing non validate scadono dopo 48 ore dalla creazione e non autorizzano più pubblicazioni;
• la prima pubblicazione riuscita lega la configurazione all’identità immutabile del repository;
• secondo CSO Online, npm rifiuta ora anche i token emessi da workflow avviati dall’evento issue_comment, oltre alla restrizione già esistente su pull_request_target.

Help Net Security osserva che la dichiarazione di GitHub non chiarisce se le configurazioni che avevano già pubblicato prima della modifica siano state legate all’identità in modo retroattivo. Per questo Bloom chiede ai manutentori di rivedere comunque le configurazioni esistenti.

Impatto per le aziende europee e italiane

npm è il registro di riferimento per JavaScript e TypeScript: lo usano applicazioni web, strumenti di sviluppo e pipeline di build in quasi tutte le aziende che sviluppano software. Un pacchetto dirottato esegue codice sulle postazioni degli sviluppatori e sui runner di CI, dove si trovano token, chiavi e accessi ai sistemi di produzione.

Bloom sottolinea il ruolo degli agenti IA di programmazione: dai dati raccolti in alcune decine di organizzazioni stima circa 70 pacchetti installati dagli agenti ogni mese per endpoint, e circa 350 sulle macchine degli sviluppatori, senza contare le dipendenze, di solito senza una revisione del pacchetto o del suo manutentore.

Per i soggetti NIS2 la sicurezza della catena di fornitura e dello sviluppo è una delle misure richieste: un caso come questo va considerato sia per il software che l’azienda pubblica su npm sia per quello che usa.

Cosa fare subito

1. Se pubblichi pacchetti con Trusted Publishing: esegui npm trust list e verifica che ogni repository indicato esista ancora e sia sotto il tuo controllo. Cancella e ricrea le configurazioni che puntano a repository rinominati o trasferiti, e togli la configurazione prima di cancellare un repository o rinominare un account.
2. Controlla la cronologia delle versioni dei tuoi pacchetti: versioni che non riconosci, o con un’attestazione di provenienza che indica un repository diverso dal tuo, vanno ritirate e segnalate.
3. Se usi pacchetti npm: non potendo confrontarti con un elenco, verifica che l’attestazione di provenienza delle versioni nuove indichi il repository da cui il progetto dovrebbe provenire.
4. Riduci l’impatto degli script di installazione: fissa le versioni con il file di lock e, dove possibile, disattiva gli script di installazione nelle pipeline (--ignore-scripts).
5. Governa le installazioni degli agenti IA, come raccomanda Bloom: stabilisci che cosa sviluppatori e agenti possono installare e fai l’inventario delle dipendenze e degli strumenti in uso.

Come aiuta ARXDOME

ARX Sentry raccoglie l’inventario di software e processi di computer e server: aiuta a sapere dove girano strumenti di sviluppo e runner da controllare. Se una macchina ha installato una versione sospetta, ARX Shield consente di isolarla dalla rete in attesa delle verifiche e della rotazione dei segreti.

Ultimo aggiornamento: 13 ottobre 2026