Mbi 135,000 instanca OpenClaw janë të ekspozuara në internet. Një cenueshmëri kritike mundëson ekzekutimin e kodit në distancë me një klikim përmes çdo shfletuesi. Studiuesit kanë gjetur mbi 1,100 aftësi keqdashëse që shpërndajnë Atomic Stealer në ClawHub. Microsoft publikoi një postim blogu me titull “Running OpenClaw Safely” që fillon duke vërejtur se “për shumicën e mjediseve, vendimi i duhur mund të jetë të mos e vendosni.” Qendra kombëtare e sigurisë kibernetike e Belgjikës lëshoi një paralajmërim qeveritar. Cisco i quajti agjentët personalë AI si OpenClaw “një makth sigurie.”

Kjo nuk është frikësim. Këto janë fakte nga studiues të pavarur sigurie, furnizues ndërmarrjesh dhe agjenci qeveritare. Nëse po ekzekutoni një instancë OpenClaw, kjo ju intereson.

Çfarë shkoi keq

OpenClaw u projektua për localhost. E instaloni në makinën tuaj, bisedoni me të përmes një ndërfaqeje lokale ueb dhe ai bën gjëra në emrin tuaj. Modeli i sigurisë supozoi se personi që po aksesonte ndërfaqen ishte personi që rrinte në tastierë.

Pastaj OpenClaw u rrit nga 9,000 në mbi 200,000 yje GitHub brenda pak javësh. Njerëzit e vendosën në makina VPS, e ekspozuan në internet dhe e lidhën me kanalet e mesazheve të tyre. Supozimi i localhost u prish në shkallë. (Ne mbulojtëm spektrin e plotë të opsioneve të vendosjes dhe kompromistë e sigurisë në një udhëzues të veçantë.)

CVE-2026-25253: ekzekutim i kodit në distancë me një klikim

Cenueshmëria më e rëndë është CVE-2026-25253, me rezultat CVSS 8.8. OpenClaw nuk validonte kokat origin të WebSocket. Ja si funksionon sulmi:

  1. Viktima viziton një faqe ueb keqdashëse (ose një faqe me një reklamë keqdashëse).
  2. JavaScript në atë faqe hap një lidhje WebSocket me localhost:18789, portin e parazgjedhur të OpenClaw.
  3. Meqenëse shfletuesi është në të njëjtën makinë, lidhja anashkalon çdo rregull firewall-i.
  4. Sulmuesi nxjerr tokenin e autentifikimit të gateway-t përmes WebSocket.
  5. Me tokenin, sulmuesi ka kontroll të plotë: qasje në shell, lexim/shkrim skedarësh dhe ekzekutim komandash.

Lidhja me localhost nuk ndihmon. Sulmi ndërmjetësohet përmes shfletuesit të vetë viktimës. Analiza e SOCRadar kalon nëpër zinxhirin e plotë.

Aftësi keqdashëse dhe sulme të zinxhirit të furnizimit

Studiuesit gjetën 341 aftësi keqdashëse në ClawHub në fillim të shkurtit. Ky numër ka arritur në mbi 1,100. Fushata ClawHavoc shpërndan Atomic Stealer përmes aftësive që duken legjitime por përmbajnë hapa të fshehura ekzekutimi komandash. Aftësitë janë skedarë Markdown. Një udhëzim i fshehur që thotë “ekzekuto këtë komandë shell” është i lehtë për t’u vendosur dhe i vështirë për t’u pikasur.

Më 17 shkurt, sulmi i zinxhirit të furnizimit Cline e çoi gjënë më tej. Një token npm i komprometuar u përdor për të publikuar një version të Cline CLI që në heshtje instalonte OpenClaw në makinat e zhvilluesve. Sulmi synonte vetë linjën e ndërtimit.

Studiuesit tani kanë zbuluar gjashtë cenueshmëri shtesë në bërthamën e OpenClaw, përfshirë CVE-2026-27001. OWASP Top 10 për Aplikacione Agjentike tani liston shumë nga këto modele si rreziqet kryesore. Siç e shpreh analiza e Conscia, kjo është një krizë e plotë sigurie.

Pse një token gateway nuk mjafton

Autentifikimi i integruar i OpenClaw është një token statik. E vendosni një herë dhe çdo kërkesë duhet ta përfshijë. Është më mirë se asgjë. Por ka kufizime themelore.

