Catena di fiducia spezzata: come tag, pacchetti e CI si combinano per aumentare il rischio

Novanta minuti di buio: un’azione non pinnata ha letto GITHUB_TOKEN e ha fatto push su un branch ignorato dai più. La coda CI di un altro team ha toccato 1.100 job in sei ore per un loop di force-push notturno. Due sviste diverse, stesso esito: credenziali esposte e infrastruttura impegnata a vuoto. La tesi: la catena di fiducia del software si spezza in più punti indipendenti, e le rotture si sommano. Un tag mobile nel CI, una wheel manomessa su PyPI, una RCE in una piattaforma, un fraintendimento sui container. Presi insieme, alzano il rischio reale di esfiltrazione, esecuzione remota e pivot laterale^1,4,5,2.

Punto di partenza: il CI come vettore di fiducia

L’incidente del tag mobile nasce da un’azione non fissata a uno SHA. some-org/setup-toolchain@v1 ha cambiato contenuto. La nuova versione ha eseguito uno script post-install, ha letto il token predefinito e ha pushato codice remoto. Un reviewer ha notato un nome di step diverso e ha fermato tutto dopo 90 minuti. Non tutti hanno quel margine di controllo¹.

Il secondo episodio è una tempesta di concorrenza. Ogni push su un branch di pull request avviava una matrice completa. Nessuna run veniva cancellata. Un contributore ha scatenato un loop di force-push notturno. La coda è salita a 1.100 job. Settimane di minuti Linux bruciati in sei ore, con build verdi. Nessun test rosso a segnalare il danno¹.

Questi guasti non emergono nei workflow di esempio. Esplodono quando il CI tocca sistemi reali e tool terzi. Nel caso citato, l’integrazione di citrolabs/ego-lite, un toolkit che consegna sessioni di browser già loggate, ha ampliato la superficie di interazione esterna del pipeline¹.

La lezione è secca: il CI custodisce token, avvia azioni con side effect e scala in parallelo. Un singolo errore di fissaggio o di politica di cancellazione può trasformare una routine in un incidente di sicurezza e di costo¹.

Registri di pacchetti e build supply: la superficie di attacco delle wheel

Il 21 ottobre 2026 è apparsa su PyPI la release malevola litellm==1.107.0. PyPI l’ha rimossa. La 1.106.2 è indicata come sicura⁴. L’impatto potenziale è alto perché LiteLLM spesso finisce sulle macchine degli sviluppatori senza installazione diretta. Molti agent e proxy lo usano per parlare con Claude, GPT e altri modelli tramite un’unica interfaccia⁴.

Il payload cercava credenziali di strumenti usati per il coding con l’AI. Nelle stringhe compaiono nomi come Claude, Cursor, Copilot, Gemini CLI e Codex CLI. È la seconda compromissione del 2026, non collegata all’incidente di marzo secondo le informazioni disponibili⁴.

Il dettaglio che conta per la difesa: il tag v1.107.0 su GitHub era pulito. I file malevoli comparivano solo nelle wheel caricate su PyPI. Leggere il sorgente non avrebbe aiutato a individuare la modifica. La ricostruzione temporale citata nel post si appoggia all’analisi, in giapponese, di GMO Flatt Security⁴.

La combinazione è pericolosa: un pacchetto apparentemente legittimo a livello di repository può portare codice diverso quando lo si installa dal registro. Se gira su un runner CI con token disponibili, può esfiltrarli. Se gira su una macchina di sviluppo con tool AI attivi, può raccoglierne le chiavi⁴.

Piattaforme core e difetti storici: RCE e backport estesi

GitLab ha corretto una vulnerabilità critica, CVE-2026-110264. In certe condizioni consente a un utente non autenticato di eseguire codice arbitrario su server self-managed. La causa è un overflow di intero nella compilazione delle espressioni regolari. Una regex costruita ad arte può innescare l’overflow e aprire alla RCE. Il difetto riguarda GitLab Community Edition e Enterprise Edition⁵.

L’impatto storico è ampio: le versioni coinvolte risalgono fino a GitLab 7.0, giugno 2014. GitLab ha pubblicato fix in 19.5.1, 19.4.3 e 19.3.6. Ha backportato la patch su 19.2.9, 19.1.9, 19.0.10 e 18.11.13. Raccomanda di aggiornare il prima possibile. GitLab.com e GitLab Dedicated risultano già patchati. Per le istanze self-managed, l’azienda ha pubblicato due rilevazioni di minaccia dedicate⁵.

