Oltre 135.000 istanze di OpenClaw sono esposte su Internet. Una vulnerabilità critica consente l’esecuzione remota di codice con un solo clic da qualsiasi browser. I ricercatori hanno trovato oltre 1.100 skill malevoli che distribuiscono Atomic Stealer su ClawHub. Microsoft ha pubblicato un articolo intitolato “Running OpenClaw Safely” che si apre osservando che “per la maggior parte degli ambienti, la decisione appropriata potrebbe essere quella di non effettuare il deployment.” Il centro nazionale di cybersicurezza del Belgio ha emesso un avviso governativo. Cisco ha definito gli agenti IA personali come OpenClaw “un incubo per la sicurezza.”

Non si tratta di allarmismo. Questi sono fatti provenienti da ricercatori di sicurezza indipendenti, fornitori enterprise e agenzie governative. Se Lei gestisce un’istanza di OpenClaw, questo La riguarda.

Cosa è andato storto

OpenClaw è stato progettato per localhost. Lo si installa sulla propria macchina, si comunica attraverso un’interfaccia web locale e lui agisce per conto dell’utente. Il modello di sicurezza presupponeva che la persona che accedeva all’interfaccia fosse quella seduta alla tastiera.

Poi OpenClaw è passato da 9.000 a oltre 200.000 stelle su GitHub nel giro di poche settimane. Le persone lo hanno distribuito su server VPS, lo hanno esposto a Internet e lo hanno collegato ai loro canali di messaggistica. L’assunzione del localhost si è infranta su larga scala. (Abbiamo trattato l’intero spettro delle opzioni di deployment e i relativi compromessi di sicurezza in una guida separata.)

CVE-2026-25253: esecuzione remota di codice con un clic

La vulnerabilità più grave è CVE-2026-25253, con punteggio CVSS 8.8. OpenClaw non validava gli header di origine WebSocket. Ecco come funziona l’attacco:

  1. La vittima visita una pagina web malevola (o una pagina con un annuncio malevolo).
  2. Il JavaScript su quella pagina apre una connessione WebSocket verso localhost:18789, la porta predefinita di OpenClaw.
  3. Poiché il browser si trova sulla stessa macchina, la connessione aggira qualsiasi regola del firewall.
  4. L’attaccante esfiltra il token di autenticazione del gateway tramite il WebSocket.
  5. Con il token, l’attaccante ha il pieno controllo: accesso alla shell, lettura/scrittura di file ed esecuzione di comandi.

Il binding a localhost non aiuta. L’attacco si serve del browser della vittima stessa come punto di ingresso. L’analisi di SOCRadar illustra l’intera catena.

Skill malevoli e attacchi alla supply chain

I ricercatori hanno trovato 341 skill malevoli su ClawHub all’inizio di febbraio. Da allora il numero è cresciuto a oltre 1.100. La campagna ClawHavoc distribuisce Atomic Stealer attraverso skill che sembrano legittimi ma contengono passaggi nascosti di esecuzione di comandi. Gli skill sono file Markdown. Un’istruzione nascosta che dice “esegui questo comando shell” è facile da incorporare e difficile da individuare.

Il 17 febbraio, l’attacco alla supply chain di Cline ha alzato ulteriormente la posta. Un token npm compromesso è stato utilizzato per pubblicare una versione del CLI di Cline che installava silenziosamente OpenClaw sulle macchine degli sviluppatori. L’attacco prendeva di mira direttamente la pipeline di build.

I ricercatori hanno ora divulgato sei ulteriori vulnerabilità nel core di OpenClaw, tra cui CVE-2026-27001. La OWASP Top 10 per le Applicazioni Agentiche elenca ora molti di questi pattern come rischi principali. Come afferma l’analisi di Conscia, si tratta di una vera e propria crisi di sicurezza.

Perché un token del gateway non è sufficiente

L’autenticazione integrata di OpenClaw è un token statico. Lo si imposta una volta, e ogni richiesta deve includerlo. È meglio di niente. Ma presenta limitazioni fondamentali.

I token statici non scadono. Se un token viene divulgato (tramite CVE-2026-25253, tramite i log, tramite uno skill malevolo che legge le variabili d’ambiente), l’attaccante ha accesso permanente finché Lei non se ne accorge e lo ruota manualmente.

I token statici non possono essere limitati nell’ambito. Il token del gateway concede accesso completo. Non c’è modo di concedere a qualcuno l’accesso in sola lettura o di limitare ciò che una sessione autenticata può fare.

I token statici non possono essere associati a un utente. Se tre persone condividono un token, non esiste alcuna traccia di audit per sapere chi ha fatto cosa.

La maggior parte delle guide di deployment su VPS consiglia di mettere OpenClaw dietro nginx con autenticazione di base. È meglio, ma rimane una credenziale statica. Se qualcuno la intercetta (sniffing di rete su una connessione non crittografata, una configurazione di reverse proxy compromessa, un file .htpasswd divulgato), ha accesso.