Tokenat statike nuk skadojnë. Nëse një token rrjedh (përmes CVE-2026-25253, përmes log-eve, përmes një aftësie keqdashëse që lexon variablat e mjedisit), sulmuesi ka qasje të përhershme derisa ta vëreni dhe ta ndërroni manualisht.

Tokenat statike nuk mund të kufizohen. Tokeni i gateway-t jep qasje të plotë. Nuk ka mënyrë t’i jepni dikujt qasje vetëm-lexim ose të kufizoni çfarë mund të bëjë një seancë e autentifikuar.

Tokenat statike nuk mund të lidhen me një përdorues. Nëse tre persona ndajnë një token, nuk keni gjurmë auditimi për kush bëri çfarë.

Shumica e udhëzuesve të vendosjes VPS rekomandojnë vendosjen e OpenClaw pas nginx me autentifikim bazik. Kjo është më mirë, por përsëri është një kredencial statik. Nëse dikush e kap atë (përgjim rrjeti në një lidhje të pakriptuar, konfigurim i komprometuar i reverse proxy, skedar i rrjedhur .htpasswd), ai është brenda.

Problemi themelor është më i thellë: autentifikimi ndodh brenda aplikacionit. Nëse aplikacioni ka një cenueshmëri, autentifikimi mund të anashkalohet. CVE-2026-25253 e demonstroi këtë saktësisht. Tokeni i gateway-t ekzistonte. Cenueshmëria e nxori atë para se aplikacioni të kishte mundësi ta verifikonte.

Kjo është arsyeja pse ne ndërtuam OpenClaw.rocks me autentifikim në nivelin e proxy-t. Seksionet më poshtë shpjegojnë arkitekturën në detaje. Nëse thjesht dëshironi një instancë të sigurt pa e ndërtuar vetë, shikoni planet tona.

Si e sigurojmë gateway-n

Në OpenClaw.rocks, autentifikimi ndodh në nivelin e proxy-t, para se kërkesa të arrijë ndonjëherë pod-in e OpenClaw. Kjo është një dallim strukturor, jo thjesht një dallim konfigurimi.

Ja arkitektura me tre shtresa.

Kur aksesoni instancën tuaj OpenClaw përmes panelit të OpenClaw.rocks, serveri gjeneron një cookie të firmosur. Formati është:

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

Cookie-ja ka një TTL 4 orësh dhe rifresohet automatikisht çdo 45 minuta. Është e kufizuar në shtegën /gw/{instanceId}, kështu që një cookie nuk mund të përdoret për të aksesuar një instancë tjetër. Është HttpOnly (JavaScript nuk mund ta lexojë), Secure (dërgohet vetëm përmes HTTPS) dhe SameSite=Lax (nuk dërgohet në kërkesa cross-origin). HMAC verifikohet duke përdorur krahasim të sigurt nga ana kohore për të parandaluar sulmet e kohës.

Edhe nëse dikush e kap vlerën e cookie-s, nuk mund të falsifikojë një të re pa sekretin e firmës. Dhe vetë cookie-ja nuk përmban kredenciale që japin qasje direkte në OpenClaw.

Shtresa 2: Traefik ForwardAuth

Çdo kërkesë ndaj një instance OpenClaw kalon përmes Traefik, reverse proxy-t tonë. Para se të përcjellë kërkesën, Traefik thërret një pikë fundore auth-gate që verifikon cookie-n e firmosur.

Ky është verifikim i pastër HMAC. Zero thirrje databaze. Zero kërkesa rrjeti ndaj Supabase ose ndonjë shërbimi tjetër. Vendimi merret në mikrosekonda.

Nëse cookie-ja është e pavlefshme, e skaduar ose mungon, kërkesa refuzohet në nivelin e proxy-t. Kërkesa nuk arrin kurrë OpenClaw. Ky është dallimi kyç. Në një konfigurim tipik, vetë OpenClaw duhet të vendosë nëse lejon ose refuzon një kërkesë. Nëse OpenClaw ka një cenueshmëri në logjikën e autentifikimit, një sulmues mund të kalojë. Në konfigurimin tonë, OpenClaw nuk sheh kurrë trafik të paautentifikuar.

Shtresa 3: Injektimi i tokenit të gateway-t

