ClawJacked: takeover dell’agente OpenClaw da qualsiasi sito web

ClawJacked è il tipo di vulnerabilità che non ha bisogno di exploit sofisticati per essere devastante, perché sfrutta una scorciatoia progettuale che molti strumenti locali considerano “ragionevole” e che, nel 2026, non lo è più: fidarsi di localhost come se fosse un perimetro. La falla, scoperta e divulgata da Oasis Security il 26 febbraio 2026, colpisce OpenClaw, un agente AI self-hosted che in pochi giorni è diventato un fenomeno di massa, superando le 100.000 stelle su GitHub in un arco temporale estremamente breve. Il cuore del problema è un gateway locale WebSocket che gestisce autenticazione, sessioni, configurazione e orchestrazione dei nodi collegati. Quel gateway, legandosi di default a localhost, appare “chiuso” e quindi sicuro. In realtà, nel modello di sicurezza moderno il browser è un ponte che collega l’esterno all’interno, e JavaScript può parlare con servizi su localhost più facilmente di quanto molti sviluppatori immaginino. L’effetto finale è brutale: un qualsiasi sito web visitato dallo sviluppatore, anche senza plugin, estensioni o interazioni particolari, può avviare una catena di attacco che porta al takeover completo dell’agente, alla registrazione silenziosa di un dispositivo “trusted” e, di conseguenza, all’accesso a credenziali API, chat, log, file e capacità di esecuzione comandi sui nodi collegati. Il team OpenClaw ha classificato la vulnerabilità come high severity e ha rilasciato una patch in meno di 24 ore nella versione 2026.2.25. Questa rapidità è un dato positivo, ma non attenua la lezione: gli agenti AI shadow, installati fuori dalla visibilità IT, stanno diventando un nuovo vettore privilegiato perché concentrano contesto, credenziali e potere operativo in un unico punto.

OpenClaw: perché un agente locale può diventare un asset critico senza che l’azienda lo sappia

OpenClaw si posiziona come assistente personale autonomo per sviluppatori, integrandosi con app di messaggistica, calendari e strumenti di sviluppo. Esegue azioni reali: invia messaggi, gestisce workflow, lancia comandi, coordina operazioni tra dispositivi e nodi connessi. Questo lo rende utile e, proprio per questo, pericoloso quando manca governance. Se un agente vive sul laptop di uno sviluppatore e ha accesso a token, chiavi, ambienti e canali di comunicazione, la sua compromissione non è più “un problema del singolo”, ma un incidente potenzialmente aziendale. Il contesto è importante anche per evitare un fraintendimento: ClawJacked non riguarda il marketplace o le estensioni. Non è un caso di “plugin malevolo”, né un problema limitato a un ecosistema di skill. La catena colpisce il core, il gateway che governa le funzioni centrali dell’agente. È proprio questo che la rende più interessante: dimostra che anche quando si toglie di mezzo l’anello più ovvio della supply chain, resta un perimetro locale fragile.

La fiducia in localhost: un anti-pattern che il web moderno sfrutta contro i tool locali

La vulnerabilità nasce da un presupposto: se una connessione arriva da localhost, allora è “di fiducia”. Nel gateway di OpenClaw questa fiducia si traduce in due scelte operative che, insieme, diventano un takeover. La prima scelta è l’assenza di rate limiting e di limiti sui tentativi falliti per le connessioni locali. Il gateway autentica tramite token o password, ma le connessioni localhost sono esentate da protezioni che normalmente impedirebbero brute-force efficaci. La seconda scelta è la logica di registrazione dei dispositivi: da localhost, la registrazione di un nuovo device viene approvata automaticamente senza prompt e senza un passaggio esplicito di conferma da parte dell’utente. In pratica, una volta ottenuta l’autenticazione, l’attaccante può trasformare la sessione in un’identità persistente “trusted”. Il passaggio che rende tutto praticabile da un sito web è tecnico ma decisivo: un sito può aprire una connessione WebSocket verso una porta su localhost, e JavaScript può orchestrare il traffico senza violare i vincoli che, intuitivamente, molti associano alla policy cross-origin. È qui che la superficie d’attacco si materializza: non serve entrare nella macchina, basta parlare con un servizio locale dal browser.

La catena di attacco: brute-force, device trust e controllo completo senza indicatori

