Modelli AI e dataset nel mirino: l’agente JadePuffer usa il ransomware EncForge per bloccare i laboratori di ML, mentre le sandbox crollano

🛡️ Executive Summary

• JadePuffer automatizza l’intrusione e distribuisce EncForge per cifrare checkpoint, dataset, modelli e database vettoriali senza esfiltrare informazioni.
• Socket Docker esposti e istanze Langflow vulnerabili consentono all’agente di ottenere privilegi root e adattare autonomamente la catena di attacco.
• Cursor, Codex e Gemini CLI mostrano fughe indirette dalle sandbox quando componenti host eseguono file o configurazioni prodotti dagli agenti.

JadePuffer evolve da agente ransomware autonomo a minaccia costruita specificamente contro le infrastrutture di intelligenza artificiale e machine learning. La nuova operazione utilizza EncForge, un ransomware progettato per cifrare checkpoint, dataset di addestramento, modelli, adattatori LoRA e database vettoriali. Parallelamente, una serie di vulnerabilità nei principali tool di coding agentici dimostra che l’isolamento del solo processo AI non protegge l’ambiente host. Cursor, Codex, Gemini CLI e Antigravity possono infatti scrivere configurazioni, hook o file che componenti privilegiati eseguono successivamente fuori dalla sandbox, trasformando l’autonomia dell’agente in un nuovo percorso di compromissione.

JadePuffer automatizza l’intera catena ransomware

JadePuffer opera come un agente capace di pianificare, eseguire e correggere un’intrusione senza una supervisione umana continua. Nell’episodio documentato è tornato su un’istanza Langflow già compromessa attraverso CVE-2025-3248, ha cercato credenziali cloud, token API e servizi interni, quindi ha individuato un socket Docker esposto che gli garantiva controllo a livello root. L’operazione rappresenta un’evoluzione della precedente campagna JadePuffer contro database MySQL e server Nacos, nella quale l’agente aveva già mostrato la capacità di adattare autonomamente ricognizione e distribuzione del payload. Quando il primo download del ransomware è fallito, JadePuffer ha generato sei script Python in circa cinque minuti, modificando progressivamente il metodo di consegna fino a produrre deploy.py v2. Lo script ha individuato il processo target, copiato EncForge oltre il namespace del container tramite procfs, eseguito una scansione preliminare e avviato la cifratura. Al termine ha contato i file con estensione .locked, utilizzando il risultato come verifica automatica del successo dell’operazione. La velocità dell’iterazione mostra perché gli attacchi agentici modificano il rapporto tra difesa e aggressore: ogni ostacolo tecnico può generare immediatamente una nuova variante, senza attendere l’intervento manuale di un operatore.

EncForge cifra checkpoint, dataset e database vettoriali

EncForge è un binario scritto in Go, compresso con UPX e progettato per individuare circa 180 estensioni legate agli ecosistemi AI e ML. I bersagli comprendono file SafeTensors, modelli PyTorch e TensorFlow, pesi GGUF e GGML, adattatori LoRA, indici FAISS e dataset in formato Parquet, Arrow, TFRecord, NumPy e DuckDB. Il ransomware non cifra integralmente ogni file, ma interviene su porzioni selezionate per aumentare la velocità e rendere comunque inutilizzabile l’asset. La crittografia utilizza AES-256 in modalità contatore, mentre la chiave simmetrica viene protetta attraverso RSA-2048. I file ricevono l’estensione .locked e una nota di riscatto contiene un identificativo univoco della vittima. La specializzazione distingue EncForge dai ransomware generalisti descritti nella guida alle gang RaaS e alle tecniche moderne di estorsione: invece di cifrare indiscriminatamente documenti e server, il malware identifica gli asset che rappresentano mesi di addestramento, tuning e raccolta dati. Non è stata osservata esfiltrazione, indicando un modello centrato sulla perdita di disponibilità. La variante Linux integra inoltre funzioni anti-recupero, tra cui la cancellazione delle copie di sicurezza e la disabilitazione delle opzioni di ripristino all’avvio.

