L’attacco supply chain che ha colpito Cline CLI 2.3.0 è uno di quei casi che sembrano “piccoli” solo se si guarda il payload, ma che in realtà mettono a nudo una frattura strutturale: quando un AI agent entra nei workflow di sviluppo con permessi eccessivi, il confine tra “automazione” e “superficie d’attacco” si dissolve. In questa campagna, l’installazione non autorizzata di OpenClaw tramite uno script postinstall non nasce da una compromissione classica di infrastruttura, ma da una combinazione moderna di tecniche: prompt injection su issue GitHub e cache poisoning su GitHub Actions, con un pivot finale sul furto del token di pubblicazione npm. Il dato operativo che conta è semplice: il 17 febbraio 2026 alle 3:26 AM PT, gli attaccanti pubblicano Cline CLI 2.3.0 sul registry npm. La versione resta disponibile per circa otto ore, fino alle 11:30 AM PT, e in quella finestra registra circa 4.000 download. Dentro il package.json, lo script malevolo non aggiunge un trojan “classico”, ma forza un’installazione globale di openclaw@latest. OpenClaw, in sé, viene descritto come un agente AI autonomo self-hosted e non mostra comportamenti intrinsecamente maligni nel contesto osservato. Il punto però non è la natura di OpenClaw: è il fatto che viene installato senza consenso dell’utente, e che questo comportamento dimostra una capacità di manipolare la catena di pubblicazione e quindi, potenzialmente, di distribuire altro.
Dal commit vulnerabile alla pubblicazione: la timeline che spiega tutto
La radice dell’incidente viene collocata in una misconfigurazione introdotta il 21 dicembre 2025, associata a un commit identificato come bb1d0681396b41e9b779f9b7db4a27d43570af0c. È qui che prende forma la vulnerabilità ribattezzata Clinejection: nel repository di Cline, l’agente AI Claude viene delegato al triage automatico delle issue con permessi eccessivi. Questa scelta, apparentemente innocua, crea un percorso di execution che gli attaccanti sfruttano in modo chirurgico. A febbraio 2026, gli hacker creano issue su GitHub con titoli costruiti come prompt malevoli. Il titolo dell’issue non è più un testo “passivo”: diventa input attivo per un agente capace di eseguire operazioni, e quindi un canale di injection. Il risultato è l’esecuzione di comandi arbitrari nel branch di default, con un vantaggio decisivo: non serve compromettere un maintainer con phishing, basta manipolare l’automazione che “lavora al posto suo”.
La catena: prompt injection → cache poisoning → furto token → rilascio su npm
Il passaggio che rende l’operazione più interessante, e più inquietante, è il pivot sull’infrastruttura CI/CD. Dopo l’esecuzione iniziale, gli attaccanti avviano un attacco di avvelenamento della cache GitHub Actions, caricando oltre 10 GB di dati junk. GitHub applica una politica LRU (Least Recently Used) che, sotto pressione, finisce per espellere voci legittime. Questo non è un dettaglio tecnico: è il meccanismo che permette di sostituire asset “fidati” con asset avvelenati. In pratica, gli attaccanti preparano cache malevole che corrispondono alle chiavi usate da workflow privilegiati, inclusi quelli di release e pubblicazione. In un contesto così, la cache diventa un vettore di escalation: se un workflow con privilegi ripristina una cache manipolata, può finire per eseguire contenuti non previsti o esporre segreti. È così che, secondo la ricostruzione, viene sottratto il token npm publish (NPM_TOKEN o equivalente) e si arriva alla pubblicazione non autorizzata di Cline CLI 2.3.0. Qui la differenza con molti incidenti supply chain è netta: non si “inietta” codice nel sorgente principale in modo evidente. Si colpisce la pipeline e si ruba l’abilità di firmare e pubblicare come se fosse il progetto.
Cline CLI 2.3.0: cosa faceva davvero il pacchetto compromesso
La modifica più rilevante è nel package.json, dove compare uno script postinstall che installa openclaw@latest globalmente. Il resto, incluso il binario cli.mjs, risulta coerente con versioni precedenti (viene indicata la corrispondenza con 2.2.3), elemento che spiega perché l’incidente possa essere passato sotto il radar in controlli superficiali: l’utente installa Cline, tutto sembra funzionare, ma in background avviene un’installazione aggiuntiva non richiesta. Questo tipo di scelta attacca un punto psicologico del mondo npm: molti sviluppatori non leggono gli script postinstall, oppure li considerano “normali” in alcuni ecosistemi. Qui, invece, è l’elemento chiave della compromissione.
Perché l’impatto viene definito “low” ma il caso resta grave
I maintainer classificano la severità come bassa, e la motivazione dichiarata è che OpenClaw non mostra comportamenti maligni intrinseci nel contesto analizzato e non risulta avviato alcun daemon o “gateway” malevolo. In termini strettamente tecnici, è plausibile: non c’è evidenza di un payload che esfiltra o cripta. Ma sul piano della sicurezza supply chain, il livello di rischio non coincide sempre con il danno immediato. Il punto è che l’attore dimostra tre capacità che, in altri scenari, sono devastanti: la manipolazione di automazioni AI, l’abuso della cache CI/CD, e il furto di segreti di pubblicazione. Oggi installa un agent AI legittimo senza consenso; domani potrebbe installare un dropper. La gravità sistemica è nell’accesso ottenuto, non nell’oggetto installato.
Cosa non è stato colpito: estensioni IDE fuori dal perimetro
Un elemento importante per delimitare il danno è che l’incidente non riguarda l’estensione VS Code né plugin JetBrains: il perimetro indicato è specifico per Cline CLI e per la versione npm 2.3.0. Questo riduce la superficie potenzialmente impattata e spiega perché i maintainer abbiano potuto contenere l’incidente con una patch e una deprecazione rapida.
Scoperta e risposta: StepSecurity, Microsoft Threat Intelligence e l’advisory GHSA
L’incidente viene intercettato perché StepSecurity rileva il compromesso e perché Microsoft Threat Intelligence nota un aumento anomalo delle installazioni di OpenClaw, un segnale di telemetria che, in ecosistemi developer, diventa spesso un campanello d’allarme. La vulnerabilità “Clinejection” viene attribuita alla ricerca di Adnan Khan, e l’analisi richiama concetti emersi in lavori precedenti come PromptPwnd (sui rischi di prompt injection in automazioni AI) e Cacheract (sull’avvelenamento della cache in pipeline CI).
I maintainer pubblicano l’advisory GHSA-9ppg-jx86-fqw7, deprecano la 2.3.0 intorno alle 11:30 AM PT e rilasciano una versione corretta 2.4.0 (indicata come disponibile già intorno alle 11:23 AM PT). In parallelo, revocano i token compromessi e introducono misure più moderne per il publishing, spostandosi verso OIDC provenance e meccanismi di trusted publishing con attestazioni di integrità.
Cosa deve fare chi ha installato Cline CLI nella finestra a rischio
Chi ha installato Cline CLI durante la finestra di esposizione deve trattare la cosa come un controllo igienico immediato del proprio ambiente: verificare la versione installata con cline –version, aggiornare a una release sicura e rimuovere l’installazione globale non desiderata di OpenClaw se non necessaria. La rimozione viene indicata in modo lineare, con disinstallazione globale e reinstallazione aggiornata. L’aspetto più importante, però, non è solo “pulire” l’host. È controllare se in ambienti enterprise esistono policy che consentono installazioni globali e script postinstall senza controllo, perché questa famiglia di incidenti sfrutta proprio l’abitudine del mondo developer a dare per scontato ciò che l’ecosistema consente per design.
La lezione: AI agent nei workflow, ma con isolamento e least privilege reali
Questo incidente è un case study didattico su un rischio che diventa sempre meno teorico: un AI agent con permessi eccessivi è un moltiplicatore di attacco, perché trasforma input pubblici (issue, commenti, PR) in potenziali comandi. La difesa non è “non usare AI”, ma trattare l’AI come un componente ad alto rischio. Significa isolare, ridurre privilegi, filtrare input, evitare che l’agente possa eseguire comandi sul branch di default o interagire con segreti, e soprattutto spezzare i collegamenti tra automazioni “di community” e workflow di rilascio privilegiati. La seconda lezione riguarda GitHub Actions e la cache: quando meccanismi pensati per accelerare build diventano un vettore, serve osservabilità, limiti, e chiavi di cache non riutilizzabili in modo prevedibile. La cache, qui, non è un dettaglio di performance: è un asset di sicurezza.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