Çdo instancë OpenClaw ka një token gateway të integruar. Ky është i njëjti token që do ta konfiguroni vetë nëse do të vetë-hostonit. Dallimi është se si arrin në pod.

Në një konfigurim tipik vetë-hostimi, ngjitni tokenin në një skedar konfigurimi, ndoshta e ruani në një variabël mjedisi dhe shpresoni se nuk do të rrjedhë kurrë. Shfletuesi juaj duhet ta dërgojë me çdo kërkesë, që është saktësisht mënyra si CVE-2026-25253 e nxori atë.

Në konfigurimin tonë, një token 32-bajt kriptografikisht i rastësishëm gjenerohet në krijimin e instancës dhe ruhet si Kubernetes Secret. Traefik e injekton si kokë Authorization në çdo kërkesë të përcjellë. Shfletuesi nuk e sheh kurrë. Nuk shfaqet kurrë në një skedar konfigurimi që mund ta bëni commit aksidentalisht. Nuk udhëton kurrë përmes një WebSocket që një faqe keqdashëse mund ta kapë. Tokeni ekziston, por jeton plotësisht brenda klasterit, duke lëvizur vetëm midis Traefik dhe pod-it.

Pse kjo arkitekturë bllokon CVE-2026-25253

Zinxhiri i sulmit CVE-2026-25253 nxjerr tokenin e gateway-t përmes WebSocket. Le të kalojmë nëpër çfarë ndodh kur ky sulm synohet ndaj një instance OpenClaw.rocks:

  1. JavaScript i sulmuesit përpiqet të hapë një lidhje WebSocket me pod-in e OpenClaw.
  2. Lidhja godet Traefik së pari. Traefik kontrollon cookie-n e firmosur.
  3. Faqja keqdashëse është në një origjinë tjetër. Cookie-ja SameSite=Lax nuk dërgohet në lidhjet WebSocket cross-origin. Kërkesa refuzohet.
  4. Edhe nëse cookie-ja do të ishte e bashkangjitur disi, faqja e sulmuesit nuk mund ta lexojë (HttpOnly). Nuk ka asgjë për të nxjerrur.
  5. Edhe nëse cookie-ja rrjedh, nuk përmban tokenin bearer. Tokeni bearer injektohet nga Traefik dhe nuk ekspozohet kurrë ndaj shfletuesit. Sulmuesi nuk mund ta rikonstruktojë.

Nuk ka asgjë për të vjedhur sepse shfletuesi nuk i mban kurrë kredencialet e vërteta. Sipërfaqja e sulmit që CVE-2026-25253 eksploaton thjesht nuk ekziston.

Lista e kontrollit të sigurisë së OpenClaw për vetë-hostuesit

Jo të gjithë duan hosting të menaxhuar, dhe kjo është në rregull. Nëse po ekzekutoni instancën tuaj OpenClaw, ja një listë kontrolli praktike për 2026.

A është tokeni juaj i autentifikimit të gateway-t i aktivizuar? Ekzekutoni openclaw doctor për të kontrolluar. Nëse autentifikimi i gateway-t është i çaktivizuar, kushdo që mund të arrijë portin 18789 kontrollon agjentin tuaj dhe gjithçka ku ai ka qasje.

A është instanca juaj pas një reverse proxy me TLS? HTTP i thjeshtë do të thotë se kushdo në shtegën e rrjetit mund të lexojë tokenin tuaj të gateway-t gjatë transitit. Përdorni nginx, Caddy ose Traefik me një çertifikatë të vlefshme TLS. Let’s Encrypt është falas.

A jeni në versionin e fundit? CVE-2026-25253 u rregullua në v2026.1.29. CVE-2026-27001 u rregullua në v2026.2.15. Nëse po ekzekutoni një version më të vjetër, përditësoni tani. Udhëzuesi i forcimit të Adversa AI mbulon hapa shtesë.

A i keni audituar aftësitë tuaja të instaluara? Fushata ClawHavoc synonte specifikisht ClawHub. Kontrolloni çdo aftësi që keni instaluar. Nëse nuk e instaluat vetë, hiqeni dhe verifikoni burimin.

A po validon reverse proxy-i juaj origjinat e WebSocket? Ky është vektori specifik që CVE-2026-25253 eksploatoi. Reverse proxy-i juaj duhet të refuzojë kërkesat e përmirësimit të WebSocket nga origjina të papritura. Dokumentacioni i sigurisë i OpenClaw ka shembuj konfigurimi.

