Attacco a Red Hat: malware nascosto nei pacchetti npm, a rischio credenziali cloud

Un attacco npm ha compromesso pacchetti Red Hat con un payload capace di rubare segreti da GitHub Actions, cloud provider, workstation e token npm, propagandosi come un worm.

E anche a giugno gli attacchi alla supply chain non accennano ad attenuarsi. I ricercatori di StepSecurity hanno confermato la scoperta di codice malevolo all’interno di un gruppo di pacchetti software associati a Red Hat.

Nell’occhio del ciclone c’è lo scope @redhat-cloud-services: alcune versioni distribuite il 1° giugno 2026 contenevano infatti codice in grado di attivarsi automaticamente durante l’installazione e di sottrarre credenziali da sistemi di sviluppo, ambienti cloud e piattaforme CI/CD.

La vicenda merita attenzione non soltanto per la portata dell’attacco, ma anche perché coinvolge componenti utilizzati all’interno di progetti collegati ai servizi cloud di Red Hat.

Su npm, il simbolo @ identifica uno scope, cioè un gruppo di pacchetti associati a un’organizzazione o a un produttore software. Nel caso di @redhat-cloud-services, si tratta di librerie JavaScript e TypeScript utilizzate per realizzare interfacce web, dashboard amministrative, componenti frontend e client API collegati a diversi servizi cloud sviluppati da Red Hat. Molti di questi pacchetti sono sfruttati dagli sviluppatori per integrare funzionalità già pronte nelle proprie applicazioni.

Come è stata scoperta la compromissione

Durante un’analisi di routine, StepSecurity ha individuato comportamenti anomali in diversi pacchetti pubblicati nello scope di Red Hat. Si tratta di librerie che registrano migliaia di download settimanali. Ciò significa che eventuali modifiche malevole possono propagarsi rapidamente in ambienti aziendali, sistemi di test e infrastrutture di sviluppo distribuite in tutto il mondo.

L’elemento che ha attirato immediatamente l’attenzione è stata la presenza di uno script preinstall: in npm il meccanismo consente di eseguire automaticamente del codice prima che il pacchetto sia installato completamente. La funzione è legittima e viene spesso utilizzata dagli sviluppatori, ma può trasformarsi in un veicolo estremamente efficace per distribuire malware.

In pratica, il codice sospetto entrava in azione non appena era invocato il comando npm install: l’utente non doveva avviare applicazioni o eseguire manualmente alcun file perché bastava installare la dipendenza.

L’analisi tecnica ha mostrato che il codice dannoso era stato nascosto con numerose tecniche di offuscamento. I ricercatori hanno trovato file JavaScript di dimensioni anomale, molto più grandi rispetto a quanto normalmente necessario per librerie di questo tipo.

Furto di credenziali e altre informazioni dai sistemi degli sviluppatori

La finalità principale del malware era il furto di credenziali: una volta eseguito, il codice cercava token, chiavi di accesso e configurazioni presenti sia nelle workstation degli sviluppatori che negli ambienti di automazione.

Fra gli obiettivi individuati figurano i token di GitHub Actions, le credenziali AWS, le configurazioni Google Cloud, gli account Azure, i token HashiCorp Vault, i file Kubernetes, le credenziali npm e numerosi altri dati di primaria importanza.

Il malware cercava inoltre file molto comuni negli ambienti di sviluppo, come .env, ~/.npmrc, ~/.aws/credentials e le chiavi SSH conservate nelle directory personali degli utenti.

Per un attaccante questi dati hanno un valore enorme: una singola chiave di accesso può consentire l’ingresso a repository privati, infrastrutture cloud o sistemi aziendali critici.

Nel caso di GitHub Actions, il codice malevolo tentava di recuperare segreti direttamente dalla memoria del runner che esegue i workflow. In altre parole, cercava di ottenere credenziali già caricate durante l’esecuzione dei processi automatici.

Un comportamento simile a quello di un worm

L’elemento che preoccupa maggiormente gli esperti è la capacità di auto-propagazione osservata nel codice malevolo.

Se riesce a ottenere token npm con privilegi sufficienti, il codice prova a pubblicare nuove versioni compromesse di altri pacchetti. In questo modo un singolo account violato può diventare il punto di partenza per ulteriori infezioni.

Una caratteristica del genere avvicina il comportamento del malware a quello di un worm informatico: ogni nuova macchina compromessa può contribuire ad ampliare la diffusione dell’attacco senza richiedere ulteriori interventi da parte degli aggressori.

Una conferma dei rischi nella supply chain software

L’incidente che ha coinvolto i pacchetti @redhat-cloud-services dimostra ancora una volta quanto le dipendenze software rappresentino un punto critico per la sicurezza informatica. Da mesi, purtroppo, ci troviamo a ripetere il solito ritornello.

Molti sviluppatori considerano npm install un’operazione di routine. In realtà ogni dipendenza introdotta in un progetto porta con sé codice proveniente da terze parti e potenzialmente in grado di eseguire operazioni sul sistema locale.

Per questo motivo sempre più aziende adottano controlli aggiuntivi sulle librerie esterne, ritardano l’installazione delle nuove versioni appena pubblicate e monitorano con maggiore attenzione ciò che accade durante le fasi di build e distribuzione. L’attacco scoperto da StepSecurity nei confronti di codice Red Hat mostra quanto queste precauzioni siano ormai diventate una necessità concreta e non più una semplice buona pratica.

Ti consigliamo anche

Link copiato negli appunti