Il problema fondamentale è più profondo: l’autenticazione avviene all’interno dell’applicazione. Se l’applicazione ha una vulnerabilità, l’autenticazione può essere aggirata. CVE-2026-25253 lo ha dimostrato esattamente. Il token del gateway esisteva. La vulnerabilità lo ha estratto prima ancora che l’applicazione avesse la possibilità di verificarlo.

Ecco perché abbiamo costruito OpenClaw.rocks con l’autenticazione a livello proxy. Le sezioni seguenti spiegano l’architettura nel dettaglio. Se desidera semplicemente un’istanza sicura senza costruire tutto questo da solo, consulti i nostri piani.

Come mettiamo in sicurezza il gateway

In OpenClaw.rocks, l’autenticazione avviene a livello proxy, prima che la richiesta raggiunga il pod di OpenClaw. Questa è una differenza strutturale, non solo una differenza di configurazione.

Ecco l’architettura a tre livelli.

Quando accede alla Sua istanza di OpenClaw tramite la dashboard di OpenClaw.rocks, il server genera un cookie firmato. Il formato è:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

Il cookie ha un TTL di 4 ore e si rinnova automaticamente ogni 45 minuti. È limitato al percorso /gw/{instanceId}, quindi un cookie non può essere usato per accedere a un’istanza diversa. È HttpOnly (JavaScript non può leggerlo), Secure (inviato solo tramite HTTPS) e SameSite=Lax (non inviato nelle richieste cross-origin). L’HMAC è verificato utilizzando un confronto a tempo costante per prevenire attacchi di temporizzazione.

Anche se qualcuno intercettasse il valore del cookie, non potrebbe crearne uno nuovo senza il segreto di firma. E il cookie stesso non contiene credenziali che concedano accesso diretto a OpenClaw.

Livello 2: Traefik ForwardAuth

Ogni richiesta verso un’istanza di OpenClaw passa attraverso Traefik, il nostro reverse proxy. Prima di inoltrare la richiesta, Traefik chiama un endpoint auth-gate che verifica il cookie firmato.

Si tratta di pura verifica HMAC. Zero chiamate al database. Zero richieste di rete verso Supabase o qualsiasi altro servizio. La decisione viene presa in microsecondi.

Se il cookie è invalido, scaduto o mancante, la richiesta viene respinta a livello proxy. La richiesta non raggiunge mai OpenClaw. Questa è la differenza fondamentale. In una configurazione tipica, è OpenClaw stesso a dover decidere se consentire o respingere una richiesta. Se OpenClaw ha una vulnerabilità nella sua logica di autenticazione, un attaccante può passare. Nella nostra configurazione, OpenClaw non vede mai traffico non autenticato.

Livello 3: Iniezione del token del gateway

Ogni istanza di OpenClaw ha un token del gateway integrato. È lo stesso token che Lei configurerebbe se facesse self-hosting. La differenza sta nel modo in cui raggiunge il pod.

In una tipica configurazione self-hosted, si incolla il token in un file di configurazione, magari lo si memorizza in una variabile d’ambiente, e si spera che non venga mai divulgato. Il browser deve inviarlo ad ogni richiesta, che è esattamente il meccanismo sfruttato da CVE-2026-25253 per esflitrarlo.

Nella nostra configurazione, un token crittograficamente casuale da 32 byte viene generato alla creazione dell’istanza e memorizzato come Kubernetes Secret. Traefik lo inietta come header Authorization in ogni richiesta inoltrata. Il browser non lo vede mai. Non appare mai in un file di configurazione che si potrebbe accidentalmente committare. Non viaggia mai su un WebSocket che una pagina malevola potrebbe dirottare. Il token esiste, ma vive interamente all’interno del cluster, spostandosi solo tra Traefik e il pod.

Perché questa architettura blocca CVE-2026-25253

La catena d’attacco di CVE-2026-25253 esfiltra il token del gateway via WebSocket. Vediamo cosa succede quando questo attacco prende di mira un’istanza di OpenClaw.rocks:

  1. Il JavaScript dell’attaccante tenta di aprire un WebSocket verso il pod di OpenClaw.
  2. La connessione raggiunge prima Traefik. Traefik verifica il cookie firmato.
  3. La pagina malevola si trova su un’origine diversa. Il cookie SameSite=Lax non viene inviato nelle connessioni WebSocket cross-origin. La richiesta viene respinta.
  4. Anche se il cookie fosse in qualche modo allegato, la pagina dell’attaccante non può leggerlo (HttpOnly). Non c’è nulla da esfiltrare.
  5. Anche se il cookie venisse divulgato, non contiene il token bearer. Il token bearer viene iniettato da Traefik, mai esposto al browser. L’attaccante non può ricostruirlo.

Non c’è nulla da rubare perché il browser non detiene mai le vere credenziali. La superficie d’attacco sfruttata da CVE-2026-25253 semplicemente non esiste.

Checklist di sicurezza OpenClaw per chi fa self-hosting

Non tutti vogliono l’hosting gestito, e va benissimo. Se gestisce la Sua istanza di OpenClaw, ecco una checklist pratica per il 2026.

