Peste 135.000 de instanțe OpenClaw sunt expuse pe internet. O vulnerabilitate critică permite execuția de cod la distanță cu un singur clic din orice browser. Cercetătorii au descoperit peste 1.100 de skill-uri malițioase care distribuie Atomic Stealer pe ClawHub. Microsoft a publicat un articol intitulat „Running OpenClaw Safely” care începe prin a nota că „pentru majoritatea mediilor, decizia potrivită ar putea fi să nu fie implementat.” Centrul național de securitate cibernetică al Belgiei a emis un avertisment guvernamental. Cisco a numit agenții AI personali precum OpenClaw „un coșmar de securitate.”

Aceasta nu este panică nejustificată. Acestea sunt fapte de la cercetători independenți în securitate, furnizori enterprise și agenții guvernamentale. Dacă rulați o instanță OpenClaw, aceasta vă privește.

Ce a mers prost

OpenClaw a fost proiectat pentru localhost. Îl instalezi pe mașina ta, comunici prin interfața web locală, iar el acționează în numele tău. Modelul de securitate presupunea că persoana care accesează interfața este persoana care stă la tastatură.

Apoi OpenClaw a trecut de la 9.000 la peste 200.000 de stele pe GitHub în câteva săptămâni. Oamenii l-au implementat pe servere VPS, l-au expus pe internet și l-au conectat la canalele lor de mesagerie. Presupunerea localhost s-a prăbușit la scară largă. (Am acoperit spectrul complet de opțiuni de implementare și compromisurile lor de securitate într-un ghid separat.)

CVE-2026-25253: execuție de cod la distanță cu un singur clic

Cea mai gravă vulnerabilitate este CVE-2026-25253, cu scor CVSS 8.8. OpenClaw nu valida header-ele de origine WebSocket. Iată cum funcționează atacul:

  1. Victima vizitează o pagină web malițioasă (sau o pagină cu o reclamă malițioasă).
  2. JavaScript-ul de pe acea pagină deschide o conexiune WebSocket către localhost:18789, portul implicit OpenClaw.
  3. Deoarece browser-ul este pe aceeași mașină, conexiunea ocolește orice reguli de firewall.
  4. Atacatorul exfiltrează token-ul de autentificare al gateway-ului prin WebSocket.
  5. Cu token-ul, atacatorul are control deplin: acces la shell, citire/scriere de fișiere și execuție de comenzi.

Legarea la localhost nu ajută. Atacul se pivotează prin browser-ul propriu al victimei. Analiza SOCRadar parcurge întregul lanț.

Skill-uri malițioase și atacuri asupra lanțului de aprovizionare

Cercetătorii au găsit 341 de skill-uri malițioase pe ClawHub la începutul lui februarie. Acel număr a crescut de atunci la peste 1.100. Campania ClawHavoc distribuie Atomic Stealer prin skill-uri care par legitime dar conțin pași ascunși de execuție a comenzilor. Skill-urile sunt fișiere Markdown. O instrucțiune ascunsă care spune „rulează această comandă shell” este ușor de încorporat și greu de detectat.

Pe 17 februarie, atacul asupra lanțului de aprovizionare Cline a mers și mai departe. Un token npm compromis a fost folosit pentru a publica o versiune a CLI-ului Cline care instala silențios OpenClaw pe mașinile dezvoltatorilor. Atacul a vizat pipeline-ul de build în sine.

Cercetătorii au dezvăluit acum șase vulnerabilități suplimentare în nucleul OpenClaw, inclusiv CVE-2026-27001. OWASP Top 10 pentru Aplicații Agentice listează acum multe dintre aceste modele ca riscuri de top. După cum formulează analiza Conscia, aceasta este o criză de securitate în toată regula.

De ce un token gateway nu este suficient

Autentificarea integrată a OpenClaw este un token static. Îl setezi o dată, și fiecare cerere trebuie să îl includă. Este mai bine decât nimic. Dar are limitări fundamentale.

Token-urile statice nu expiră. Dacă un token se scurge (prin CVE-2026-25253, prin log-uri, prin un skill malițios care citește variabilele de mediu), atacatorul are acces permanent până când observi și faci rotația manual.

Token-urile statice nu pot fi limitate în domeniu. Token-ul gateway acordă acces complet. Nu există nicio modalitate de a oferi cuiva acces doar de citire sau de a limita ceea ce o sesiune autentificată poate face.

Token-urile statice nu pot fi legate de un utilizator. Dacă trei persoane partajează un token, nu există niciun traseu de audit pentru cine a făcut ce.

Cele mai multe ghiduri de implementare pe VPS vă spun să puneți OpenClaw în spatele nginx cu autentificare de bază. Este mai bine, dar rămâne o credențială statică. Dacă cineva o capturează (interceptare de rețea pe o conexiune necriptată, o configurație de reverse proxy compromisă, un fișier .htpasswd scurs), are acces.

