TL; DR
Il 14 settembre 2025, i ricercatori hanno identificato Shai Hulud, un verme autoreplicante nascosto all'interno pacchetti npm, trasformando un aggiornamento di routine delle dipendenze in un aggiornamento completo attacco alla catena di approvvigionamento. Avvistato per la prima volta nel @ctrl/tinycolor pacchetto di Daniel dos Santos Pereira, Shai-Hulud raccoglie segreti, li estrae tramite repository e flussi di lavoro GitHub e si ripubblica nel registro utilizzando credenziali rubate. Nel giro di pochi giorni, il numero di pacchetti infetti è balzato da decine a centinaia, confermando che Shaihulud non è solo un altro trojan, ma un worm progettato per diffondersi automaticamente nell'ecosistema npm.
Impatto: qualsiasi sviluppatore o CI runner che installa pacchetti npm pubblici è a rischio.
Azioni immediate: bloccare le versioni note, passare alle installazioni solo con file di blocco, ruotare i token npm e GitHub, controllare i flussi di lavoro e monitorare gli indicatori di compromissione (IoC).
Cosa succede?
. Attacco alla supply chain Shai-Hulud nei pacchetti npm è uno degli incidenti più destabilizzanti della storia recente. A differenza dei trojan isolati, questo worm mescola furto di credenziali, esfiltrazione automatizzata e autoreplicazioneDi conseguenza, il periodo di contagio si è ridotto da settimane a poche ore.
Per i team DevOps, la lezione è chiara: se ogni installazione può eseguire codice, allora ogni aggiornamento delle dipendenze rappresenta un potenziale punto di violazione.
Possibili vettori iniziali e credenziali mirate
Analisi precoce indica che l'attacco è probabilmente iniziato con credenziali rubateAd esempio, campagne di phishing che falsificano npm login Oppure i prompt MFA potrebbero aver catturato i token degli sviluppatori. Una volta che gli aggressori hanno ottenuto quel primo punto d'appoggio, il worm si è diffuso incorporandosi nei pacchetti npm e rubando altri segreti da:
- file di configurazione npm piace
.npmrc, spesso contenenti token di pubblicazione. - Variabili ambientali e configurazioni con GitHub PAT e CI/CD segreti.
- Endpoint dei metadati cloud (AWS, GCP, Azure) che forniscono credenziali di breve durata per il movimento laterale.
Pertanto, il furto di credenziali è diventato il trampolino di lancio. Con token npm validi e segreti GitHub, Shai-Hulud poteva autoreplicarsi su più pacchetti e repository senza ulteriore sforzo umano.
Impatto esecutivo dell'attacco alla catena di fornitura di Shai-Hulud
Shai-Hulud è ancora attivo oggi. Questo worm accelera i tempi di impatto. Ciò che un tempo richiedeva settimane con un trojan, ora si verifica in poche ore. Di conseguenza, la diffusione è più rapida e difficile da contenere. Avanza tramite:
- Furto di token di pubblicazione npm e segreti GitHub.
- Ripubblicandosi in altri pacchetti npm.
- Aggiunta di flussi di lavoro GitHub Actions dannosi per la persistenza.
Chi è interessato:
Qualsiasi team che installi pacchetti npm pubblici è esposto. Inoltre, gli sviluppatori con token npm o GitHub memorizzati nella cache corrono un rischio elevato. Anche gli sviluppatori di CI che utilizzano segreti di ampia portata sono vulnerabili.
Rischio aziendale
L'impatto aziendale cresce rapidamente. I token rubati possono portare all'appropriazione indebita di account, al dirottamento di pacchetti e persino all'uso improprio del cloud. Inoltre, la persistenza nei flussi di lavoro di GitHub rende più difficile la pulizia. Pertanto, i team devono trattare Shai-Hulud come un incidente in corso, non come uno chiuso.
Come funziona l'attacco alla supply chain Shai-Hulud nei pacchetti npm
Obiettivi e movente dell'attaccante
La campagna è ottimizzata per tre cose:
- Il primo obiettivo è quello di rubare credenziali su larga scala Dai laptop degli sviluppatori e dai runner di CI. Tra questi rientrano i token di pubblicazione npm, i token GitHub e le credenziali cloud. Infatti, diverse analisi confermano la raccolta sistematica di dati segreti, come l'esecuzione di TruffleHog e l'interrogazione degli endpoint dei metadati cloud.
- Il secondo obiettivo è quello di propagare automaticamente abusando dei diritti di pubblicazione dei manutentori compromessi. Di conseguenza, un punto d'appoggio si espande rapidamente in molti, poiché nuove versioni infette di altri pacchetti compaiono senza ulteriore intervento umano.
- Il terzo obiettivo è quello di persistere ed esfiltrare in modo affidabile attraverso l'infrastruttura GitHub. Gli aggressori creano un repository pubblico denominato "Shai-Hulud" con un doppio base64 dati.json, e inoltre impiantano un flusso di lavoro che serializza ${{ toJSON(segreti) }} e lo pubblica su un webhook statico.
Il probabile vantaggio include l'accesso duraturo ai registri e al codice sorgente, un rapido movimento laterale verso gli account cloud e la possibilità di sfruttare ulteriormente la supply chain come arma. I report pubblici mostrano che i repository privati sono diventati pubblici con un "-migrazione" suffisso, che aumenta l'esposizione e lo slancio dei dati
All'interno del carico utile Shai-Hulud: bundle.js nei pacchetti npm
Shai-Hulud viene spedito come un grande, in bundle con Webpack e fortemente minimizzato file JavaScript (bundle.js, circa 3–3.7 MB) che viene eseguito da un post-installazione agganciare pacchetto.jsonDi conseguenza, Ogni installazione attiva automaticamente il payload. Questa progettazione nasconde gli identificatori, comprime il flusso di controllo e concentra tutta la logica in un singolo artefatto che viene eseguito durante l'installazione. Gli analisti confermano costantemente il raggruppamento di Webpack, le dimensioni insolite dei file e l'esecuzione in fase di installazione.
Tratti di offuscamento e anti-analisi che vedrai nei campioni:
- Grafico del modulo minimizzato con ID di modulo numerici, commenti sparsi e flusso di controllo appiattito. Inoltre, questa struttura rende estremamente difficile la revisione manuale.
- Stringa nascosta tramite livelli base64 e strumenti di costruzione. Ad esempio, la codifica e la decodifica ripetute in base64 solitamente compaiono attorno alle routine di esfiltrazione.
- Spedizione dinamica attraverso eval-modelli di stile e corpi di funzioni generate, consentendo quindi al codice di modificare il comportamento in fase di esecuzione.
- Filtraggio del sistema operativo preferire l'esecuzione di Linux e macOS, in particolare su runner CI e laptop per sviluppatori.
Dal punto di vista funzionale, il pacchetto è modulare. I documenti descrivono moduli per la scoperta del sistema operativo, scansioni del file system e dei segreti Git, accesso al cloud SDK, operazioni API GitHub e un motore di propagazione che modifica altri pacchetti di proprietà del manutentore. Infatti, sia StepSecurity che ReversingLabs evidenziano una funzione che aggiorna automaticamente i pacchetti con l'hook dannoso.
Esecuzione in fase di installazione in Shai-Hulud: come i pacchetti npm attivano il worm
L'attacco inizia quando postinstall esegue il nodo bundle.js. A questo punto, lo script inizializza e decomprime lo stato di funzionamento nella memoria, preparando il terreno per il funzionamento completo del worm.
Scoperta e raccolta
- Il payload esegue il dump di process.env e analizza i file locali alla ricerca di segreti ad alta entropia e prefissi di token. Inoltre, estende la copertura eseguendo TruffleHog.
- Interroga gli endpoint dei metadati cloud per raccogliere credenziali di breve durata. Per esempio, chiama a
169.254.169.254su AWS ometadata.google.internalsu GCP appaiono spesso negli host infetti. - Di conseguenza, qualsiasi credenziale trovata diventa immediatamente utilizzabile per pubblicare nuovi pacchetti npm o inviare flussi di lavoro GitHub.
exfiltration
- Il worm crea un nuovo repository GitHub denominato Shai Hulud e scrive un doppio codice codificato in base64
data.jsoncon dettagli sulla piattaforma, dump dell'ambiente e segreti. Come si può vedere, questo comportamento "rumoroso" è facile da individuare se i difensori sanno dove guardare. - Inoltre, inserisce un flusso di lavoro di GitHub Actions, spesso su un ramo denominato Shai-hulud, che serializza
${{ toJSON(secrets) }}e pubblica i dati in un webhook statico. Inoltre, questo flusso di lavoro persiste finché qualcuno non lo rimuove attivamente.
Propagazione
- Con qualsiasi token npm scoperto, il payload enumera tutti i pacchetti di proprietà del manutentore compromesso. Quindi, recupera ogni tarball, inietta bundle.js e una voce postinstall e ripubblica il pacchetto.
- Di conseguenza, nel giro di poche ore possono comparire decine di pacchetti infetti, moltiplicando il raggio dell'esplosione nell'ecosistema.
Persistenza ed esposizione
Il worm mantiene attivi i flussi di lavoro dannosi e, in diversi casi, trasforma i repository privati in pubblici con un "-migrazione" suffisso. Nel complesso, questo garantisce all'aggressore di mantenere un punto d'appoggio e massimizza la fuga di dati.
Nota di rilevamento chiave
Questo insolito uso di ${{ toJSON(secrets) }} nei flussi di lavoro di Azioni è raro. Perciò, le squadre dovrebbero considerarlo un indicatore di segnale elevato durante le battute di caccia.
Modello di flusso di lavoro sanificato a cui dovresti dare la caccia
Questo insolito uso di a JSON(segreti) in Actions è un indicatore di segnale elevato in questo incidente.
Pseudo-codice di propagazione di alto livello (sicuro, descrittivo)
async function propagate(token, owner) {
const pkgs = await npmApi.listPackages(owner, token);
for (const p of pkgs) {
const tgz = await npmApi.fetchTarball(p, token);
const modified = injectBundleAndPostinstall(tgz); // adds bundle.js + "postinstall"
await npmApi.publish(modified, token); // publishes new malicious version
}
}Gli analisti hanno osservato questo ciclo su larga scala, il che spiega il rapido salto da decine a centinaia di pacchetti infetti.
Perché questo è un worm in un ecosistema di pacchetti
Un worm è un malware che si diffonde autonomamente, senza richiedere l'intervento manuale dell'operatore in ogni fase. Nei sistemi operativi, i worm di solito sfruttano le vulnerabilità di rete per passare da una macchina all'altra. Al contrario, Shai-Hulud opera all'interno del registro npm. Il suo percorso efficiente passa attraverso riutilizzo delle credenziali.
Il worm sfrutta i token di pubblicazione npm rubati. Non appena ottiene credenziali valide, ripubblica le versioni infette sotto altri pacchetti di proprietà dello stesso maintainer. Successivamente, tali pacchetti vengono installati da sviluppatori o runner di CI ignari e il ciclo si ripete.
Per questo motivo, gli analisti della sicurezza, tra cui Lettura oscura, classificare Shai-Hulud come un verme autoreplicante piuttosto che un semplice trojan o un incidente di typosquatting. La differenza è importante: un trojan in genere compromette un host, ma un worm amplifica automaticamente il suo impatto su un intero ecosistema.
Promemoria "Come funziona"
Per riassumere il ciclo di vita di Shai-Hulud, ecco un controcisla ripartizione dei suoi passaggi principali:
- Un pacchetto con post-installazione è installato e
bundle.jsesegue. - Il payload scarica le variabili di ambiente, esegue la scansione dei file e della cronologia git, viene eseguito TruffleHoge interroga i servizi di metadati cloud. Di conseguenza, qualsiasi segreto trovato diventa immediatamente utile.
- L'esfiltrazione avviene in due modi: in primo luogo, creando un repository pubblico denominato Shai Hulud con una doppia codifica in base64
data.json; in secondo luogo, impiantando un flusso di lavoro di GitHub Actions che pubblica${{ toJSON(secrets) }}a un webhook. - Utilizzando qualsiasi token npm rubato, il worm ripubblica tutti gli altri pacchetti di proprietà del manutentore compromesso con lo stesso hook dannoso. In questo modo, l'infezione si moltiplica rapidamente.
- Infine, l'attaccante detiene più segreti, più pacchetti da diffondere e persistenza all'interno degli account e dei repository GitHub.
Come evitare questa classe di attacchi, praticamente
Shai-Hulud è un campanello d'allarme. Un worm che ruba token e si ripubblica non è un rischio futuro, è vivo nel ecosistema dei pacchetti npm oggi. Per prevenire questo tipo di attacco alla catena di approvvigionamento, i team hanno bisogno di controlli programmabili, automatizzati e applicati direttamente in CI/CD pipelines. Queste sono le stesse difese che puoi già implementare con Xygeni.
Fermare i cattivi artefatti al cancello
Dovresti scansionare i pacchetti npm e i tarball prima che raggiungano gli sviluppatori o i lavori di CI. Sovradimensionati bundle.js file, postinstallazione sospetta hookse i marcatori di offuscamento servono tutti come primi segnali d'allarme. Inoltre, l'applicazione di periodi di raffreddamento e versioni bloccate in pipelineimpedisce che le nuove versioni non verificate vengano utilizzate automaticamente.
indurire CI/CD per impostazione predefinita,
Guardrails in CI/CD Sono essenziali. Rifiutano unioni o installazioni che introducono nuovi script o binari. Allo stesso tempo, bloccano i flussi di lavoro che serializzano segreti o tentano post esterni. I team dovrebbero anche richiedere installazioni basate solo su file di blocco (npm ci) in tutto pipelinein modo che i set di dipendenza rimangano riproducibili e sicuri.
Ridurre il raggio di esplosione del token
I segreti non devono diventare singoli punti di errore. Scansiona continuamente codice, configurazioni e pipeline uscita per credenziali esposteI token dovrebbero avere un ambito di applicazione ristretto, una durata di vita breve e una rotazione automatica quando viene rilevata un'esposizione. Di norma, qualsiasi token utilizzato su un host che ha eseguito una post-installazione sospetta deve essere considerato compromesso.
Osservare il comportamento dei vermi in anticipo
Rilevazione di anomalie È fondamentale. Ad esempio, picchi improvvisi negli eventi di pubblicazione npm, nuovi flussi di lavoro che compaiono senza motivo o nuovi repository pubblici pieni di strani file codificati possono essere tutti segnali di attività di worm. Pertanto, i team dovrebbero segnalare tempestivamente eventuali problemi e isolare eventuali manutentori o runner che mostrano questi segnali di allarme.
Risolvi rapidamente senza interrompere le build
Velocità e sicurezza devono andare di pari passo. Automatizzato pull requests può sostituire i pacchetti npm compromessi con versioni verificate. Inoltre, raggiungibilità e sfruttabilità L'analisi garantisce che gli aggiornamenti rimangano minimi e stabili. Infine, una volta confermata l'esposizione, ricostruire i runner CI interessati da immagini pulite, impedendo all'attacco di diffondersi ulteriormente.
Indicatori di compromesso (IoC)
Quando si analizza Shai-Hulud, le squadre dovrebbero fare attenzione ad entrambi IoC statici nei file e IoC comportamentali in pipelines. Insieme, questi segnali aiutano a rilevare precocemente le infezioni e a reagire prima che il verme si diffonda ulteriormente.
IoC statici
I seguenti digest SHA-256 corrispondono a quanto osservato bundle.js campioni:
- 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
- 81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
- dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c
Inoltre, fai attenzione a questi schemi ricorrenti:
- A
bundle.jsnella radice del pacchetto. "postinstall": "node bundle.js"internopackage.json.- Repository denominati Shai Hulud.
- Flussi di lavoro GitHub contenenti
${{ toJSON(secrets) }}.
IoC comportamentali
Oltre alle firme dei file, l'attività dei worm si rivela attraverso il comportamento. Ad esempio:
- Improvvisi picchi di eventi di pubblicazione npm da parte di un manutentore.
- Nuovi flussi di lavoro che inviano dati a endpoint esterni.
- Richieste POST in uscita attivate dai runner CI.
- Repository pubblici creati di recente con blob codificati.
Caccia veloce
# Find postinstall in package.json
grep -R --line-number '"postinstall"' --include="package.json" /path/to/archives
# Detect tarballs with bundle.js
find /path/to/tarballs -name "*.tgz" -print0 \
| xargs -0 -n1 -I{} sh -c 'tar -tf "{}" | grep bundle.js && echo "== {}"'
# Search workflows for toJSON(secrets)
grep -R --line-number "toJSON(secrets)" --include="*.yml" .github || trueConclusione: lezioni da Shai-Hulud
. Attacco alla catena di approvvigionamento di Shai-Hulud nei pacchetti npm mostra quanto sia diventata fragile l'attuale catena di fornitura del software. Questo worm ha fatto molto di più che aggiungere codice dannoso. Ha rubato token, inviato dati e poi si è ripubblicato automaticamente. Per questo motivo, l'attacco si è diffuso in poche ore anziché in settimane.
Per gli sviluppatori e i team DevOps, la lezione è chiara:
- Ogni installazione esegue del codice. Anche un comune pacchetto npm può nascondere un worm postinstall.
- Ogni token ha un valore elevato. Una volta rubati, possono essere utilizzati per diffondere ulteriormente il malware.
- Ogni pipeline necessita di controlli. Senza guardrails in termini di dipendenze, flussi di lavoro e segreti, un compromesso può rapidamente compromettere la produzione.
Pertanto, fermare attacchi come Shai-Hulud richiede controlli automatici e facili da applicare. I team dovrebbero analizzare i pacchetti npm prima delle installazioni, utilizzare build di lockfile, rilevare attività di pubblicazione sospette e mantenere i token di breve durata. Questi passaggi non sono più facoltativi. Al contrario, rappresentano il fondamento della resilienza nelle moderne applicazioni. pipelines.
In Xygeni, consideriamo l'attacco alla supply chain di Shai-Hulud come un monito per l'intero ecosistema open source. La strada sostenibile da seguire è integrare la sicurezza della supply chain direttamente nel processo di sviluppo, nel punto in cui codice, pacchetti npm e pipelines connettersi.
Di seguito è riportato l'elenco completo dei pacchetti e delle versioni di npm segnalati come compromessi in Shai-Hulud. Utilizzatelo per controllare i vostri file di lock, registri e CI. pipelines per esposizione.
Elenco dei pacchetti compromessi
📦 Anteprima dei pacchetti npm compromessi
| Nome pacchetto | Versione | Data di pubblicazione |
|---|---|---|
| json-rules-engine-semplificato | 0.2.1 | 2025-09-14T17:58:51.203Z |
| pilota di volo | 0.8.8 | 2025-09-14T18:35:07.600Z |
| mcp-knowledge-graph | 1.2.1 | 2025-09-14T18:35:09.494Z |
| capo dell'aviazione | 0.3.1 | 2025-09-14T18:35:09.521Z |
| jumpgate | 0.0.2 | 2025-09-14T18:35:09.651Z |
| tvi-cli | 0.1.5 | 2025-09-14T18:35:10.996Z |
| @thangved/callback-window | 1.1.4 | 2025-09-14T20:31:38.479Z |
| @tnf-dev/api | 1.0.8 | 2025-09-14T20:31:39.547Z |
| @tnf-dev/js | 1.0.8 | 2025-09-14T20:31:41.251Z |
| @tnf-dev/mui | 1.0.8 | 2025-09-14T20:31:41.259Z |
| @tnf-dev/core | 1.0.8 | 2025-09-14T20:31:42.728Z |
| @teselagen/react-table | 6.10.20 | 2025-09-14T20:37:08.597Z |
| @hestjs/demo | 0.1.2 | 2025-09-14T20:45:52.348Z |
| @nexe/eslint-config | 0.1.1 | 2025-09-14T20:45:53.625Z |
| @hestjs/eslint-config | 0.1.2 | 2025-09-14T20:45:55.044Z |
| @nexe/config-manager | 0.1.1 | 2025-09-14T20:45:55.066Z |
| @nexe/logger | 0.1.3 | 2025-09-14T20:45:55.170Z |
| @hestjs/logger | 0.1.6 | 2025-09-14T20:45:55.197Z |
| @hestjs/validazione | 0.1.6 | 2025-09-14T20:45:55.595Z |
| @hestjs/core | 0.2.1 | 2025-09-14T20:45:55.888Z |
➡️ Visualizza l'elenco completo dei pacchetti compromessi
| Nome pacchetto | Versione | Data di pubblicazione |
|---|---|---|
| json-rules-engine-semplificato | 0.2.1 | 2025-09-14T17:58:51.203Z |
| pilota di volo | 0.8.8 | 2025-09-14T18:35:07.600Z |
| mcp-knowledge-graph | 1.2.1 | 2025-09-14T18:35:09.494Z |
| capo dell'aviazione | 0.3.1 | 2025-09-14T18:35:09.521Z |
| jumpgate | 0.0.2 | 2025-09-14T18:35:09.651Z |
| tvi-cli | 0.1.5 | 2025-09-14T18:35:10.996Z |
| @thangved/callback-window | 1.1.4 | 2025-09-14T20:31:38.479Z |
| @tnf-dev/api | 1.0.8 | 2025-09-14T20:31:39.547Z |
| @tnf-dev/js | 1.0.8 | 2025-09-14T20:31:41.251Z |
| @tnf-dev/mui | 1.0.8 | 2025-09-14T20:31:41.259Z |
| @tnf-dev/core | 1.0.8 | 2025-09-14T20:31:42.728Z |
| @teselagen/react-table | 6.10.20 | 2025-09-14T20:37:08.597Z |
| @hestjs/demo | 0.1.2 | 2025-09-14T20:45:52.348Z |
| @nexe/eslint-config | 0.1.1 | 2025-09-14T20:45:53.625Z |
| @hestjs/eslint-config | 0.1.2 | 2025-09-14T20:45:55.044Z |
| @nexe/config-manager | 0.1.1 | 2025-09-14T20:45:55.066Z |
| @nexe/logger | 0.1.3 | 2025-09-14T20:45:55.170Z |
| @hestjs/logger | 0.1.6 | 2025-09-14T20:45:55.197Z |
| @hestjs/validazione | 0.1.6 | 2025-09-14T20:45:55.595Z |
| @hestjs/core | 0.2.1 | 2025-09-14T20:45:55.888Z |
| @hestjs/cqrs | 0.1.6 | 2025-09-14T20:45:55.966Z |
| @hestjs/scalar | 0.1.7 | 2025-09-14T20:45:56.386Z |
| caricamento file ng2 | 7.0.3 | 2025-09-15T02:44:29.555Z |
| gestore-notifiche-condensatore | 0.0.2 | 2025-09-15T04:54:48.431Z |
| condensatore-plugin-vonage | 1.0.2 | 2025-09-15T04:54:48.501Z |
| condensatore-plugin-healthapp | 0.0.2 | 2025-09-15T04:54:48.704Z |
| capacitorandroidpermissions | 0.0.4 | 2025-09-15T04:54:48.753Z |
| kit di chiamata voip | 1.0.2 | 2025-09-15T04:54:49.223Z |
| condensatore-plugin-ihealth | 1.1.8 | 2025-09-15T04:55:08.113Z |
| @art-ws/common | 2.0.22 | 2025-09-15T05:21:15.411Z |
| @art-ws/config-eslint | 2.0.4 | 2025-09-15T05:21:17.199Z |
| ngx-ws | 1.1.5 | 2025-09-15T05:21:17.514Z |
| @art-ws/slf | 2.0.15 | 2025-09-15T05:21:17.524Z |
| @art-ws/http-server | 2.0.21 | 2025-09-15T05:21:17.745Z |
| pm2-gelf-json | 1.0.4 | 2025-09-15T05:21:18.413Z |
| @art-ws/di | 2.0.28 | 2025-09-15T05:21:18.488Z |
| @art-ws/di-node | 2.0.13 | 2025-09-15T05:21:18.849Z |
| @art-ws/config-ts | 2.0.7 | 2025-09-15T05:21:19.408Z |
| @art-ws/db-context | 2.0.21 | 2025-09-15T05:21:19.814Z |
| @art-ws/openapi | 0.1.9 | 2025-09-15T05:21:19.969Z |
| @art-ws/web-app | 1.0.3 | 2025-09-15T05:21:20.383Z |
| @art-ws/ssl-info | 1.0.9 | 2025-09-15T05:21:20.927Z |