Il Suo token di autenticazione del gateway è abilitato? Esegua openclaw doctor per verificarlo. Se l’autenticazione del gateway è disabilitata, chiunque possa raggiungere la porta 18789 controlla il Suo agente e tutto ciò a cui ha accesso.

La Sua istanza è dietro un reverse proxy con TLS? L’HTTP in chiaro significa che chiunque sul percorso di rete può leggere il Suo token del gateway in transito. Usi nginx, Caddy o Traefik con un certificato TLS valido. Let’s Encrypt è gratuito.

È sulla versione più recente? CVE-2026-25253 è stato corretto nella v2026.1.29. CVE-2026-27001 è stato corretto nella v2026.2.15. Se sta utilizzando una versione precedente, aggiorni ora. La guida al hardening di Adversa AI copre passaggi aggiuntivi.

Ha verificato gli skill installati? La campagna ClawHavoc prendeva di mira specificamente ClawHub. Controlli ogni skill che ha installato. Se non lo ha installato Lei stesso, lo rimuova e verifichi la fonte.

Il Suo reverse proxy valida le origini WebSocket? Questo è il vettore specifico sfruttato da CVE-2026-25253. Il Suo reverse proxy dovrebbe respingere le richieste di upgrade WebSocket da origini inaspettate. La documentazione sulla sicurezza di OpenClaw contiene esempi di configurazione.

La Sua autenticazione avviene prima o dopo che la richiesta raggiunga OpenClaw? Questa è la domanda più importante. Se OpenClaw gestisce la propria autenticazione, una vulnerabilità in OpenClaw può aggirarla. Se il Suo reverse proxy gestisce l’autenticazione, la richiesta non raggiunge mai OpenClaw a meno che non sia già verificata.

Cosa non risolviamo

L’onestà è importante qui. L’autenticazione a livello proxy risolve la sicurezza del gateway. Non risolve tutto.

La prompt injection è un problema a livello applicativo. Un messaggio abilmente formulato può potenzialmente indurre l’agente a compiere azioni non previste. Questo è un’area di ricerca attiva nell’intera industria dell’IA, e nessun provider di hosting può prevenirlo completamente oggi.

Il comportamento malevolo degli skill viene eseguito nel contesto dell’agente. Se installa uno skill che esfiltra dati attraverso traffico HTTPS in uscita consentito, l’autenticazione proxy non può fermarlo. Ciò che la nostra infrastruttura fa è contenere il raggio d’azione: ogni istanza viene eseguita nel proprio pod Kubernetes con isolamento di rete, capability ridotte, seccomp e un filesystem root in sola lettura. Un agente compromesso non può raggiungere altri agenti o il sistema host. L’operatore Kubernetes applica queste impostazioni predefinite per ogni istanza.

La fiducia nel provider LLM dipende dal Suo piano. Se utilizza le Sue chiavi API (piano Light), le Sue conversazioni passano attraverso qualsiasi provider Lei configuri, e si applica la loro policy sulla privacy. Con il piano Pro, instraiamo il traffico attraverso il nostro gateway AI con provider preconfigurati. Non ha bisogno di consegnare le Sue chiavi API a un’istanza di OpenClaw o fidarsi che una chiave di terze parti sia conservata in modo sicuro. Il gateway gestisce le credenziali dei provider per Suo conto, e Lei non le vede né le gestisce mai direttamente.

La sicurezza funziona a livelli. Noi gestiamo i livelli infrastrutturali. Le sfide a livello applicativo sono reali e meritano di essere comprese.

La sicurezza è una decisione architetturale

La crisi di sicurezza di OpenClaw non riguarda un singolo CVE o un lotto di skill malevoli. Riguarda uno strumento progettato per localhost che viene distribuito su Internet da centinaia di migliaia di persone, con un’autenticazione che avviene all’interno dell’applicazione che dovrebbe proteggere.

Spostare l’autenticazione al livello proxy non è una funzionalità. È una decisione architetturale. Significa che quando il prossimo CVE di OpenClaw verrà pubblicato (e accadrà), le richieste autenticate saranno comunque verificate prima di toccare l’applicazione. La superficie d’attacco è strutturalmente più piccola.

Abbiamo preso questa decisione dal primo giorno. Ogni istanza di OpenClaw.rocks viene eseguita dietro cookie firmati, verifica ForwardAuth e token bearer per istanza. Nessun token del gateway nel browser. Nessuna credenziale statica da esfiltrare. Nessuna logica di autenticazione all’interno dell’applicazione vulnerabile.

Se desidera approfondire come distribuiamo OpenClaw su Kubernetes con hardening di sicurezza completo, la guida al deployment lo tratta nel dettaglio.

Se desidera semplicemente un agente funzionante che resti sicuro senza dover pensare a tutto questo, è esattamente ciò che abbiamo costruito.

Inizi su OpenClaw.rocks o esplori l’operatore Kubernetes open-source se preferisce gestire la propria infrastruttura.