Problema fundamentală este mai profundă: autentificarea are loc în interiorul aplicației. Dacă aplicația are o vulnerabilitate, autentificarea poate fi ocolită. CVE-2026-25253 a demonstrat exact acest lucru. Token-ul gateway exista. Vulnerabilitatea l-a extras înainte ca aplicația să aibă măcar șansa de a-l verifica.

De aceea am construit OpenClaw.rocks cu autentificare la nivel de proxy. Secțiunile de mai jos explică arhitectura în detaliu. Dacă doriți pur și simplu o instanță securizată fără a construi totul singur, vedeți planurile noastre.

Cum securizăm gateway-ul

La OpenClaw.rocks, autentificarea are loc la nivelul proxy-ului, înainte ca cererea să ajungă vreodată la pod-ul OpenClaw. Aceasta este o diferență structurală, nu doar o diferență de configurare.

Iată arhitectura cu trei straturi.

Când accesați instanța dvs. OpenClaw prin dashboard-ul OpenClaw.rocks, serverul generează un cookie semnat. Formatul este:

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

Cookie-ul are un TTL de 4 ore și se reîmprospătează automat la fiecare 45 de minute. Este limitat la calea /gw/{instanceId}, astfel încât un cookie nu poate fi folosit pentru a accesa o altă instanță. Este HttpOnly (JavaScript nu îl poate citi), Secure (trimis doar prin HTTPS) și SameSite=Lax (nu este trimis la cereri cross-origin). HMAC-ul este verificat folosind comparare cu timp constant pentru a preveni atacurile de timing.

Chiar dacă cineva interceptează valoarea cookie-ului, nu poate falsifica unul nou fără secretul de semnare. Iar cookie-ul în sine nu conține credențiale care să acorde acces direct la OpenClaw.

Stratul 2: Traefik ForwardAuth

Fiecare cerere către o instanță OpenClaw trece prin Traefik, reverse proxy-ul nostru. Înainte de a transmite cererea, Traefik apelează un endpoint auth-gate care verifică cookie-ul semnat.

Este verificare HMAC pură. Zero apeluri la baza de date. Zero cereri de rețea către Supabase sau orice alt serviciu. Decizia este luată în microsecunde.

Dacă cookie-ul este invalid, expirat sau lipsește, cererea este respinsă la nivelul proxy-ului. Cererea nu ajunge niciodată la OpenClaw. Aceasta este diferența cheie. Într-o configurare tipică, OpenClaw însuși trebuie să decidă dacă permite sau respinge o cerere. Dacă OpenClaw are o vulnerabilitate în logica sa de autentificare, un atacator poate trece. În configurarea noastră, OpenClaw nu vede niciodată trafic neautentificat.

Stratul 3: Injectarea token-ului gateway

Fiecare instanță OpenClaw are un token gateway integrat. Este același token pe care l-ați configura singur dacă ați face self-hosting. Diferența constă în modul în care ajunge la pod.

Într-o configurare tipică de self-hosting, lipiți token-ul într-un fișier de configurare, poate îl stocați într-o variabilă de mediu și sperați că nu se va scurge niciodată. Browser-ul trebuie să îl trimită la fiecare cerere, care este exact mecanismul pe care CVE-2026-25253 l-a exploatat pentru a-l exfiltra.

În configurarea noastră, un token criptografic aleatoriu de 32 de octeți este generat la crearea instanței și stocat ca un Kubernetes Secret. Traefik îl injectează ca header Authorization la fiecare cerere transmisă. Browser-ul nu îl vede niciodată. Nu apare niciodată într-un fișier de configurare pe care l-ați putea comite accidental. Nu călătorește niciodată printr-un WebSocket pe care o pagină malițioasă l-ar putea deturna. Token-ul există, dar trăiește în întregime în interiorul cluster-ului, deplasându-se doar între Traefik și pod.

De ce această arhitectură blochează CVE-2026-25253

Lanțul de atac al CVE-2026-25253 exfiltrează token-ul gateway prin WebSocket. Să parcurgem ce se întâmplă când acel atac vizează o instanță OpenClaw.rocks:

  1. JavaScript-ul atacatorului încearcă să deschidă un WebSocket către pod-ul OpenClaw.
  2. Conexiunea ajunge mai întâi la Traefik. Traefik verifică cookie-ul semnat.
  3. Pagina malițioasă este pe o origine diferită. Cookie-ul SameSite=Lax nu este trimis la conexiuni WebSocket cross-origin. Cererea este respinsă.
  4. Chiar dacă cookie-ul ar fi cumva atașat, pagina atacatorului nu îl poate citi (HttpOnly). Nu există nimic de exfiltrat.
  5. Chiar dacă cookie-ul s-ar scurge, nu conține token-ul bearer. Token-ul bearer este injectat de Traefik, niciodată expus browser-ului. Atacatorul nu îl poate reconstrui.

Nu există nimic de furat pentru că browser-ul nu deține niciodată credențialele reale. Suprafața de atac pe care CVE-2026-25253 o exploatează pur și simplu nu există.

Lista de verificare de securitate OpenClaw pentru self-hosteri

Nu toți doresc hosting gestionat, și asta e în regulă. Dacă rulați propria instanță OpenClaw, iată o listă practică de verificare pentru 2026.

