Il punto di ingresso era scritto in linguaggio naturale
Il 17 febbraio 2026 qualcuno ha pubblicato cline@2.3.0 su npm. Il binario CLI era identico byte per byte alla versione precedente. L’unica modifica? Una singola riga nel package.json che ha innescato una reazione a catena devastante.
Per le successive otto ore, ogni sviluppatore che installava o aggiornava Cline si ritrovava OpenClaw – un agente AI separato con pieno accesso al sistema – installato globalmente sulla propria macchina senza consenso. Circa 4.000 download prima che il pacchetto venisse rimosso.
La parte interessante non è il payload. È come l’attaccante ha ottenuto il token npm: iniettando un prompt in un titolo di issue GitHub, che un bot AI di triage ha letto, interpretato come istruzione ed eseguito.
Cinque passi dal titolo di una issue a 4.000 macchine compromesse
L’attacco – che Snyk ha chiamato “Clinejection” – combina cinque vulnerabilità ben note in un singolo exploit che non richiede altro che aprire una issue GitHub.
Primo passo: prompt injection via titolo issue
Cline aveva implementato un workflow di triage automatico delle issue usando claude-code-action di Anthropic. Il workflow era configurato con allowed_non_write_users: “*”, il che significa che qualsiasi utente GitHub poteva attivarlo aprendo una issue. Il titolo della issue veniva interpolato direttamente nel prompt di Claude tramite ${{ github.event.issue.title }} senza alcuna sanitizzazione.
Il 28 gennaio un attaccante ha creato l’Issue #8904 con un titolo costruito per sembrare un report di performance ma contenente un’istruzione nascosta: installare un pacchetto da uno specifico repository GitHub.
Secondo passo: il bot AI esegue codice arbitrario
Claude ha interpretato l’istruzione iniettata come legittima ed eseguito npm install puntando al fork dell’attaccante – un repository typosquatted (glthub-actions/cline, notare la ‘i’ mancante in ‘github’). Il package.json del fork conteneva uno script preinstall che recuperava ed eseguiva uno script shell remoto.
Terzo passo: cache poisoning
Lo script shell ha implementato Cacheract, uno strumento di cache poisoning per GitHub Actions. Ha inondato la cache con oltre 10GB di dati spazzatura, attivando la policy di eviction LRU di GitHub ed eliminando le voci di cache legittime. Le voci avvelenate erano costruite per corrispondere al pattern di chiave cache usato dal workflow di rilascio notturno di Cline.
Quarto passo: furto di credenziali
Quando il workflow di rilascio notturno si è attivato e ha ripristinato node_modules dalla cache, ha ottenuto la versione compromessa. Il workflow di rilascio conteneva NPM_RELEASE_TOKEN, VSCE_PAT (VS Code Marketplace) e OVSX_PAT (OpenVSX). Tutti e tre sono stati esfiltrati.
Quinto passo: pubblicazione malevola
Usando il token npm rubato, l’attaccante ha pubblicato cline@2.3.0 con l’hook postinstall di OpenClaw. La versione compromessa è rimasta online per otto ore prima che il monitoraggio automatico di StepSecurity la segnalasse – circa 14 minuti dopo la pubblicazione.
Una rotazione delle credenziali mal gestita ha peggiorato tutto
Il ricercatore di sicurezza Adnan Khan aveva scoperto la catena di vulnerabilità a fine dicembre 2025 e l’aveva segnalata tramite GitHub Security Advisory il 1° gennaio 2026. Ha inviato molteplici solleciti nell’arco di cinque settimane. Nessuno ha ricevuto risposta.
Quando Khan ha divulgato pubblicamente il 9 febbraio, Cline ha corretto in 30 minuti rimuovendo i workflow di triage AI. Ha iniziato la rotazione delle credenziali il giorno successivo.
Ma la rotazione era incompleta. Il team ha eliminato il token sbagliato, lasciando attivo quello esposto. Hanno scoperto l’errore l’11 febbraio e ruotato nuovamente. Ma l’attaccante aveva già esfiltrato le credenziali e il token npm è rimasto valido abbastanza a lungo da pubblicare il pacchetto compromesso sei giorni dopo.
Khan non era l’attaccante. Un attore separato e sconosciuto ha trovato il proof-of-concept di Khan sul suo repository di test e l’ha trasformato in un’arma contro Cline direttamente.
Il nuovo pattern: AI installa AI
La catena di vulnerabilità specifica è interessante ma non senza precedenti. Prompt injection, cache poisoning e furto di credenziali sono tutte classi di attacco documentate. Quello che rende Clinejection distintivo è il risultato: uno strumento AI che installa silenziosamente un secondo agente AI sulle macchine degli sviluppatori.
Questo crea un problema di ricorsione nella supply chain. Lo sviluppatore si fida dello Strumento A (Cline). Lo Strumento A viene compromesso per installare lo Strumento B (OpenClaw). Lo Strumento B ha le proprie capacità – esecuzione shell, accesso alle credenziali, installazione di daemon persistenti – che sono indipendenti dallo Strumento A e invisibili alla decisione di fiducia originale dello sviluppatore.
OpenClaw come installato poteva leggere credenziali da ~/.openclaw/, eseguire comandi shell tramite la sua Gateway API e installarsi come daemon di sistema persistente che sopravvive ai riavvii. La gravità è stata dibattuta – Endor Labs ha caratterizzato il payload più vicino a un proof-of-concept che a un attacco armato – ma il meccanismo è quello che conta. Il prossimo payload non sarà un proof-of-concept.
Perché i controlli esistenti non l’hanno intercettato
npm audit: lo script postinstall installa un pacchetto legittimo e non dannoso (OpenClaw). Non c’è malware da rilevare.
Code review: il binario CLI era identico byte per byte alla versione precedente. Solo package.json è cambiato, e solo di una riga. I controlli automatici delle differenze che si concentrano sui cambiamenti binari lo avrebbero perso.
Attestazioni di provenienza: Cline non stava usando la provenienza npm basata su OIDC al momento. Il token compromesso poteva pubblicare senza metadati di provenienza, che StepSecurity ha segnalato come anomalo.
Prompt di autorizzazione: l’installazione avviene in un hook postinstall durante npm install. Nessuno strumento di coding AI chiede all’utente prima che uno script del ciclo di vita di una dipendenza venga eseguito. L’operazione è invisibile.
L’attacco ha sfruttato il divario tra quello che gli sviluppatori pensano di installare (una versione specifica di Cline) e quello che realmente viene eseguito (script del ciclo di vita arbitrari dal pacchetto e tutto ciò che installa transitivamente).
Cosa ha cambiato Cline dopo
La post-mortem di Cline delinea diversi passaggi di rimedio:
- Eliminato l’uso della cache di GitHub Actions dai workflow che gestiscono credenziali
- Adottate attestazioni di provenienza OIDC per la pubblicazione npm, eliminando i token a lunga vita
- Aggiunti requisiti di verifica per la rotazione delle credenziali
- Iniziato a lavorare su un processo formale di divulgazione delle vulnerabilità con SLA
- Commissionate audit di sicurezza di terze parti dell’infrastruttura CI/CD
Questi sono miglioramenti significativi. La sola migrazione OIDC avrebbe prevenuto l’attacco – un token rubato non può pubblicare pacchetti quando la provenienza richiede un’attestazione crittografica da uno specifico workflow di GitHub Actions.
La questione architettonica dell’intelligenza artificiale nella supply chain
Clinejection è un attacco alla supply chain, ma è anche un problema di sicurezza degli agenti. Il punto di ingresso era linguaggio naturale in un titolo di issue GitHub. Il primo anello della catena era un bot AI che ha interpretato testo non fidato come un’istruzione e l’ha eseguito con i privilegi dell’ambiente CI.
Questo è lo stesso pattern strutturale che abbiamo visto nel contesto dell’avvelenamento degli strumenti MCP e dei registry di skill degli agenti – input non fidato raggiunge un agente, l’agente agisce su di esso e niente valuta le operazioni risultanti prima che vengano eseguite.
La differenza qui è che l’agente non era l’assistente di coding locale di uno sviluppatore. Era un workflow CI automatizzato che girava su ogni nuova issue, con accesso shell e credenziali in cache. Il raggio d’impatto non era la macchina di uno sviluppatore – era l’intera pipeline di pubblicazione del progetto.
Ogni team che implementa agenti AI in CI/CD – per triage di issue, code review, testing automatizzato o qualsiasi altro workflow – ha questa stessa esposizione. L’agente elabora input non fidato (issue, PR, commenti) e ha accesso a segreti (token, chiavi, credenziali). La questione è se qualcosa valuta quello che l’agente fa con quell’accesso.
L’intercettazione per-syscall cattura questa classe di attacco a livello di operazione. Quando il bot di triage AI tenta di eseguire npm install da un repository inaspettato, l’operazione viene valutata contro la policy prima che venga eseguita – indipendentemente da cosa diceva il titolo dell’issue. Quando uno script del ciclo di vita tenta di esfil trare credenziali verso un host esterno, l’egress viene bloccato.
Il punto di ingresso cambia. Le operazioni no. grith è stato costruito per intercettare esattamente questa classe di problema – valutando ogni operazione a livello di syscall, indipendentemente da quale agente l’abbia attivata o perché.
