Npm introduce staged publishing contro gli attacchi supply chain su pacchetti JavaScript

L’ecosistema npm introduce una delle modifiche di sicurezza più importanti degli ultimi anni con il debutto dello staged publishing e di nuovi controlli sulle installazioni delle dipendenze. Le novità, annunciate da GitHub il 22 maggio 2026 per la CLI npm 11.15.0 o successiva, arrivano in un momento particolarmente critico per la supply chain JavaScript dopo la scoperta delle campagne malevole TrapDoor e degli hook postinstall distribuiti in centinaia di repository pubblici. L’obiettivo delle nuove funzioni è ridurre drasticamente il rischio di pubblicazioni compromesse, token rubati e installazioni automatizzate di payload maligni all’interno di workflow CI/CD e ambienti di sviluppo locali. La nuova strategia di sicurezza di npm introduce una verifica umana obbligatoria prima che un pacchetto diventi disponibile sul registry pubblico. Parallelamente, i nuovi flag di installazione limitano il caricamento automatico di dipendenze provenienti da fonti non registrate, tarball remoti o repository Git non autorizzati. L’iniziativa rappresenta una risposta diretta all’aumento degli attacchi contro sviluppatori crypto, piattaforme DeFi, ambienti AI e repository open source sempre più sfruttati dai gruppi cybercriminali.

TrapDoor colpisce npm con centinaia di pacchetti crypto stealer

La campagna TrapDoor è stata individuata dai ricercatori di Socket il 19 maggio 2026 e risulta una delle operazioni supply chain più estese dell’ultimo periodo. L’attività malevola rimane attiva fino al 24 maggio coinvolgendo simultaneamente gli ecosistemi npm, PyPI e Cargo. Su npm gli attaccanti pubblicano pacchetti apparentemente legittimi progettati per imitare utility di sviluppo, tool di auditing per ambienti DeFi e strumenti dedicati ai workflow AI.

Tra i nomi individuati compaiono project-init-tools 1.5.1, model-switch-router 1.5.1, build-scripts-utils 1.5.1 e dev-env-bootstrapper 1.5.2. I pacchetti sembrano normali librerie per automazione e sviluppo ma contengono payload in grado di sottrarre asset digitali, seed wallet, chiavi private e informazioni sensibili memorizzate sui sistemi compromessi. Secondo l’analisi di Socket, la pubblicazione dei pacchetti malevoli avviene in modo estremamente rapido e coordinato. I rilevamenti mostrano upload concentrati il 24 maggio 2026 tra le 02:11 UTC e le 11:19 UTC, con identificazione quasi immediata da parte dei sistemi di monitoraggio. Complessivamente vengono censiti 384 artefatti malevoli collegati alla stessa famiglia di crypto stealer distribuiti nell’arco di una sola settimana. La strategia degli attaccanti punta sulla fiducia automatica degli sviluppatori verso nomi credibili e versioni incrementalmente plausibili. Molti progetti colpiti operano in settori dove la rapidità di deployment supera spesso i controlli manuali di sicurezza, condizione ideale per compromettere workflow automatizzati.

Gli hook postinstall malevoli sfruttano package.json e GitHub Actions

Parallelamente alla campagna TrapDoor, Socket individua un secondo vettore di attacco basato su hook postinstall maligni inseriti in oltre 700 repository pubblici su GitHub. L’operazione parte inizialmente da otto pacchetti Packagist legati all’ecosistema PHP ma si espande rapidamente verso repository che integrano tooling JavaScript. L’attaccante identificato come parikhpreyash4 modifica file package.json inserendo script postinstall capaci di scaricare automaticamente un binario Linux durante l’esecuzione di npm install. Il comando utilizza curl -skL per recuperare un file chiamato gvfsd-network da release GitHub controllate dal threat actor.

Il payload viene salvato nel percorso /tmp/.sshd, reso eseguibile e avviato in background. La combinazione di opzioni utilizzate dagli attaccanti disabilita la verifica TLS, sopprime gli errori e nasconde l’attività durante le fasi di build automatizzata. Il nome scelto per il file simula inoltre un normale processo di sistema Linux, rendendo più difficile individuare il malware durante controlli superficiali.

Tra i progetti coinvolti figurano repository popolari come devdojo/wave, che supera le 6400 stelle GitHub, insieme a devdojo/genesis, katanaui/katana, elitedevsquad/sidecar-laravel e r2luna/brain. Molti di questi starter kit attivano automaticamente npm install nella root del progetto, consentendo l’esecuzione immediata del payload.

Gli attacchi supply chain sfruttano ecosistemi cross-language

L’incidente evidenzia un problema sempre più diffuso negli ambienti open source moderni: la superficie di attacco cross-ecosystem. Molti sviluppatori PHP concentrano i controlli di sicurezza su composer.json trascurando la presenza di package.json utilizzati per build frontend, asset pipeline e workflow JavaScript. Gli attaccanti sfruttano questa separazione culturale tra ecosistemi per introdurre payload Node.js all’interno di repository percepiti principalmente come PHP. Lo stesso malware compare anche in file .github/workflows, trasformando pipeline GitHub Actions in vettori di esecuzione remota. La rimozione dei pacchetti da Packagist avviene rapidamente ma il problema resta aperto per branch dinamici come dev-main e dev-master, che rischiano di reintrodurre automaticamente codice malevolo a ogni aggiornamento. Alcuni maintainer ripristinano immediatamente commit puliti con messaggi espliciti legati alla sicurezza, mentre altri repository mantengono ancora hook compromessi nei branch principali.