Este activat token-ul de autentificare gateway? Rulați openclaw doctor pentru a verifica. Dacă autentificarea gateway este dezactivată, oricine poate ajunge la portul 18789 controlează agentul dvs. și tot ce are acces.

Este instanța dvs. în spatele unui reverse proxy cu TLS? HTTP necriptat înseamnă că oricine de pe calea rețelei poate citi token-ul gateway în tranzit. Folosiți nginx, Caddy sau Traefik cu un certificat TLS valid. Let’s Encrypt este gratuit.

Sunteți pe cea mai recentă versiune? CVE-2026-25253 a fost remediată în v2026.1.29. CVE-2026-27001 a fost remediată în v2026.2.15. Dacă rulați o versiune mai veche, actualizați acum. Ghidul de hardening Adversa AI acoperă pași suplimentari.

Ați auditat skill-urile instalate? Campania ClawHavoc a vizat specific ClawHub. Verificați fiecare skill pe care l-ați instalat. Dacă nu l-ați instalat dvs. personal, eliminați-l și verificați sursa.

Reverse proxy-ul dvs. validează originile WebSocket? Acesta este vectorul specific pe care CVE-2026-25253 l-a exploatat. Reverse proxy-ul dvs. ar trebui să respingă cererile de upgrade WebSocket de la origini neașteptate. Documentația de securitate OpenClaw conține exemple de configurare.

Autentificarea dvs. are loc înainte sau după ce cererea ajunge la OpenClaw? Aceasta este întrebarea care contează cel mai mult. Dacă OpenClaw gestionează propria autentificare, o vulnerabilitate în OpenClaw o poate ocoli. Dacă reverse proxy-ul gestionează autentificarea, cererea nu ajunge niciodată la OpenClaw decât dacă este deja verificată.

Ce nu rezolvăm

Onestitatea contează aici. Autentificarea la nivel de proxy rezolvă securitatea gateway-ului. Nu rezolvă totul.

Injectarea de prompt-uri este o problemă la nivel de aplicație. Un mesaj elaborat cu grijă poate potențial păcăli agentul să execute acțiuni neintenționate. Acesta este un domeniu activ de cercetare în întreaga industrie AI, și niciun furnizor de hosting nu îl poate preveni complet astăzi.

Comportamentul malițios al skill-urilor rulează în contextul agentului. Dacă instalați un skill care exfiltrează date prin trafic HTTPS de ieșire permis, autentificarea proxy nu poate opri asta. Ceea ce face infrastructura noastră este să limiteze raza de explozie: fiecare instanță rulează în propriul pod Kubernetes cu izolare de rețea, capabilities reduse, seccomp și un sistem de fișiere root doar pentru citire. Un agent compromis nu poate ajunge la alți agenți sau la sistemul gazdă. Operatorul Kubernetes aplică aceste setări implicite pentru fiecare instanță.

Încrederea în furnizorul LLM depinde de planul dvs. Dacă folosiți propriile chei API (planul Light), conversațiile dvs. trec prin orice furnizor configurați, iar politica lor de confidențialitate se aplică. La planul Pro, dirijăm traficul prin propriul nostru gateway AI cu furnizori preconfigurați. Nu trebuie să predați cheile API unei instanțe OpenClaw sau să aveți încredere că o cheie terță este stocată în siguranță. Gateway-ul gestionează credențialele furnizorilor în numele dvs., iar dvs. nu le vedeți sau gestionați niciodată direct.

Securitatea funcționează pe straturi. Noi ne ocupăm de straturile de infrastructură. Provocările la nivel de aplicație sunt reale și merită înțelese.

Securitatea este o decizie de arhitectură

Criza de securitate OpenClaw nu este despre un singur CVE sau un lot de skill-uri malițioase. Este despre un instrument proiectat pentru localhost care este implementat pe internet de sute de mii de oameni, cu autentificare care are loc în interiorul aplicației pe care ar trebui să o protejeze.

Mutarea autentificării la nivelul proxy-ului nu este o funcționalitate. Este o decizie de arhitectură. Înseamnă că atunci când următorul CVE OpenClaw apare (și va apărea), cererile autentificate sunt încă verificate înainte de a atinge aplicația. Suprafața de atac este structural mai mică.

Am luat această decizie din prima zi. Fiecare instanță OpenClaw.rocks rulează în spatele cookie-urilor semnate, verificării ForwardAuth și token-urilor bearer per instanță. Fără token-uri gateway în browser. Fără credențiale statice de exfiltrat. Fără logică de autentificare în interiorul aplicației vulnerabile.

Dacă doriți să citiți mai mult despre cum implementăm OpenClaw pe Kubernetes cu hardening complet de securitate, ghidul de implementare acoperă subiectul în detaliu.

Dacă doriți pur și simplu un agent funcțional care rămâne securizat fără a vă gândi la nimic din toate acestea, exact asta am construit.

Începeți pe OpenClaw.rocks sau explorați operatorul Kubernetes open-source dacă preferați să gestionați propria infrastructură.