Consegnare a un attaccante le chiavi del proprio agente di intelligenza artificiale senza accorgersene, semplicemente per aver navigato su un sito web apparentemente innocuo: è esattamente lo scenario d’attacco che lo sfruttamento della vulnerabilità ribattezzata ClawJacked rende possibile su OpenClaw, uno dei framework agentic AI più utilizzati in ambito Enterprise e di sviluppo software.
La falla, scoperta e divulgata responsabilmente dai ricercatori di Oasis Security, è stata patchata da OpenClaw in meno di 24 ore con la versione 2026.2.25, rilasciata il 26 febbraio 2026.
Tuttavia, la sua natura tecnica e il contesto in cui si inserisce meritano un’analisi approfondita in quanto non si tratta solo di un bug da aggiornare, ma di un segnale chiaro su come la sicurezza degli AI agent sia oggi uno dei fronti più esposti dell’intera superficie d’attacco aziendale.
Indice degli argomenti
Come funziona l’attacco ClawJacked
Per capire la gravità di ClawJacked, è necessario partire dall’architettura di OpenClaw.
Il framework espone un gateway locale, ossia un server WebSocket in ascolto su localhost e protetto da password, attraverso il quale l’agente AI comunica con dispositivi e applicazioni registrate. A prima vista, un design di sviluppo ragionevole: il servizio non è accessibile dall’esterno e la password dovrebbe garantire la corretta autenticazione.
Il problema, come sottolineato dai ricercatori di Oasis Security, è che i browser moderni permettono a qualsiasi pagina web di aprire connessioni WebSocket verso localhost, senza che il meccanismo CORS (Cross-Origin Resource Sharing) lo blocchi.
In pratica, le WebSocket cross-origin non sono soggette alle stesse restrizioni delle normali richieste HTTP. Il risultato è proprio che qualsiasi sito malevolo visitato dallo sviluppatore può, in background e in silenzio totale, tentare di connettersi al gateway OpenClaw.
La catena d’attacco si articola, quindi, in quattro differenti fasi:
- Connessione silenziosa: il JavaScript malevolo della pagina apre una WebSocket verso la porta locale di OpenClaw.
- Brute force della password: l’assenza di meccanismi di rate limiting consente all’attaccante di tentare password a raffica senza essere bloccato.
- Registrazione automatica come dispositivo fidato: una volta autenticato, lo script si registra come nuovo dispositivo. OpenClaw, per connessioni provenienti da localhost, approva questa registrazione automaticamente, senza richiedere conferma all’utente.
- Controllo totale dell’agente: l’attaccante può interagire con l’AI, estrarre dati di configurazione, enumerare i nodi connessi, leggere i log applicativi.
Una catena d’attacco che dimostra come, in questo caso, la vulnerabilità non risiede in plugin, estensioni o marketplace di terze parti ma nel cuore stesso del sistema, ossia nel comportamento documentato e atteso del gateway.
Ed è questo un dettaglio che rende la falla ancora più insidiosa, perché non è il frutto di una configurazione errata da parte dell’utente.
Il trust mal riposto: localhost non è un perimetro sicuro
Il cuore del problema è concettuale prima ancora che tecnico. OpenClaw, come molti altri strumenti di sviluppo locale, opera su un’assunzione implicita: se una connessione arriva da localhost, allora può “fidarsi”.
Questa logica ha radici antiche nell’architettura dei sistemi Unix e nei modelli di sicurezza perimetrale, ma nel contesto del browser moderno è semplicemente sbagliata.
Il browser è un ambiente ostile per definizione: carica ed esegue codice JavaScript proveniente da migliaia di siti diversi ogni giorno. Quel codice può essere legittimo, ma può anche essere stato iniettato tramite un attacco supply chain, una XSS su un sito fidato, o semplicemente provenire da un dominio malevolo visitato per errore.
Trattare localhost come zona di fiducia, in questo scenario, equivale a lasciare la porta della server room aperta perché l’edificio ha un cancello all’ingresso.
La conseguenza pratica nel caso ClawJacked è stata l’approvazione automatica di nuovi dispositivi senza mostrare alcun prompt all’utente per connessioni localhost. Un meccanismo pensato per rendere sicuramente più fluida l’esperienza di sviluppo, ma che si è trasformato in un vettore di escalation dei privilegi immediata.
Un ecosistema sotto pressione: OpenClaw non è solo ClawJacked
ClawJacked non è una vulnerabilità isolata, ma l’ultimo capitolo di una serie di criticità che stanno emergendo nell’ecosistema OpenClaw con ritmo preoccupante.
Nelle settimane precedenti, il framework era già stato interessato da diverse CVE tra cui CVE-2026-25593, CVE-2026-24763 e CVE-2026-26319/22/29 che coprivano scenari di remote code execution, command injection, SSRF, authentication bypass e path traversal, con severity che arrivano fino al livello High.
Parallelamente, una vulnerabilità di log poisoning (risolta nella versione 2026.2.13) mostrava come l’agente AI potesse essere manipolato attraverso i propri log: un attaccante con accesso all’endpoint WebSocket pubblico su porta 18789 poteva scrivere contenuto malevolo che, una volta letto dall’agente durante le operazioni di troubleshooting, avrebbe potuto influenzarne il ragionamento o la disclosure di dati.
Un attacco indiretto, ma con conseguenze concrete su sistemi che delegano decisioni operative all’AI.
Il marketplace ClawHub aggiunge un ulteriore livello di rischio: ricercatori di Straiker hanno identificato oltre 70 skill malevole su 3.505 analizzate, alcune camuffate da tool per criptovalute che reindirizzavano fondi verso wallet controllati dagli attaccanti.
Infine, Trend Micro ha documentato campagne di distribuzione di Atomic Stealer tramite skill apparentemente innocue, mentre threat hunter hanno segnalato campagne social engineering attive negli stessi canali.
OpenClaw non è per workstation standard
In questo scenario, il Microsoft Defender Security Research Team ha emesso un advisory che, pur nella sua neutralità tecnica, suona come un campanello d’allarme per chiunque stia valutando il deployment di OpenClaw in contesti Enterprise: il framework va trattato come codice di esecuzione non fidato con credenziali persistenti e non è appropriato farlo girare su workstation personali o aziendali standard.
La raccomandazione Microsoft è di isolare completamente l’ambiente (macchina virtuale dedicata o sistema fisico separato che sia) con credenziali non privilegiate, accesso solo a dati non sensibili, monitoraggio continuo e un piano di rebuild.
Con un approccio che, come è evidente, riflette una comprensione matura del rischio, ma che è anche lontano anni luce dalla realtà di come molti sviluppatori usano oggi questi strumenti: direttamente sulla propria macchina di lavoro, con accesso a tutti i sistemi aziendali.
Cosa fare subito: indicazioni pratiche
Alla luce della gravità della vulnerabilità ClawJacked è opportuno mettere in pratica alcune indicazioni operative.
Aggiornamento immediato
Aggiornare OpenClaw alla versione 2026.2.25 o successiva è la priorità assoluta. Se si usa ancora la 2026.2.12 o precedenti, applicare anche la patch per il log poisoning (versione 2026.2.13).
Inoltre, occorre verificare la versione installata prima di qualsiasi altra operazione.
Audit dei dispositivi registrati
Verificare l’elenco dei dispositivi fidati nel gateway OpenClaw e revocare qualsiasi entry non riconosciuta o sospetta.
Se l’istanza era attiva in un periodo precedente alla patch, assumere la compromissione come scenario possibile e avviare un’analisi forense minimale.
Isolamento dell’ambiente di runtime
Seguire le indicazioni Microsoft: OpenClaw non dovrebbe girare sulla workstation principale.
Valutare il deploy su una macchina virtuale dedicata con accesso controllato, credenziali non privilegiate e nessun accesso a sistemi produttivi o repository di codice sensibile.
Password robusta e protezione da attacchi brute force
Importante anche impostare una password gateway lunga e casuale (almeno 24 caratteri, generata da un password manager).
Verificare che la versione aggiornata abbia implementato il rate limiting correttamente per mitigare eventuali tentativi di attacco brute force.
Per una maggiore sicurezza si potrebbe considerare anche l’uso di un firewall locale (es. regole UFW/iptables) per bloccare connessioni alla porta OpenClaw da tutti i processi tranne quelli autorizzati.
Audit delle skill ClawHub
Infine, è necessario rivedere le skill installate tramite ClawHub verificando provenienza, reputazione dell’autore e la presenza di una eventuale analisi VirusTotal.
Inoltre, occorre evitare di usare skill che richiedono credenziali, chiavi API o accesso a wallet crypto: ricordiamoci di seguire solo canali ufficiali per l’installazione.
Gestione e mitigazione del rischio: la prospettiva Enterprise
L’analisi tecnica di ClawJacked conferma un pattern che si ripete con crescente frequenza: l’AI agentica viene adottata con la stessa velocità e la stessa (scarsa) attenzione alla sicurezza con cui, dieci anni fa, venivano adottati i primi strumenti di DevOps.
La fretta di portare in produzione capacità di automazione intelligente lascia indietro la valutazione dei rischi associati.
Il problema con gli AI agent non è solo che possono essere compromessi: è che quando vengono compromessi, l’impatto è enormemente più grande di quello di un’applicazione tradizionale.
Un agente OpenClaw ben configurato ha accesso a e-mail, calendar, strumenti di project management, repository di codice, database, API aziendali: comprometterlo significa non compromettere un singolo sistema, ma l’entità che fa da hub tra tutti i sistemi.
Governance delle identità non-umane
Il punto di partenza per qualsiasi organizzazione che utilizzi o voglia utilizzare framework agentic AI è, dunque, trattare gli agenti AI come identità non-umane (NHI) soggette agli stessi controlli delle identità umane privilegiate.
Questo significa applicare il principio del minimo privilegio alle connessioni dell’agente: autorizzare solo i sistemi e le operazioni strettamente necessari, con revisione periodica delle autorizzazioni.
Occorre sempre tenere a mente che i permessi dati a un AI agent tendono a espandersi nel tempo, ma raramente vengono rivisti.
Threat modeling specifico per AI agent
Il threat modeling tradizionale non è sufficiente per i sistemi agentic AI. Va esteso per coprire vettori specifici come il prompt injection (diretto e indiretto), la compromissione delle skill di terze parti, la manipolazione dei log e l’abuso delle API dei sistemi integrati.
ClawJacked aggiunge a questa lista la compromissione via browser, ossia un vettore d’attacco che nessun team di sicurezza starebbe spontaneamente a modellare per un servizio che gira su localhost.
Monitoraggio comportamentale dell’agente
Molto utile anche implementare logging dettagliato delle azioni eseguite dall’agente AI, con alerting su comportamenti anomali: accesso a risorse inusuali, creazione di nuove connessioni, tentativi di accesso a file o sistemi fuori scope.
In ambienti Enterprise, inoltre, occorrerebbe integrare i log dell’agente nel SIEM aziendale. La visibilità sulle azioni degli AI agent è oggi, nella maggior parte delle organizzazioni, sostanzialmente nulla.
Policy di utilizzo e formazione
Molti developer che usano OpenClaw non sono figure di sicurezza: sono programmatori che usano uno strumento produttivo.
La formazione su rischi specifici come il phishing verso utenti di AI agent, la verifica delle skill prima dell’installazione e la gestione sicura delle credenziali integrate nell’agente rappresentano oggi un gap formativo critico che le organizzazioni devono colmare.
Profilo GDPR e data protection: l’agente AI come soggetto critico
C’è un altro problema specifico che la scoperta di ClawJacked pone dal punto di vista della data protection.
Un AI agent tipicamente processa, anche solo temporaneamente, dati personali: e-mail con informazioni di clienti, documenti HR, dati di accesso a sistemi che trattano dati sensibili. La compromissione dell’agente equivale, in molti casi, a una violazione dei dati personali ai sensi del GDPR.
I titolari del trattamento che utilizzano OpenClaw in contesti aziendali devono valutare se il framework rientra nell’ambito del loro registro dei trattamenti e della DPIA (Data Protection Impact Assessment), specialmente se l’agente accede a dati di categorie particolari o a sistemi che li contengono.
L’assenza di controlli adeguati come quelli che la scoperta della vulnerabilità ClawJacked ha evidenziato, può tradursi in una notifica di data breach obbligatoria all’autorità di controllo, con tutte le conseguenze del caso.
Una sveglia per l’intera industria AI agentica
È necessario sottolineare che OpenClaw ha risposto bene alla scoperta della vulnerabilità ClawJacked: il rilascio della patch in meno di 24 ore dalla divulgazione è un benchmark che molti vendor tradizionali non raggiungono.
Ma la velocità del fix non deve far perdere di vista la portata del segnale. Man mano che i framework AI agentic diventano infrastruttura Enterprise, l’analisi di sicurezza deve evolvere per indirizzare sia le vulnerabilità tradizionali che le superfici d’attacco specifiche dell’AI.
ClawJacked non è la prima e non sarà l’ultima vulnerabilità nei framework AI agentic. È però tra le prime a mostrare con chiarezza come l’integrazione profonda tra AI agent e sistemi aziendali, combinata con modelli di fiducia legacy, crei vettori d’attacco di portata potenzialmente devastante.
Il browser come punto d’ingresso per compromettere l’intera infrastruttura AI di un’organizzazione non era nel modello di minaccia di nessuno.
È dunque il momento di agire non solo con la patch, ma con un riesame strutturale di come viene distribuita l’intelligenza artificiale nelle aziende e proteggendo l’Agentic AI.