A ndodh autentifikimi juaj para apo pasi kërkesa arrin OpenClaw? Kjo është pyetja më e rëndësishme. Nëse OpenClaw menaxhon autentifikimin e vet, një cenueshmëri në OpenClaw mund ta anashkalojë. Nëse reverse proxy-i juaj menaxhon autentifikimin, kërkesa nuk arrin kurrë OpenClaw nëse nuk është tashmë e verifikuar.

Çfarë nuk zgjidhim

Sinqeriteti ka rëndësi këtu. Autentifikimi në nivelin e proxy-t zgjidh sigurinë e gateway-t. Nuk zgjidh gjithçka.

Injektimi i prompt-it është problem i nivelit të aplikacionit. Një mesazh i ndërtuar me dinakëri mund potencialisht të mashtrojë agjentin për të ndërmarrë veprime të paqëllimshme. Ky është një fushë aktive kërkimi në të gjithë industrinë e AI dhe asnjë ofrues hostimi nuk mund ta parandalojë plotësisht sot.

Sjellja keqdashëse e aftësive ekzekutohet brenda kontekstit të agjentit. Nëse instaloni një aftësi që nxjerr të dhëna përmes një dalje të lejuar HTTPS, autentifikimi i proxy-t nuk mund ta ndalojë. Ajo çfarë bën infrastruktura jonë është kufizimi i rrezes së shpërthimit: çdo instancë ekzekutohet në pod-in e vet Kubernetes me izolim rrjeti, aftësi të hequra, seccomp dhe sistem skedarësh root vetëm për lexim. Një agjent i komprometuar nuk mund të arrijë agjentë të tjerë ose sistemin pritës. Operatori Kubernetes zbaton këto parazgjedhje për çdo instancë.

Besimi ndaj ofruesit LLM varet nga plani juaj. Nëse përdorni çelësat tuaj API (plani Light), bisedat tuaja kalojnë përmes ofruesit që konfiguroni dhe politika e tyre e privatësisë zbatohet. Në planin Pro, ne drejtojmë trafikun përmes gateway-t tonë AI me ofrues të parakonfiguruar. Nuk keni nevojë t’i dorëzoni çelësat tuaj API një instance OpenClaw ose të besoni se një çelës i palës së tretë ruhet me siguri. Gateway-i menaxhon kredencialet e ofruesve në emrin tuaj dhe ju nuk i shihni ose menaxhoni ato drejtpërdrejt kurrë.

Siguria është shtresa. Ne menaxhojmë shtresat e infrastrukturës. Sfidat e nivelit të aplikacionit janë reale dhe ia vlen t’i kuptoni.

Siguria është vendim arkitekturor

Kriza e sigurisë së OpenClaw nuk ka të bëjë me një CVE ose një seri aftësish keqdashëse. Ka të bëjë me një mjet të projektuar për localhost që vendoset në internet nga qindra mijëra njerëz, me autentifikim që ndodh brenda aplikacionit që supozohet ta mbrojë.

Lëvizja e autentifikimit në nivelin e proxy-t nuk është veçori. Është vendim arkitekturor. Kjo do të thotë se kur CVE-ja e radhës e OpenClaw del (dhe do të dalë), kërkesat e autentifikuara verifikohen ende para se të prekin aplikacionin. Sipërfaqja e sulmit është strukturalisht më e vogël.

Ne e morëm atë vendim që ditën e parë. Çdo instancë e OpenClaw.rocks ekzekutohet pas cookie-ve të firmosura, verifikimit ForwardAuth dhe tokenave bearer për instancë. Asnjë token gateway në shfletues. Asnjë kredencial statik për të nxjerrur. Asnjë logjikë autentifikimi brenda aplikacionit të cenueshëm.

Nëse dëshironi të lexoni më shumë rreth asaj se si e vendosim OpenClaw në Kubernetes me forcim të plotë sigurie, udhëzuesi i vendosjes e mbulon në detaje.

Nëse thjesht dëshironi një agjent që funksionon dhe mbetet i sigurt pa menduar për asgjë nga kjo, pikërisht këtë ndërtuam.

Filloni në OpenClaw.rocks ose eksploroni operatorin Kubernetes me burim të hapur nëse preferoni të ekzekutoni infrastrukturën tuaj.