GitHub introduce staged publishing per bloccare pubblicazioni compromesse

Per contrastare questi scenari, GitHub introduce ufficialmente lo staged publishing all’interno della CLI npm 11.15.0. Il nuovo sistema modifica radicalmente il modello di pubblicazione dei pacchetti imponendo un passaggio di approvazione manuale prima che il contenuto diventi installabile dal registry pubblico. Invece del tradizionale comando npm publish, gli sviluppatori utilizzano npm stage publish. Il comando carica il tarball precompilato in una coda di staging senza renderlo immediatamente disponibile agli utenti finali. Solo un maintainer autorizzato con 2FA attivo può approvare manualmente la pubblicazione definitiva tramite CLI oppure attraverso l’interfaccia web di npmjs.com.

Il sistema richiede almeno Node.js 22.14.0 e può essere utilizzato soltanto per pacchetti già esistenti sul registry npm. Questo significa che non supporta pubblicazioni iniziali ma rafforza significativamente la sicurezza dei rilasci successivi.

Npm aggiunge approvazione umana obbligatoria e verifica offline

Il workflow dello staged publishing si sviluppa in tre fasi principali. Lo sviluppatore pubblica inizialmente il pacchetto attraverso npm stage publish senza necessità di autenticazione 2FA. Successivamente il maintainer può visualizzare la coda tramite npm stage list oppure analizzare singoli upload con npm stage view. Uno degli aspetti più importanti riguarda la possibilità di scaricare il tarball con npm stage download per effettuare ispezioni offline prima dell’approvazione finale. Questa funzione permette ai team di sicurezza di verificare dipendenze, script installazione e contenuto effettivo dei pacchetti senza esporre immediatamente il registry pubblico a potenziali compromissioni. L’approvazione definitiva richiede obbligatoriamente verifica 2FA e può avvenire tramite npm stage approve oppure dal tab dedicato su npmjs.com. Il sistema introduce quindi una vera separazione tra automazione CI/CD e validazione umana finale.

Trusted publishing OIDC si integra con npm stage publish

Lo staged publishing si integra direttamente con il sistema di trusted publishing basato su OIDC. Le organizzazioni possono configurare publisher trusted in modalità stage-only, consentendo ai workflow automatizzati di continuare a operare senza interazioni manuali durante il caricamento iniziale del pacchetto. Solo l’approvazione finale deve avvenire da parte di un maintainer umano su dispositivo considerato affidabile. Questa architettura rafforza la cosiddetta proof of presence riducendo drasticamente il rischio che token rubati o pipeline compromesse possano pubblicare malware direttamente sul registry npm. Le configurazioni bulk introdotte da GitHub nel febbraio 2026 semplificano ulteriormente la migrazione. In molti casi è sufficiente aggiornare la CLI npm e sostituire npm publish con npm stage publish nei workflow YAML esistenti.

Npm 11.15.0 introduce nuovi flag contro dipendenze non registrate

Oltre allo staged publishing, la versione npm 11.15.0 introduce nuovi flag di controllo per limitare installazioni da fonti non verificate. I parametri –allow-file, –allow-remote e –allow-directory consentono agli sviluppatori di definire esplicitamente quali origini siano autorizzate durante le installazioni. I valori disponibili sono all e none, configurabili tramite .npmrc o direttamente in package.json. Il flag già esistente –allow-git continua a controllare installazioni provenienti da repository Git come URL github: o git+. Per motivi di compatibilità, npm mantiene temporaneamente il default permissivo all, ma la futura major release npm v12 imposterà automaticamente –allow-git=none. Le organizzazioni possono comunque adottare subito policy più restrittive configurando manualmente i flag su none. Questi controlli impediscono a package malevoli di scaricare automaticamente tarball remoti, binari locali o dipendenze esterne non autorizzate. In pratica, npm trasforma installazioni implicite in operazioni esplicitamente approvate dal team di sviluppo.

Le nuove difese npm riducono il rischio per CI/CD e sviluppatori crypto

Le nuove funzionalità introdotte da npm rappresentano una risposta concreta all’evoluzione degli attacchi supply chain nel mondo JavaScript. Lo staged publishing elimina il rischio di pubblicazioni accidentali o compromesse da credenziali sottratte durante workflow CI/CD, mentre i nuovi flag di installazione limitano drasticamente la superficie di attacco legata a dipendenze esterne e script postinstall. Per sviluppatori crypto, piattaforme DeFi e ambienti AI, bersagli principali della campagna TrapDoor, questi strumenti introducono finalmente meccanismi di controllo più granulari senza sacrificare completamente l’automazione dei rilasci. Il panorama npm del 2026 mostra chiaramente come gli attaccanti sfruttino la velocità dei processi DevOps moderni e la fiducia implicita verso package open source. La risposta di GitHub punta invece su approvazione umana, trasparenza delle fonti e verifica esplicita delle dipendenze. I team che adotteranno rapidamente npm stage publish e le nuove policy restrittive otterranno un vantaggio significativo nella protezione della propria supply chain software.