La sequenza descritta dai ricercatori è lineare e proprio per questo inquietante. Un utente visita un sito malevolo, magari attraverso phishing o advertising. Lo script prova ad aprire WebSocket verso la porta del gateway locale. Una volta stabilita la connessione, avvia un brute-force sulla password a centinaia di tentativi al secondo, approfittando della mancanza di rate limiting per localhost. Le password comuni possono esaurirsi in meno di un secondo, mentre un dizionario più ampio richiede pochi minuti. L’attaccante non deve indovinare “una password forte”, deve solo sfruttare la velocità e la probabilità che molti utenti abbiano scelto credenziali riutilizzate o deboli. Quando l’autenticazione riesce, la registrazione del dispositivo diventa il punto di non ritorno. Il nuovo device viene approvato automaticamente e ottiene accesso completo alle funzioni dell’agente.

A quel punto l’attaccante può estrarre configurazioni, identificare provider AI collegati, leggere canali di messaggistica, enumerare nodi connessi con indirizzi IP e capacità operative. Se tra queste capacità c’è esecuzione comandi shell o accesso a risorse locali, l’agente compromesso diventa un proxy perfetto per muoversi lateralmente. Il dettaglio più pericoloso è l’assenza di indicatori visivi: la vittima non vede nulla, non riceve prompt, non percepisce la registrazione del dispositivo come evento di sicurezza.

Impatto: da compromissione developer a rischio aziendale e supply chain

In un ambiente reale, l’impatto non si ferma al laptop. Uno sviluppatore compromesso spesso possiede chiavi e token per CI/CD, accesso a repository, credenziali di ambienti cloud, canali Slack, strumenti di incident response, dataset e infrastrutture. ClawJacked, se sfruttata, permette di arrivare a questi asset attraverso un’interfaccia “legittima”: l’agente. È per questo che la vulnerabilità espande il blast radius: non è un malware tradizionale che deve vivere e nascondersi, ma un controllo del piano di orchestrazione che può fare azioni lecite con credenziali lecite. Nel testo compare anche una CVE associata, CVE-2026-25253, e viene indicato che al momento della divulgazione non risultavano exploit in the wild confermati, ma che l’esistenza di un PoC pubblico aumenta l’urgenza. Anche questa dinamica è tipica: un takeover via browser contro localhost, se facilmente replicabile, tende a scalare rapidamente perché si presta a campagne opportunistiche.

La risposta di OpenClaw: patch rapida, ma la lezione resta sul design

Il team OpenClaw ha rilasciato la correzione in meno di 24 ore nella versione 2026.2.25, classificando il problema come high severity. La patch, secondo la descrizione, interviene sulla gestione dell’autenticazione e sulla registrazione dei dispositivi da localhost, chiudendo la fiducia implicita che rendeva l’attacco silenzioso e veloce. La reattività è un segnale di maturità, ma per aziende e sviluppatori il punto operativo è più semplice e più duro: chi usa versioni precedenti resta esposto fino all’aggiornamento.

Cosa fare subito: aggiornamento critico e riduzione del potere degli agenti

Per gli utenti individuali, l’azione immediata è aggiornare OpenClaw a 2026.2.25 o successiva e trattare l’update come patch critica, non come “minor release”. Subito dopo, ha senso agire sulle conseguenze: rivedere le credenziali a cui l’agente aveva accesso, ruotare chiavi API sensibili, controllare integrazioni con messaggistica e tool di sviluppo, e verificare se esistono device registrati che non si riconoscono. Per le organizzazioni, l’ordine delle priorità cambia perché la vulnerabilità è un sintomo di un problema più ampio: la crescita di shadow AI fuori controllo. La prima urgenza è inventariare dove OpenClaw o tool simili sono installati e con quali permessi operano. La seconda urgenza è ridurre il privilegio: gli agenti non dovrebbero avere accesso permanente a token con scope ampio, né capacità di esecuzione comandi senza guardrail e senza audit trail. In pratica, l’agente va trattato come un’identità operativa, e quindi sottoposto alle stesse logiche che un’azienda applica a un service account: scoping minimo, durata limitata, tracciamento completo, revoca rapida.

Governance degli agenti: identità non umane, policy e audit come nuovo perimetro

ClawJacked mette in evidenza un punto che molte aziende stanno ancora metabolizzando: l’AI agent non è un “tool”, è un soggetto operativo che agisce. Se agisce, deve essere governato. La governance per identità non umane richiede policy specifiche che includano approvazione umana per azioni sensibili, accesso just-in-time, guardrail sulle chiamate tool e logging che consenta accountability. La domanda non è più se gli agenti entreranno nei workflow, ma come evitare che diventino un canale invisibile per esfiltrazione e movimento laterale. La lezione finale di ClawJacked è semplice e scomoda: in un mondo dove il browser può parlare con localhost, “localhost è fidato” non è una policy di sicurezza. È un’ipotesi che va dimostrata, e quasi sempre va sostituita.