Pacchetti sleeper multi-ecosistema svuotano le pipeline CI

Almeno due campagne hanno piazzato pacchetti malevoli su RubyGems, npm e Go per rubare credenziali, alterare GitHub Actions e persistere nelle CI.

Contenuto

Pacchetti sleeper multi-ecosistema svuotano le pipeline CI
Pacchetti sleeper multi-ecosistema svuotano le pipeline CI

Nel giro di meno di una settimana, a partire dal 29 aprile 2026, almeno due campagne distinte hanno distribuito pacchetti sleeper malevoli su RubyGems, npm, Go modules e altri registri open source per sottrarre credenziali di sviluppatori, alterare workflow GitHub Actions e garantire persistenza nelle pipeline di continuous integration. I CI runner, spesso effimeri e meno sorvegliati dei endpoint aziendali, si trasformano così in bancomat per threat actor e in vettori di compromissione a valle. La novità tattica non è solo il furto di secret, ma il targeting delle configurazioni degli agenti di coding AI e l’uso di wrapper intercettori che influenzano le build senza romperle.

Punti chiave
  • L’account GitHub BufferZoneCorp ha pubblicato gemme Ruby e moduli Go malevoli poi rimossi dai rispettivi registri; i pacchetti rubano credenziali locali e modificano il PATH delle GitHub Actions per installare un wrapper falso.
  • La campagna Mini Shai-Hulud ha piazzato almeno quattro pacchetti SAP npm — mbt, @cap-js/db-service, @cap-js/postgres e @cap-js/sqlite — usando script pre-install per sottrarre token e secret cloud.
  • Il modulo Go di BufferZoneCorp sfrutta la funzione init() per rilevare GITHUB_ENV e GITHUB_PATH, impostare proxy HTTP e HTTPS e scrivere un binario go contraffatto nella cache del runner.
  • Secondo StepSecurity, questa ondata è tra le prime a puntare direttamente sulle configurazioni degli agenti di coding AI come vettore di persistenza e propagazione all’interno delle repository.

Il meccanismo del wrapper Go: quando il binario di build diventa una spia

I moduli Go distribuiti dall’account BufferZoneCorp non si limitano a eseguire codice al momento dell’installazione. Secondo l’analisi di Kirill Boychenko, ricercatore di Socket, il pacchetto attiva un meccanismo di intercettazione che altera l’ambiente del CI runner in modo persistente. Attraverso la funzione init(), il codice rileva la presenza delle variabili d’ambiente GITHUB_ENV e GITHUB_PATH, segnalando che sta girando all’interno di una pipeline GitHub Actions. A quel punto imposta HTTP_PROXY e HTTPS_PROXY e scrive un eseguibile go contraffatto in una directory di cache, dandole priorità nel PATH del workflow.

"The module executes through init(), detects GITHUB_ENV and GITHUB_PATH, sets HTTP_PROXY and HTTPS_PROXY, writes a fake go executable into a cache directory, and appends that directory to the workflow path so the wrapper is selected before the real binary," — Kirill Boychenko, Socket

Le esecuzioni successive del compilatore vengono così dirottate verso il wrapper malevolo, che può influenzare le build senza farle fallire. Nello stesso contesto, il pacchetto aggiunge una chiave SSH hardcoded nel file ~/.ssh/authorized_keys, aprendo un canale di accesso remoto anche dopo la fine del job. L’effetto è una persistenza silenziosa in un ambiente che, per sua natura, dovrebbe sparire nel giro di minuti.

RubyGems e l’esfiltrazione silenziosa verso endpoint controllati

In parallelo ai moduli Go, l’account BufferZoneCorp ha pubblicato gemme Ruby che impersonano librerie legittime. Durante l’installazione, questi pacchetti avviano una raccolta aggressiva di credenziali: variabili d’ambiente, chiavi SSH, segreti AWS, file .npmrc, .netrc, configurazioni della GitHub CLI e credenziali RubyGems stesse. I dati raccolti vengono poi esfiltrati verso un endpoint Webhook.site controllato dall’attaccante.

I pacchetti sono stati successivamente rimossi da RubyGems e bloccati sul registro Go, ma chi li ha installati nel lasso di tempo compreso tra la pubblicazione e la rimozione potrebbe aver già esposto secret critici. L’operazione dimostra come la semplice esecuzione di bundle install o go get in un CI runner possa trasformarsi in un punto di raccolta sistematica di token.

Mini Shai-Hulud e l’offensiva su npm: i pacchetti SAP compromessi

La seconda campagna, identificata come Mini Shai-Hulud, ha colpito almeno quattro pacchetti SAP pubblicati su npm in data 29 aprile 2026: mbt, @cap-js/db-service, @cap-js/postgres e @cap-js/sqlite. Ogni pacchetto conteneva uno script pre-install progettato per rubare credenziali di sviluppatori, token GitHub e npm, secret GitHub Actions e segreti cloud relativi ad AWS, Azure, GCP e Kubernetes.

