Un titolo GitHub ha compromesso 4.000 PC degli sviluppatori: come è successo

Anche il semplice titolo di una segnalazione di problema (issue) su GitHub, la piattaforma usata dagli sviluppatori per collaborare e gestire il codice, può diventare un vero e proprio vettore d’attacco: se sfruttato in modo malevolo, può essere utilizzato per eseguire codice o manipolare strumenti automatici collegati al repository, arrivando potenzialmente a compromettere migliaia di ambienti di sviluppo. È quanto emerso in un incidente che ha coinvolto l’assistente di programmazione Cline, uno strumento utilizzato da sviluppatori per interagire con repository e automatizzare attività di coding.

L’episodio evidenzia un nuovo schema di attacco: un agente AI compromesso che installa silenziosamente un secondo agente AI sui sistemi degli sviluppatori. La vicenda ha riguardato circa 4.000 macchine e si inserisce in un contesto più ampio, in cui automazione, CI/CD (Continuous Integration/Continuous Delivery/Deployment) e agenti LLM stanno ampliando la superficie d’attacco delle piattaforme di sviluppo.

Il caso è emerso all’inizio del 2026, quando il ricercatore di sicurezza Adnan Khan ha individuato una catena di vulnerabilità che combinava automazioni GitHub, gestione delle credenziali e comportamenti tipici dei sistemi basati su modelli linguistici. Quando un tool AI opera con privilegi elevati all’interno di workflow automatizzati, può diventare un intermediario per l’esecuzione di codice non previsto. L’attacco è stato soprannominato “Clinejection”, una combinazione tra prompt injection e compromissione della supply chain.

La catena di compromissione che parte da una GitHub Issue

Il punto di ingresso dell’attacco si trovava in un workflow di automazione utilizzato per la gestione delle issue nel repository del progetto. L’automazione impiegava un agente basato su modelli linguistici per classificare e gestire automaticamente i ticket.

Il titolo delle issue veniva passato direttamente nel prompt del modello attraverso variabili dell’evento GitHub, senza un meccanismo di sanitizzazione dell’input.

Un utente esterno poteva quindi aprire una issue contenente istruzioni appositamente costruite per influenzare il comportamento dell’agente. Il workflow risultava attivabile da chiunque, poiché l’azione GitHub era configurata con parametri permissivi che consentivano l’esecuzione anche da account esterni.

L’agente AI, autorizzato a utilizzare strumenti come Bash, lettura e scrittura di file o operazioni di ricerca, interpretava il contenuto della issue come parte del prompt operativo e poteva eseguire azioni non previste.

Quando un agente AI installa un altro agente

L’elemento più insolito dell’attacco riguarda il payload. Il pacchetto compromesso installava automaticamente un secondo agente AI ovvero il tanto discusso OpenClaw. In pratica lo sviluppatore autorizzava implicitamente il primo strumento, ma finiva per eseguire un software completamente diverso, dotato di capacità autonome.

Una volta installato, OpenClaw poteva accedere alla directory di configurazione locale, leggere credenziali memorizzate e interagire con il sistema attraverso la sua interfaccia di controllo. L’agente esponeva infatti un’API denominata Gateway API, progettata per consentire l’esecuzione di comandi shell e altre operazioni di automazione.

Il software poteva inoltre installarsi come servizio persistente tramite un system daemon, sopravvivendo ai riavvii del sistema operativo.

Il problema della delega implicita nelle automazioni AI

Quanto accaduto mette in evidenza una dinamica cruciale: lo sviluppatore concede fiducia a uno strumento specifico, ma l’attacco sfrutta tale fiducia per delegare privilegi a un software completamente diverso. In altre parole, l’utente non autorizza direttamente il secondo agente, ma la compromissione del primo consente comunque l’esecuzione del nuovo componente.

La presenza di agenti autonomi amplifica l’impatto potenziale. I LLM integrati negli strumenti di sviluppo possono eseguire operazioni complesse attraverso interfacce di tooling, come accesso al file system, interrogazioni Web o esecuzione di script.

Quando queste capacità sono combinate con sistemi CI/CD e repository pubblici, la separazione tra input non attendibile e logica applicativa diventa estremamente fragile.

Perché i controlli di sicurezza non hanno intercettato l’attacco

Gran parte delle difese tradizionali della supply chain software si basa sull’identificazione di codice malevolo o dipendenze sospette. In questo caso il pacchetto installato risultava legittimo e disponibile pubblicamente. L’azione malevola non era contenuta nel codice stesso ma nel contesto di installazione.

Gli strumenti di revisione automatica non hanno rilevato anomalie perché la differenza tra versioni del software era minima. Anche i meccanismi di attestazione della provenienza dei pacchetti non erano attivi nel progetto al momento dell’incidente.

Il caso dimostra come l’integrazione tra agenti AI, repository pubblici e sistemi di distribuzione software possa generare nuove classi di attacco. L’automazione offre vantaggi operativi evidenti, ma senza una rigorosa separazione dei privilegi e controlli di provenienza verificabili rischia di trasformarsi in un moltiplicatore di vulnerabilità lungo l’intera supply chain dello sviluppo software.