Una RCE su una piattaforma di gestione del codice cambia il profilo di rischio. Un token acquisito via CI o un pacchetto malevolo possono diventare il primo passo. La falla di piattaforma può offrire persistenza o esecuzione remota oltre il perimetro del pipeline⁵.

La pressione offensiva aumenta anche altrove. VulnCheck afferma di avere un exploit che aggira l’ASLR su server x86-64 e rende praticabile l’attacco legato a PHP2Shell, mirato alla falla CVE-2026-109618 con esecuzione remota di codice. L’exploit non è pubblico. L’azienda lo fornisce ai soli clienti del servizio Initial Access Intelligence. Secondo VulnCheck, gruppi ostili usano strumenti di intelligenza artificiale per cercare nuove vie di attacco sulle stesse falle³.

L’illusione dell’isolamento container: perché non basta confinare

Un esperimento pubblicato il 22 ottobre 2026 su codeandcake.dev ribadisce un punto pratico: i container non sono macchine virtuali. Sono processi del kernel con restrizioni applicate. Se sai dove guardare, li trovi in /proc. Le immagini sono solo cartelle che diventano la loro root².

Non esiste una singola feature di Linux chiamata “container”. L’isolamento nasce dalla combinazione di meccanismi diversi. L’autore cita i namespaces, che separano ciò che vedono host e container, e i cgroups, che limitano le risorse. Per la rete parla di “un sacco di magia” che non capisce, ma che isola la connettività. Sullo storage, nota che Docker mette i file da qualche parte sul filesystem e poi chiama chroot, o pivot_root².

Implica una cosa concreta per chi difende: se il processo containerizzato ottiene accesso inatteso a risorse dell’host, il confine si assottiglia. La pratica operativa deve riflettere la natura reale dell’isolamento, non l’analogia con le VM².

Come questi guasti si concatenano: scenari pratici e punti deboli

I casi recenti disegnano una traiettoria precisa.

• Un tag mobile in CI può eseguire codice imprevisto e leggere GITHUB_TOKEN. Se una dipendenza nel job arriva da una wheel malevola, il codice nel pacchetto può esfiltrare credenziali del runner e di strumenti AI presenti sulla macchina. Il CI può anche pushare a remoto in automatico, come già visto. Il danno cresce prima che qualcuno noti un nome di step diverso o un’anomalia di log^1,4.

• Una coda non gestita può mascherare attività malevole dietro centinaia di job legittimi. Matrici ampie, nessuna cancellazione automatica, loop di push, e il budget dei runner evapora. In quel rumore, una release compromessa o un tentativo di pivot hanno più tempo per agire senza un test rosso a bloccarli¹.

• Se l’infrastruttura di gestione del codice resta indietro sulle patch, una RCE nota può offrire l’ultima leva. Un accesso iniziale, conquistato via pacchetto o CI, può diventare esecuzione remota su un’istanza self-managed. La storicità della falla di GitLab, fino alla 7.0, amplia il bacino potenziale se molti server non aggiornano subito⁵.

• La fiducia eccessiva nell’isolamento dei container può completare la catena. Un processo che ottiene accesso inatteso all’host può uscire dal perimetro previsto. Le immagini sono cartelle, non macchine. La difesa deve controllare configurazioni e privilegi con lo stesso rigore applicato al codice².

Questa è la tendenza comune: vulnerabilità tecniche e pratiche deboli si incontrano sui confini tra sistemi, non al loro interno. I registri distribuiscono artefatti che non combaciano con il sorgente. I pipeline eseguono codice terzo con token a portata. Le piattaforme core patchano falle con ampia estensione temporale. I container danno un’illusione di separazione più netta di quella reale^1,4,5,2,3.

L’altra faccia è l’offensiva che accelera. VulnCheck dice di aver superato l’ASLR su x86-64 nel contesto di PHP2Shell e segnala l’uso di strumenti di intelligenza artificiale per la ricerca di nuove vie d’attacco. I difensori devono aspettarsi che lo stesso approccio venga applicato anche ai bordi della supply chain, non solo ai singoli bug³.

Chi costruisce pipeline e piattaforme oggi si gioca la resilienza nei dettagli d’assemblaggio: finché un tag resta mobile, una wheel può differire dal tag e un container resta un processo del kernel, l’aggiornamento tempestivo e il fissaggio puntuale di ogni anello faranno la differenza tra incidente circoscritto e compromissione di filiera.