Attacco a Red Hat tramite pacchetti npm compromessi: anche a giugno la pressione sulla supply chain software non molla la presa. Alcune versioni di librerie pubblicate sotto lo scope @redhat-cloud-services contenevano codice malevolo capace di attivarsi da solo durante l’installazione e di rubare credenziali da ambienti di sviluppo, piattaforme cloud e sistemi CI/CD. La scoperta arriva da un’analisi dei ricercatori di StepSecurity, e merita attenzione per la portata dell’operazione.
Il problema riguarda versioni distribuite il 1° giugno 2026. Su npm il simbolo @ identifica uno scope, ossia un gruppo di pacchetti legati a un’organizzazione o a un produttore. Nel caso di Red Hat parliamo di librerie JavaScript e TypeScript usate per costruire interfacce web, dashboard amministrative, componenti frontend e client API collegati ai suoi servizi cloud. Roba che gli sviluppatori integrano nelle proprie applicazioni perché offre funzionalità già pronte, senza dover reinventare la ruota ogni volta.
Come è saltata fuori la compromissione
Durante un controllo di routine, StepSecurity ha notato comportamenti strani in diversi pacchetti pubblicati nello scope. Si tratta di librerie che totalizzano migliaia di download a settimana, quindi qualsiasi modifica malevola può diffondersi in fretta tra ambienti aziendali, sistemi di test e infrastrutture di sviluppo sparse ovunque. Il dettaglio che ha fatto suonare il campanello è la presenza di uno script preinstall: un meccanismo che permette di eseguire automaticamente del codice prima che il pacchetto sia installato del tutto. È una funzione legittima, usata di continuo dagli sviluppatori, ma che si presta benissimo a diventare un veicolo per il malware.
In sostanza il codice sospetto si attivava appena veniva lanciato il comando npm install. Nessun bisogno di avviare applicazioni o cliccare su file: bastava installare la dipendenza e il gioco era fatto. L’analisi tecnica ha mostrato che il codice dannoso era nascosto con varie tecniche di offuscamento, con file JavaScript dalle dimensioni anomale, decisamente più grandi del normale per librerie di questo genere.
Il furto di credenziali e il comportamento da worm
L’obiettivo principale era il furto di credenziali. Una volta in esecuzione, il codice andava a caccia di token, chiavi di accesso e configurazioni presenti sia sulle workstation degli sviluppatori che negli ambienti di automazione. Tra i bersagli individuati ci sono i token di GitHub Actions, le credenziali AWS, le configurazioni Google Cloud, gli account Azure, i token HashiCorp Vault, i file Kubernetes e le credenziali npm. Il malware setacciava anche file molto comuni negli ambienti di sviluppo come .env, ~/.npmrc, ~/.aws/credentials e le chiavi SSH conservate nelle cartelle personali degli utenti.
Per chi attacca, questi dati valgono oro. Una singola chiave può aprire le porte a repository privati, infrastrutture cloud o sistemi aziendali critici. Nel caso di GitHub Actions, il codice provava addirittura a recuperare segreti direttamente dalla memoria del runner che esegue i workflow, intercettando credenziali già caricate durante i processi automatici.
C’è poi l’aspetto che preoccupa di più gli esperti: la capacità di auto-propagazione. Se riesce a mettere le mani su token npm con privilegi sufficienti, il codice tenta di pubblicare nuove versioni compromesse di altri pacchetti. Un singolo account violato diventa così il trampolino per ulteriori infezioni, un comportamento che lo avvicina parecchio a quello di un worm informatico: ogni macchina colpita amplia la diffusione senza che gli aggressori debbano muovere un dito.
L’episodio dei pacchetti @redhat-cloud-services conferma quanto le dipendenze software siano un punto debole per la sicurezza informatica. Molti considerano npm install un gesto banale, di routine, ma ogni dipendenza porta con sé codice di terze parti che può eseguire operazioni sul sistema locale. Per questo sempre più aziende aggiungono controlli sulle librerie esterne, rimandano l’installazione delle versioni appena pubblicate e tengono d’occhio con maggiore attenzione le fasi di build e distribuzione. Precauzioni che, alla luce di questo attacco, non sono più una semplice buona pratica ma una necessità concreta.