La perdita dei modelli può bloccare mesi di sviluppo

La cifratura di un checkpoint non equivale alla perdita di un normale file applicativo. Un modello può incorporare settimane di training, dataset selezionati, procedure di fine-tuning, valutazioni interne e adattamenti sviluppati per specifici processi aziendali. La perdita simultanea di pesi, dataset e indici vettoriali può rendere inutilizzabile l’intera pipeline, obbligando l’organizzazione a ripetere addestramento, validazione e deployment. Le stime riportate collocano il danno tra circa 68.800 e 458.500 euro per singolo modello, ma l’impatto reale comprende anche ritardi nelle roadmap, indisponibilità dei servizi e perdita del vantaggio competitivo. Il socket Docker esposto svolge un ruolo decisivo perché converte la compromissione di un’applicazione in controllo dell’host, dinamica già osservata negli attacchi che concatenano vulnerabilità Docker, piattaforme AI ed evasione degli strumenti EDR. Le aziende devono quindi proteggere i modelli come asset di produzione: backup offline e immutabili, separazione tra training e serving, controllo degli accessi ai repository, rotazione dei token e monitoraggio delle modifiche ai file ad alta criticità. Una copia ospitata nello stesso cluster o montata nello stesso namespace non rappresenta una protezione adeguata contro un agente capace di raggiungere il livello root.

Le sandbox falliscono attraverso i componenti host fidati

Le ricerche su Cursor, Codex, Gemini CLI e Antigravity mostrano un modello di evasione differente da quello tradizionale. In molti casi l’agente non rompe direttamente il confine della sandbox, ma scrive file che un componente esterno considera affidabili ed esegue successivamente. Un socket Docker privilegiato ha offerto accesso a un ambiente non isolato in più piattaforme. In Cursor, l’agente ha modificato un interprete virtualenv successivamente caricato dall’estensione Python; in un altro caso ha creato directory Git con nomi alternativi a .git, inducendo l’estensione host ad attivare un fsmonitor controllato. La stessa superficie era già emersa quando Cursor eseguiva codice proveniente dai repository clonati e quando un prompt malevolo poteva trasformare Cursor IDE in un vettore RCE. In Codex CLI, una allowlist classificava alcuni comandi Git come sicuri senza analizzarne argomenti, directory e configurazioni caricate. Cursor poteva inoltre eseguire hook .claude, mentre Antigravity consentiva l’uso di funzioni non bloccate dal profilo Seatbelt. Un task VSCode scritto nello workspace completava lo stesso schema: l’agente produceva il contenuto, ma l’esecuzione avveniva tramite un processo host privilegiato.

La sicurezza agentica richiede un nuovo confine di fiducia

I casi documentati convergono su quattro debolezze: sandbox basate su denylist, configurazioni dello workspace trattate come dati innocui, allowlist concentrate sul nome del comando e daemon locali privilegiati raggiungibili dall’agente. La protezione deve quindi considerare non soltanto ciò che il modello può eseguire direttamente, ma anche ciò che può convincere altri componenti a eseguire. Le organizzazioni devono applicare un modello deny-by-default, impedire agli agenti di modificare hook, task, interpreti, configurazioni Git e file di automazione senza approvazione, oltre a isolare socket Docker e language server.

L’intero comando deve essere valutato in base ad argomenti, directory di lavoro, variabili d’ambiente ed effetti collaterali, superando le allowlist nominali. Le criticità descritte nell’analisi di AgentJacking contro gli AI coding agent e nel tool poisoning dei server MCP mostrano che codice sorgente, credenziali cloud e pipeline di rilascio convergono oggi nello stesso punto di rischio. JadePuffer aggiunge il livello successivo: un agente offensivo può sfruttare queste connessioni per raggiungere gli asset AI e cifrarli con un payload costruito appositamente per il loro ecosistema.