Secondo l’analisi condotta da StepSecurity e Wiz, il payload impiega cifratura AES-256-CGM per l’esfiltrazione ed è in grado di effettuare self-commit su ogni repository GitHub accessibile, diffondendo la compromissione alla fonte. I pacchetti sono stati deprecati da npm, ma il rischio persiste per i team che non abbiano ancora verificato le proprie cache locali e i lockfile. StepSecurity ha sottolineato che "this is one of the first supply chain attacks to target AI coding agent configurations as a persistence and propagation vector", evidenziando un’escalation tattica che allarga la superficie d’attacco dalle macchine degli sviluppatori agli strumenti di automazione intelligente. La campagna ha colpito anche altri registri, tra cui PyPI, PHP Packagist, RubyGems e Go modules, oltre a librerie come PyTorch Lightning e il client Intercom su npm, come segnalato da Developer Tech.

Perché le pipeline CI sono il bancomat dei threat actor

Le pipeline di continuous integration rappresentano un bersaglio privilegiato perché combinano tre fattori di rischio: accesso privilegiato ai secret di build, durata effimera che riduce la soglia di allarme, e complessità poliglotta che rende difficile auditare ogni dipendenza. A differenza di un laptop aziendale, un CI runner viene spesso istanziato, esegue il suo compito e viene distrutto in meno di un’ora; se durante quel lasso di tempo un pacchetto installa un proxy, una chiave SSH o un wrapper sul compilatore, il payload può agire indisturbato.

La campagna BufferZoneCorp e la campagna Mini Shai-Hulud sfruttano entrambe questa finestra temporale, sebbene non sia confermato che siano orchestrazioni collegate. In entrambi i casi, il danno non si ferma al furto di credenziali: un CI runner compromesso può iniettare backdoor nei software distribuiti a valle, propagando l’attacco fino agli utenti finali senza che nessun endpoint tradizionale suoni un allarme.

Cosa fare adesso

Per contenere il rischio e ripristinare la fiducia nelle catene di build, i team DevOps e i CISO devono agire su più fronti. Ecco quattro priorità:

  1. Audit dei log d’installazione. Verificare nei log dei CI runner eseguiti tra il 29 aprile e il 6 maggio 2026 la presenza dei nomi dei pacchetti indicati nelle analisi, inclusi mbt, i pacchetti @cap-js, le gemme BufferZoneCorp e i moduli Go associati all’account omonimo.
  2. Isolamento dei secret. Limitare l’esposizione di token GitHub, chiavi cloud e credenziali npm durante le fasi di risoluzione delle dipendenze; usare environment protetti e ruoli a breve scadenza in modo che un pacchetto malevolo non possa accedere a secret globali.
  3. Pin e verifica d’integrità. Bloccare le versioni delle dipendenze nei lockfile e confrontare gli hash dei pacchetti Go, Ruby e npm con quelli ufficiali; prestare attenzione alle directory di cache e al PATH dei runner self-hosted, dove i wrapper possono nascondersi.
  4. Controllo delle configurazioni AI. Auditare le impostazioni degli agenti di coding AI e delle GitHub Actions alla ricerca di proxy HTTP/HTTPS anomali, chiavi SSH non autorizzate in ~/.ssh/authorized_keys e modifiche sospette ai workflow.

La convergenza di queste due campagne sullo stesso obiettivo — le pipeline di build — segnala un passaggio tattico che non riguarda più solo la reputazione dei registri open source, ma la sicurezza dell’intera catena di rilascio del software. Finché i CI runner saranno considerati ambienti transitori e non endpoint critici, il margine di manovra per gli attaccanti resta ampio e misurato in minuti, non in ore.

Domande frequenti

BufferZoneCorp e Mini Shai-Hulud sono la stessa operazione?

Non è confermato. Le fonti tecniche le trattano come campagne distinte, con tecniche sovrapposte ma senza evidenza di coordinamento o infrastruttura condivisa.

Perché un modulo Go può alterare GitHub Actions senza essere rilevato?

Sfrutta la funzione init() e le variabili d’ambiente GITHUB_ENV/GITHUB_PATH per modificare il PATH del workflow e intercettare le chiamate al compilatore, operando interamente in memoria e in file temporanei.

I pacchetti compromessi sono ancora installabili?

Quelli associati a BufferZoneCorp sono stati yanked da RubyGems e bloccati su Go; i pacchetti SAP npm sono stati deprecati. Chi li ha già scaricati o conservati in cache, tuttavia, rischia di eseguirli se non ripulisce gli ambienti.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews