Alpine Linux sotto attacco: GitHub rafforza la supply chain npm

🛡️ Executive Summary

• Alpine Linux conferma tentativi di sfruttamento della CVE-2026-97229 su GitLab, ma non trova prove di compromissione riuscita.
• L’aggiornamento a GitLab 19.3.6 non aveva corretto la vulnerabilità nella build Alpine, che utilizzava una versione di Ruby ancora esposta.
• GitHub introduce un package firewall per npm, con controlli preventivi sulle dipendenze installate da sviluppatori, agenti AI e pipeline CI/CD.

Alpine Linux ha ricostruito completamente la propria infrastruttura GitLab dopo un tentativo di sfruttamento della vulnerabilità critica CVE-2026-97229, classificata con un punteggio CVSS di 10.0, mentre GitHub ha introdotto un nuovo firewall per impedire l’installazione di pacchetti npm considerati rischiosi. I due sviluppi, indipendenti tra loro, mostrano problemi complementari nella sicurezza della supply chain open source: da una parte un componente software vulnerabile può esporre l’infrastruttura che produce e distribuisce pacchetti, dall’altra le dipendenze scaricate automaticamente possono trasformarsi in vettori di compromissione. Il caso Alpine presenta inoltre un elemento particolarmente delicato: un aggiornamento apparentemente corretto di GitLab non aveva eliminato la vulnerabilità, perché la patch dipendeva dalla versione di Ruby utilizzata nell’immagine container.

Alpine Linux sotto attacco: otto crash di GitLab e un exploit quasi riuscito

Il resoconto ufficiale pubblicato da Alpine Linux il 28 ottobre ricostruisce una sequenza di attività malevole avvenute tra il 20 e il 21 ottobre 2026, quando un attaccante ha tentato di sfruttare CVE-2026-97229 contro l’istanza GitLab del progetto. L’operazione sarebbe partita dalla registrazione di un nuovo account, successivamente utilizzato per inviare configurazioni CI opportunamente costruite e attivare la vulnerabilità nel motore delle espressioni regolari. I tentativi hanno provocato otto arresti anomali dei processi worker di GitLab, quattro dei quali mostrano, secondo gli sviluppatori, che l’attaccante era riuscito a superare alcune fasi della catena di exploit, fallendo però in un passaggio successivo. L’operatore ha inoltre scaricato l’immagine container utilizzata dal progetto, elemento che suggerisce un’attività di adattamento dell’attacco alla configurazione effettivamente in esecuzione. Alpine non ha trovato prove di esecuzione di codice sul server, ma non può escludere completamente che l’exploit sia riuscito: una compromissione senza crash avrebbe potuto lasciare poche tracce, mentre alcuni log non erano più disponibili. Il rischio era già noto dopo la pubblicazione delle correzioni GitLab per CVE-2026-97229, ma il nuovo incidente documenta il passaggio dalla vulnerabilità teorica a tentativi concreti contro un’infrastruttura open source.

Leggi anche: GitHub e PyPI introducono difese temporali contro la supply chain

GitLab aggiornato ma ancora vulnerabile: il problema nascosto in Ruby

La parte tecnicamente più significativa dell’incidente riguarda la gestione degli aggiornamenti. GitLab aveva distribuito la correzione il 12 ottobre, ma Alpine aveva inizialmente installato la versione 19.3.4, anziché la 19.3.5 che conteneva la patch prevista. Il successivo passaggio a GitLab 19.3.6, effettuato il 22 ottobre, avrebbe dovuto risolvere il problema, ma un controllo del 26 ottobre ha dimostrato che l’istanza era ancora vulnerabile. La spiegazione risiede nell’architettura del software: il difetto coinvolge Onigmo, il motore delle espressioni regolari integrato in Ruby, e GitLab aveva applicato la correzione alla versione di Ruby distribuita nei propri pacchetti ufficiali. L’immagine utilizzata da Alpine impiegava invece una versione standard di Ruby, non necessariamente aggiornata insieme al codice applicativo. La vulnerabilità rimaneva quindi sfruttabile nonostante l’installazione di una release GitLab più recente. Le versioni corrette del runtime sono Ruby 3.3.13, 3.4.12 e 4.0.9, rilasciate upstream il 23 ottobre. Gli amministratori che compilano GitLab dai sorgenti o utilizzano container personalizzati devono pertanto verificare separatamente il runtime e non limitarsi al numero di versione dell’applicazione. Per le immagini Alpine, il progetto indica di scaricare nuovamente alpinelinux/gitlab:19.3.6: quella pubblicata il 27 ottobre incorpora Ruby 3.3.13, mentre le immagini precedenti con lo stesso tag rimanevano vulnerabili.

GitHub introduce il package firewall: controlli prima di installare npm

La risposta di GitHub a una diversa superficie della supply chain arriva attraverso il package firewall annunciato ufficialmente il 20 ottobre, disponibile in public preview per i clienti GitHub Enterprise Cloud, comprese le configurazioni con residenza dei dati. Il sistema opera come intermediario fra sviluppatori, registri interni, agenti di programmazione e repository pubblici dei pacchetti, sottoponendo le richieste a controlli di sicurezza prima che una dipendenza venga installata. La valutazione riguarda sia i metadati sia il download dei pacchetti e utilizza criteri configurabili dagli amministratori, tra cui un periodo di attesa per le nuove release, le segnalazioni presenti nel GitHub Advisory Database e i controlli sulle attestazioni della supply chain. Un pacchetto appena pubblicato può quindi essere temporaneamente bloccato prima di raggiungere una workstation o una pipeline automatizzata, lasciando maggiore tempo ai sistemi di analisi per individuare eventuali compromissioni.

Il meccanismo è particolarmente rilevante per gli agenti AI e i runner CI/CD, che installano dipendenze senza la verifica continua di un operatore umano. Quando un blocco risulta ingiustificato, GitHub prevede una procedura per richiedere un’eccezione. Nella fase iniziale il firewall supporta esclusivamente npm, è gratuito durante la preview e passerà a un modello di fatturazione basato sull’utilizzo una volta raggiunta la disponibilità generale. Non si tratta quindi di una protezione universalmente attiva per qualsiasi repository GitHub.

Dal controllo delle pubblicazioni npm alla protezione delle installazioni automatiche

Il firewall rappresenta un’evoluzione rispetto alle misure con cui GitHub ha progressivamente rafforzato l’ecosistema npm, comprese le restrizioni su trusted publishing, credenziali e workflow automatizzati. Le precedenti difese intervengono soprattutto sulla capacità di pubblicare nuove versioni: autenticazione, identità del maintainer, autorizzazione dei workflow e gestione dei token. Il nuovo servizio aggiunge invece un controllo al momento dell’installazione, quando il pacchetto è già disponibile nel registry ma non ha ancora raggiunto l’ambiente di esecuzione. Questa distinzione è decisiva perché una release malevola può essere distribuita attraverso credenziali legittime compromesse, oppure contenere codice dannoso non identificato durante la pubblicazione. Anche le attestazioni e il periodo di attesa non garantiscono che una dipendenza sia sicura, ma consentono di applicare una politica centrale e di ridurre la probabilità che una versione sospetta venga installata automaticamente. Il caso Alpine mostra tuttavia un limite differente: un package firewall npm non avrebbe corretto la vulnerabilità GitLab né sostituito l’aggiornamento di Ruby. Le due misure proteggono momenti diversi del ciclo software, rispettivamente l’acquisizione delle dipendenze e l’integrità dell’infrastruttura che gestisce sviluppo e distribuzione.

Continua con:

npm sotto attacco: TensorLake infetta gli agenti AI, MALFEX supera 40.000 download

Alpine ricostruisce GitLab: quali rischi restano per aziende e sviluppatori

Alpine Linux ha scelto di trattare l’istanza come potenzialmente compromessa e di ricostruirla da zero, completando l’operazione il 28 ottobre con il reset delle password e la sostituzione delle chiavi segrete di GitLab. Il progetto dichiara che non sono state trovate alterazioni nei pacchetti, nel repository aports e nelle release stabili del 21 ottobre, controllate confrontando commit e risultati delle build con registrazioni esterne all’istanza coinvolta. Le chiavi utilizzate per firmare pacchetti e distribuzioni non erano conservate sul server GitLab e non risultano esposte. La verifica iniziale ha coperto i commit dal 20 al 22 ottobre e i pacchetti prodotti fino al 24 ottobre; Alpine ha precisato di voler estendere i controlli fino alla chiusura dell’istanza, avvenuta il 27 ottobre. Non risultano inoltre prove di accesso ai dati privati degli utenti, sebbene l’assenza di alcune registrazioni impedisca di escludere categoricamente ogni compromissione. Gli amministratori che utilizzano le immagini GitLab mantenute da Alpine devono verificare la versione effettiva di Ruby e recuperare l’immagine corretta; agli utenti del servizio GitLab viene richiesto di impostare una nuova password quando tornerà disponibile e di modificarla anche su altri servizi, qualora fosse stata riutilizzata.

Per le organizzazioni italiane che gestiscono ambienti Linux, container, pipeline CI/CD e agenti AI, la vicenda evidenzia due priorità operative complementari: verificare che gli aggiornamenti correggano realmente tutte le dipendenze del software e applicare controlli sulle installazioni automatizzate. Una release aggiornata non garantisce da sola un runtime sicuro, così come un pacchetto distribuito da un registry legittimo non può essere considerato automaticamente affidabile. Il problema non riguarda una compromissione generalizzata di Alpine Linux né dimostra un collegamento fra l’attaccante di GitLab e le campagne malware npm. Riguarda invece la necessità di proteggere ogni passaggio della catena di produzione software, dalle librerie utilizzate dai server fino alle dipendenze introdotte negli ambienti di sviluppo.