npm trusted publishing ora fa scadere le configurazioni non validate
npm trusted publishing è stato rafforzato dopo che Bloom Security ha scoperto una falla che potrebbe consentire a un aggressore di pubblicare una nuova versione del npm package di qualcun altro senza rubare le credenziali del maintainer.
GitHub, proprietaria di npm, ha modificato il modo in cui vengono gestite le configurazioni di trusted publishing non validate. Una configurazione di trusted publisher appena creata ora ha 48 ore per completare il primo publish riuscito del package. Dopo quel primo publish riuscito, la configurazione viene validata ed esentata dalla scadenza. GitHub afferma che la modifica dell’identità del repository o del progetto crea una nuova relazione di trust e avvia una nuova finestra di validazione di 48 ore, mentre le modifiche ordinarie non riavviano la scadenza.
La modifica punta a una debolezza specifica nel modo in cui il trust veniva inizialmente collegato al nome di un GitHub repository. Trusted publishing, introdotto per npm nel luglio 2025, è un modo senza credenziali per pubblicare npm packages da una piattaforma di continuous integration e continuous delivery, spesso abbreviata in CI/CD, come GitHub Actions. CI/CD indica sistemi automatizzati che compilano, testano e rilasciano software per gli sviluppatori. Invece di conservare un secret npm di lunga durata, il provider CI/CD crea un OpenID Connect token di breve durata, spesso chiamato OIDC token, per una specifica esecuzione di workflow. npm verifica quindi quel token rispetto a una configurazione di publishing pre-approvata.
Questo design riduce la necessità per i maintainer di conservare e ruotare le credenziali npm, abbassando il rischio che un secret trapelato possa essere usato per pubblicare package malevoli. Crea inoltre provenance attestations per gli npm packages, ossia record che aiutano a mostrare dove è stato creato un package e chi lo ha pubblicato. La debolezza segnalata da Bloom Security non riguardava l’idea generale del publishing basato su token, ma il trust binding iniziale tra npm e il GitHub repository.
Bloom Security ha segnalato le proprie scoperte a GitHub il 6 giugno 2026. L’azienda ha dichiarato che npm registrava inizialmente l’indirizzo leggibile del repository, chiamato anche slug, nella forma owner/repository. Secondo la ricerca, npm non si basava sull’ID numerico permanente del repository di GitHub fino al primo publish riuscito da quel repository. Gli OIDC tokens di GitHub contengono ID numerici che sopravvivono a rinomine e trasferimenti dei repository, ma Bloom Security ha scoperto che npm ignorava quegli ID prima del primo publish riuscito.
Questo creava un vuoto se una configurazione di trusted publisher puntava a uno slug di repository che in seguito diventava disponibile. Bloom Security ha chiamato l’attacco SlugFest. Perché l’attacco funzionasse, il trusted publisher della vittima doveva puntare a uno slug GitHub che un aggressore poteva rivendicare, e quel repository non doveva ancora essere stato usato per pubblicare una versione del package su npm. Lo slug poteva diventare disponibile dopo che un maintainer aveva rinominato, trasferito o eliminato un repository.
Il percorso d’attacco descritto da Bloom Security è diretto. Un aggressore crea un repository nel percorso owner/repository liberato. GitHub assegna a quel nuovo repository il proprio ID numerico. L’aggressore poi crea ed esegue un workflow di npm publishing, che produce un OIDC token contenente lo slug recuperato e il nuovo ID del repository. Quando quel token viene inviato all’exchange endpoint di npm, npm vede il claim del repository corrispondente allo slug memorizzato ed emette una credenziale a tempo limitato per pubblicare. L’aggressore può quindi pubblicare una nuova versione di un package che non possiede.
L’impatto è serio perché la versione malevola apparirebbe sotto il nome legittimo del package. Beneficerebbe della reputazione esistente del package, della sua cronologia di download e delle relazioni con i progetti che dipendono da esso. Bloom Security ha dichiarato di aver trovato più di 1.500 package vulnerabili, con download complessivi superiori a 10 milioni. Nella sicurezza della supply chain, questo conta perché un solo package compromesso può essere inserito automaticamente in molti progetti downstream.
Bloom Security ha inoltre avvertito che gli AI agents in esecuzione sulle macchine degli sviluppatori possono aumentare il rischio. L’azienda ha affermato che gli agents possono risolvere le dependencies autonomamente, spesso scegliere la versione più recente e potrebbero non controllare da dove proviene un package. In quella situazione, una versione malevola pubblicata tramite uno slug di repository recuperato potrebbe essere installata ed eseguita senza che una persona riveda prima la decisione.
La risposta di GitHub aggiunge un periodo di scadenza per le nuove configurazioni di trusted publishing che non sono ancora state validate da un publish riuscito. GitHub afferma inoltre che npm ora rifiuta i trusted publishing tokens provenienti da eventi issue_comment di GitHub Actions. Questa restrizione viene aggiunta accanto a una restrizione esistente per gli eventi pull_request_target. Entrambi i tipi di evento sono importanti perché i publishing tokens dovrebbero essere accettati solo da workflow di cui npm può fidarsi per le attività di release.
Per i maintainer, il messaggio pratico è controllare se i loro binding di npm trusted publisher puntano ancora a repository sotto il loro controllo. Bloom Security consiglia agli sviluppatori di eseguire un audit dei binding di trusted publisher, confermare che lo slug elencato risolva ancora al proprio repository, eliminare e ricreare il binding se un repository è stato rinominato o trasferito, monitorare eventi di npm publish inattesi e rimuovere i trust bindings ogni volta che un repository viene eliminato, trasferito o rinominato.
Questo non è l’unico problema di supply chain che Bloom Security ha segnalato riguardo a nomi trusted e spazi non rivendicati. All’inizio di agosto, l’azienda ha dichiarato che Open VSX e Microsoft’s VS Code Marketplace consentivano agli extension packs di fare riferimento a estensioni che non esistevano nei marketplace. Bloom Security ha chiamato questa tecnica Extension Resurrection e ha affermato che 87 packs in Open VSX e 677 packs in VS Code Marketplace erano vulnerabili. In quello scenario, un aggressore poteva rivendicare uno slot di estensione vuoto e far installare codice insieme a un pack trusted. L’azienda ha osservato che le estensioni vengono eseguite con accesso completo all’host, rendendo questa una via verso remote code execution sotto un percorso di installazione dall’aspetto trusted.
Per i proprietari di siti web e le aziende, il problema npm ricorda che i siti web moderni spesso dipendono da software packages mantenuti fuori dall’organizzazione. Una piccola dependency usata in una build pipeline può influenzare un sito pubblico, un pannello di amministrazione o uno strumento interno se codice malevolo entra nella release chain. AEU-I fornisce IT, infrastruttura e consulenza security-first, un aspetto rilevante per i team che stanno rivedendo come il loro software, hosting e processi operativi gestiscono il rischio legato alle third-party dependencies.
La lezione principale è circoscritta ma importante: un’impostazione di trust basata su un nome modificabile può diventare insicura quando quel nome viene poi riutilizzato. La nuova scadenza di 48 ore di GitHub per le configurazioni npm trusted publishing non validate riduce la finestra per quella condizione specifica, ma i maintainer devono comunque ripulire i vecchi binding quando i repository vengono rinominati, spostati o eliminati.