Un agente AI autonomo che ha conquistato internet nasconde vulnerabilità critiche
Nelle ultime settimane OpenClaw ha dominato i social media, GitHub e i forum tecnici. Un assistente AI always-on che vive nelle piattaforme di chat, esegue compiti per conto degli utenti e opera continuamente con supervisione minima. Per molti rappresenta il futuro dell’automazione personale e locale.
Il problema? Una ricerca di Zenity Labs pubblicata il 4 febbraio 2026 rivela che questo agente presenta vulnerabilità critiche di sicurezza che permettono agli attaccanti di stabilire backdoor persistenti attraverso attacchi di indirect prompt injection a zero-click. Tradotto: un assistente progettato per aiutarti può trasformarsi nel punto di ingresso perfetto per compromettere l’intera infrastruttura aziendale.
Il difetto architetturale che rende OpenClaw vulnerabile all’indirect prompt injection
OpenClaw è diverso dai chatbot tradizionali. Non si limita a rispondere – agisce. Può invocare strumenti, interagire con servizi esterni, leggere e scrivere file, eseguire comandi usando i permessi concessi durante il setup. L’interfaccia primaria è la conversazione: gli utenti collegano l’agente a piattaforme di chat e delegano compiti inviando istruzioni in linguaggio naturale.
Qui sta il problema fondamentale. Per essere utile, OpenClaw deve ingerire contenuti esterni da fonti non attendibili come parte del normale funzionamento:
- Messaggi inviati da altri utenti nelle chat condivise
- Contenuti recuperati dal browser
- Dati restituiti da skills e plugin
Il design critico è che OpenClaw non tratta questi input come dati passivi. I contenuti recuperati attraverso integrazioni di chat, accesso al browser o skills vengono processati nello stesso contesto conversazionale delle istruzioni dirette dell’utente. Nei test condotti da Zenity Labs non sono stati osservati guardrail progettati per rilevare o bloccare tentativi di indirect prompt injection.
In pratica non c’è separazione rigida tra ciò che l’utente ha chiesto all’agente di fare e ciò che l’agente legge mentre esegue quel compito. Una volta che i contenuti non attendibili vengono ingeriti, possono influenzare l’interpretazione interna del compito nello stesso modo delle istruzioni fornite dall’utente.
Come funziona l’attacco: dal documento malevolo al controllo totale
L’attacco inizia con uno scenario tipico di deployment enterprise. Un dipendente installa OpenClaw sulla propria workstation e lo distribuisce come agente di produttività personale, alimentato da un modello come GPT-5.2. L’utente integra OpenClaw con lo Slack Enterprise workspace dell’organizzazione e lo collega al Google Workspace aziendale.
A questo punto OpenClaw sta operando con permessi legittimi all’interno di due sistemi enterprise core. Ma ecco cosa succede quando qualcosa va storto.
L’iniezione del payload
L’obiettivo dell’attaccante non è l’esecuzione immediata, ma il controllo persistente. L’attacco inizia con un documento contenente contenuti controllati dall’attaccante – strutturato per apparire benigno, con testo legittimo in stile enterprise in alto. Più in profondità nel documento, un payload di indirect prompt injection è incorporato in modo da essere processato da OpenClaw come parte di un compito normale piuttosto che come un’istruzione esplicita dell’utente.
Quando OpenClaw processa il documento, il contenuto iniettato influenza l’interpretazione interna del compito. Invece di eseguire solo l’azione prevista dall’utente, l’agente viene indotto a creare una nuova integrazione di chat usando una piattaforma selezionata dall’attaccante – nella proof of concept di Zenity Labs, un bot Telegram.
Il canale di controllo esterno
Una volta creata l’integrazione, OpenClaw inizia ad accettare e rispondere ai messaggi dal bot controllato dall’attaccante. Il contesto enterprise originale ha adempiuto al suo ruolo – l’integrazione Slack e l’accesso a Google Workspace erano necessari solo per consegnare il contenuto iniziale. Da questo momento l’attaccante interagisce con OpenClaw esclusivamente attraverso il canale appena aggiunto.
Dal punto di vista di OpenClaw, questa transizione è del tutto legittima. L’agente sta semplicemente ricevendo istruzioni attraverso un’integrazione supportata che è stato configurato per fidare. Nessun alert, nessun piano di controllo enterprise coinvolto. Il risultato è un canale di controllo esterno persistente che esiste al di fuori della visibilità organizzativa.
Escalation: dalla manipolazione dell’agente alla compromissione del sistema
Una volta stabilito un backdoor persistente, l’attaccante può iniziare ad abusare di OpenClaw direttamente. Anche senza strumenti aggiuntivi, questo già abilita azioni dannose significative. Poiché l’agente opera con i permessi dell’utente, può eseguire comandi sulla macchina, interagire con il file system locale, accedere a dati sensibili ed eseguire operazioni distruttive.
Nella prima demo, Zenity Labs mostra un esempio di questa capacità: l’attaccante ordina a OpenClaw di localizzare file sulla macchina della vittima, esfiltrarli verso un endpoint controllato dall’attaccante, e poi eliminarli permanentemente dal file system locale. Queste azioni vengono eseguite interamente attraverso l’interfaccia di chat senza ulteriore sfruttamento.
La persistenza attraverso SOUL.md
OpenClaw mantiene un file chiamato SOUL.md che definisce l’identità, il tono e i confini comportamentali dell’agente. Questo file viene iniettato nel contesto durante ogni interazione e gioca un ruolo centrale nel modellare come l’agente ragiona e risponde nel tempo.
Utilizzando il backdoor, un attaccante può modificare questo file per influenzare il comportamento a lungo termine di OpenClaw. Nella proof of concept viene sfruttato questo meccanismo per introdurre persistenza a livello di sistema operativo – specificamente, viene ordinato a OpenClaw di creare un’attività pianificata sul sistema Windows che modifica periodicamente SOUL.md, assicurando che istruzioni controllate dall’attaccante vengano continuamente re-iniettate nel contesto dell’agente.
Il deployment di implant C2
Stabilire un backdoor persistente nell’agente è effettivamente solo l’inizio. Poiché OpenClaw opera come un processo sulla macchina host con privilegi per eseguire comandi, scaricare dati ed eseguire file, un attaccante può passare dalla manipolazione dell’agente alla compromissione dell’host sottostante.
Nella demo, Zenity Labs mostra questo ordinando all’agente di scaricare ed eseguire un beacon Sliver C2 – un framework command and control usato per operazioni di red team. Questo aggiorna la compromissione da uno scenario “rogue AI agent” a un implant di accesso remoto tradizionale. Con questo livello di accesso, un canale C2 serve come trampolino per movimento laterale, escalation di privilegi, harvesting di credenziali o deployment di ransomware.
Il contesto: vulnerabilità già note e preoccupazioni dell’industria
OpenClaw ha già attirato attenzione significativa per molteplici problemi di sicurezza. Nei giorni precedenti la pubblicazione del report di Zenity Labs, il progetto ha rilasciato tre advisory ad alto impatto:
- CVE-2026-25253 (CVSS 8.8): vulnerabilità di esecuzione codice remoto one-click che permette di rubare token di autenticazione
- Due vulnerabilità di command injection aggiuntive identificate e risolte
- Koi Security ha identificato 341 skills malicious inviate a ClawHub in un solo mese
Le principali firme di sicurezza hanno pubblicato avvertimenti. Cisco ha definito gli agenti AI personali come OpenClaw “a Security Nightmare”. Palo Alto Networks ha avvertito che OpenClaw presenta una “lethal trifecta” di rischi derivanti dal suo accesso a dati privati, esposizione a contenuti non attendibili e capacità di eseguire comunicazioni esterne mantenendo la memoria. Gartner ha dichiarato che OpenClaw rappresenta un rischio di cybersecurity inaccettabile.
Moltbook: la rete sociale per agenti che amplifica il rischio
OpenClaw si integra anche con Moltbook, una rete sociale esclusivamente per agenti AI che emula il formato di Reddit. Al 2 febbraio 2026, il sito riportava 1,5 milioni di bot registrati. I ricercatori di cybersecurity hanno citato Moltbook come vettore significativo per indirect prompt injection.
Il 31 gennaio 2026, 404 Media ha riportato una vulnerabilità critica causata da un database non protetto che permetteva a chiunque di comandare qualsiasi agente sulla piattaforma. Il problema è stato attribuito al fatto che il forum era stato “vibe-coded” – il fondatore ha dichiarato su X che “non ha scritto una singola linea di codice” per la piattaforma, dirigendo un assistente AI a creare l’intero sito.
Andrej Karpathy, ex direttore AI a Tesla, ha commentato: “è un dumpster fire, e definitivamente non raccomando che le persone eseguano questa roba sui loro computer.” Elon Musk ha dichiarato che Moltbook segna “le primissime fasi della singolarità.”
Una questione architetturale che va oltre OpenClaw
Questo scenario evidenzia una lezione più ampia per i sistemi agentici. L’indirect prompt injection non è un exploit che può essere patchato – è una conseguenza del design dove contenuti non attendibili e istruzioni utente convergono nello stesso contesto di elaborazione senza separazione rigida.
Come ha dichiarato Robert McSulla di Tenable: “La stessa autonomia che rende questi agenti preziosi è ciò che li rende unicamente rischiosi.” Adam Khan di Barracuda Networks ha definito il surge di questi strumenti “uno degli sviluppi più preoccupanti” della memoria recente, avvertendo che le caratteristiche strutturali di queste reti di agenti rispecchiano scenari che fino a poco tempo fa appartenevano alla fantascienza.
Per gli assistenti AI personali che vivranno sui nostri endpoint e all’interno dei nostri workflow aziendali, la sicurezza deve essere costruita dalle fondamenta. Gli agenti autonomi richiedono isolamento forte, controlli espliciti e confini applicabili. Senza questi elementi, quando gli assistenti AI ottengono capacità di esecuzione, ogni messaggio diventa un potenziale trigger – e ogni trigger può diventare un cambiamento di stato in un sistema reale.
