Preko 135 000 OpenClaw instanci izloženo je na internetu. Kritična ranjivost omogućuje daljinsko izvršavanje koda jednim klikom iz bilo kojeg preglednika. Istraživači su pronašli preko 1 100 zlonamjernih vještina koje distribuiraju Atomic Stealer na ClawHub-u. Microsoft je objavio blog post naslovljen “Running OpenClaw Safely” koji započinje napomenom da “za većinu okruženja, odgovarajuća odluka može biti ne implementirati ga.” Belgijski nacionalni centar za kibernetičku sigurnost izdao je vladno upozorenje. Cisco je osobne AI agente poput OpenClaw-a nazvao “sigurnosnom noćnom morom.”

Ovo nije širenje panike. To su činjenice od neovisnih sigurnosnih istraživača, korporativnih dobavljača i vladinih agencija. Ako upravljate OpenClaw instancom, ovo se tiče Vas.

Što je pošlo po krivu

OpenClaw je dizajniran za localhost. Instalirate ga na svoje računalo, komunicirate putem lokalnog web sučelja, a on izvršava zadatke u Vaše ime. Sigurnosni model pretpostavljao je da je osoba koja pristupa sučelju osoba koja sjedi za tipkovnicom.

Potom je OpenClaw skočio s 9 000 na preko 200 000 GitHub zvjezdica u roku od nekoliko tjedana. Ljudi su ga implementirali na VPS poslužitelje, izložili internetu i povezali sa svojim kanalima za razmjenu poruka. Pretpostavka localhost-a se urušila u velikom mjerilu. (Pokrili smo cijeli spektar opcija implementacije i njihove sigurnosne kompromise u zasebnom vodiču.)

CVE-2026-25253: daljinsko izvršavanje koda jednim klikom

Najozbiljnija ranjivost je CVE-2026-25253, ocijenjena CVSS ocjenom 8.8. OpenClaw nije validirao WebSocket origin zaglavlja. Ovako napad funkcionira:

  1. Žrtva posjeti zlonamjernu web stranicu (ili stranicu sa zlonamjernim oglasom).
  2. JavaScript na toj stranici otvara WebSocket vezu prema localhost:18789, zadanom OpenClaw portu.
  3. Budući da je preglednik na istom računalu, veza zaobilazi sva pravila vatrozida.
  4. Napadač eksfiltrira gateway autentifikacijski token putem WebSocket-a.
  5. S tokenom napadač ima potpunu kontrolu: pristup ljusci, čitanje/pisanje datoteka i izvršavanje naredbi.

Vezivanje na localhost ne pomaže. Napad se preusmjerava kroz vlastiti preglednik žrtve. Analiza SOCRadar-a prolazi kroz cijeli lanac.

Zlonamjerne vještine i napadi na lanac opskrbe

Istraživači su pronašli 341 zlonamjernu vještinu na ClawHub-u početkom veljače. Taj broj je od tada narastao na preko 1 100. Kampanja ClawHavoc distribuira Atomic Stealer putem vještina koje izgledaju legitimno, ali sadrže skrivene korake za izvršavanje naredbi. Vještine su Markdown datoteke. Skrivena instrukcija koja kaže “pokreni ovu ljusku naredbu” lako se ugradi i teško se uoči.

  1. veljače, napad na lanac opskrbe Cline-a otišao je korak dalje. Kompromitirani npm token korišten je za objavljivanje verzije Cline CLI-ja koja je tiho instalirala OpenClaw na računala programera. Napad je ciljao sam build pipeline.

Istraživači su sada otkrili šest dodatnih ranjivosti u jezgri OpenClaw-a, uključujući CVE-2026-27001. OWASP Top 10 za agentske aplikacije sada navodi mnoge od ovih obrazaca kao vodeće rizike. Kako to formulira analiza Conscie, radi se o punoj sigurnosnoj krizi.

Zašto gateway token nije dovoljan

Ugrađena autentifikacija OpenClaw-a je statički token. Postavite ga jednom, i svaki zahtjev ga mora sadržavati. To je bolje od ničega. Ali ima temeljnih ograničenja.

Statički tokeni ne istječu. Ako token procuri (putem CVE-2026-25253, putem logova, putem zlonamjerne vještine koja čita varijable okruženja), napadač ima trajni pristup dok ne primijetite i ručno ga rotirate.

Statički tokeni ne mogu biti ograničeni u dosegu. Gateway token daje puni pristup. Ne postoji način da se nekome da pristup samo za čitanje ili ograniči što autentificirana sesija može raditi.

Statički tokeni ne mogu biti vezani za korisnika. Ako tri osobe dijele token, nema revizijskog traga o tome tko je što napravio.

Većina VPS vodiča za implementaciju savjetuje stavljanje OpenClaw-a iza nginx-a s basic auth-om. To je bolje, ali i dalje je statička vjerodajnica. Ako je netko presretne (mrežno prisluškivanje na nekriptiranoj vezi, kompromitirana konfiguracija reverse proxyja, procurela .htpasswd datoteka), ima pristup.

Temeljni problem je dublji: autentifikacija se odvija unutar aplikacije. Ako aplikacija ima ranjivost, autentifikacija se može zaobići. CVE-2026-25253 to je točno demonstrirao. Gateway token je postojao. Ranjivost ga je ekstrahirala prije nego što je aplikacija uopće imala priliku verificirati ga.

Zato smo izgradili OpenClaw.rocks s autentifikacijom na razini proxyja. Sljedeći odjeljci detaljno objašnjavaju arhitekturu. Ako jednostavno želite sigurnu instancu bez da sve to gradite sami, pogledajte naše planove.

Kako osiguravamo gateway

U OpenClaw.rocks, autentifikacija se odvija na razini proxyja, prije nego zahtjev ikada dosegne OpenClaw pod. Ovo je strukturalna razlika, ne samo konfiguracijska.

Evo troslojne arhitekture.

Sloj 1: Potpisani gateway kolačići (HMAC-SHA256)

Kada pristupate svojoj OpenClaw instanci putem OpenClaw.rocks nadzorne ploče, poslužitelj generira potpisani kolačić. Format je:

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

Kolačić ima TTL od 4 sata i automatski se obnavlja svakih 45 minuta. Ograničen je na putanju /gw/{instanceId}, tako da se jedan kolačić ne može koristiti za pristup drugoj instanci. On je HttpOnly (JavaScript ga ne može čitati), Secure (šalje se samo putem HTTPS-a) i SameSite=Lax (ne šalje se pri cross-origin zahtjevima). HMAC se verificira koristeći vremenski sigurnu usporedbu za sprječavanje vremenskih napada.

Čak i ako netko presretne vrijednost kolačića, ne može lažirati novi bez tajne za potpisivanje. A sam kolačić ne sadrži vjerodajnice koje daju izravni pristup OpenClaw-u.

Sloj 2: Traefik ForwardAuth

Svaki zahtjev prema OpenClaw instanci prolazi kroz Traefik, naš reverse proxy. Prije prosljeđivanja zahtjeva, Traefik poziva auth-gate krajnju točku koja verificira potpisani kolačić.

Ovo je čista HMAC verifikacija. Nula poziva bazi podataka. Nula mrežnih zahtjeva prema Supabase-u ili bilo kojoj drugoj usluzi. Odluka se donosi u mikrosekundama.

Ako je kolačić nevažeći, istekao ili nedostaje, zahtjev se odbija na razini proxyja. Zahtjev nikada ne dosegne OpenClaw. Ovo je ključna razlika. U tipičnom postavu, sam OpenClaw mora odlučiti hoće li dopustiti ili odbiti zahtjev. Ako OpenClaw ima ranjivost u svojoj logici autentifikacije, napadač se može provući. U našem postavu, OpenClaw nikada ne vidi neautentificirani promet.

Sloj 3: Injektiranje gateway tokena

Svaka OpenClaw instanca ima ugrađeni gateway token. To je isti token koji biste sami konfigurirali da radite self-hosting. Razlika je u tome kako dolazi do poda.

U tipičnom self-hosting postavu, zalijepite token u konfiguracijsku datoteku, možda ga pohranite u varijablu okruženja i nadate se da nikada neće procuriti. Vaš preglednik ga mora slati sa svakim zahtjevom, što je točno način na koji ga je CVE-2026-25253 eksfiltrirao.

U našem postavu, kriptografski slučajni 32-bajtni token generira se pri stvaranju instance i pohranjuje kao Kubernetes Secret. Traefik ga injektira kao Authorization zaglavlje pri svakom proslijeđenom zahtjevu. Preglednik ga nikada ne vidi. Nikada se ne pojavljuje u konfiguracijskoj datoteci koju biste mogli slučajno commitati. Nikada ne putuje putem WebSocket-a koji bi zlonamjerna stranica mogla oteti. Token postoji, ali živi u potpunosti unutar klastera, krećući se samo između Traefik-a i poda.

Zašto ova arhitektura blokira CVE-2026-25253

Lanac napada CVE-2026-25253 eksfiltrira gateway token putem WebSocket-a. Prođimo kroz ono što se događa kada taj napad cilja OpenClaw.rocks instancu:

  1. Napadačev JavaScript pokušava otvoriti WebSocket prema OpenClaw podu.
  2. Veza prvo pogađa Traefik. Traefik provjerava potpisani kolačić.
  3. Zlonamjerna stranica je na drugom originu. SameSite=Lax kolačić se ne šalje pri cross-origin WebSocket vezama. Zahtjev se odbija.
  4. Čak i ako bi kolačić nekako bio priložen, napadačeva stranica ga ne može pročitati (HttpOnly). Nema što eksfiltrirati.
  5. Čak i ako bi kolačić procurio, ne sadrži bearer token. Bearer token injektira Traefik, nikada nije izložen pregledniku. Napadač ga ne može rekonstruirati.

Nema što ukrasti jer preglednik nikada ne posjeduje stvarne vjerodajnice. Napadačka površina koju CVE-2026-25253 iskorištava jednostavno ne postoji.

Sigurnosna kontrolna lista OpenClaw-a za self-hostere

Ne žele svi upravljani hosting, i to je u redu. Ako upravljate vlastitom OpenClaw instancom, evo praktične kontrolne liste za 2026.

Je li Vaš gateway autentifikacijski token omogućen? Pokrenite openclaw doctor za provjeru. Ako je gateway auth onemogućen, svatko tko može dosegnuti port 18789 kontrolira Vašeg agenta i sve čemu ima pristup.

Je li Vaša instanca iza reverse proxyja s TLS-om? Nekriptirani HTTP znači da svatko na mrežnom putu može pročitati Vaš gateway token u prijenosu. Koristite nginx, Caddy ili Traefik s valjanim TLS certifikatom. Let’s Encrypt je besplatan.

Jeste li na najnovijoj verziji? CVE-2026-25253 ispravljena je u v2026.1.29. CVE-2026-27001 ispravljena je u v2026.2.15. Ako koristite stariju verziju, ažurirajte sada. Adversa AI vodič za ojačavanje pokriva dodatne korake.

Jeste li provjerili instalirane vještine? Kampanja ClawHavoc ciljala je specifično ClawHub. Provjerite svaku vještinu koju ste instalirali. Ako je niste sami instalirali, uklonite je i provjerite izvor.

Validira li Vaš reverse proxy WebSocket origine? Ovo je specifični vektor koji je CVE-2026-25253 iskoristio. Vaš reverse proxy trebao bi odbijati WebSocket upgrade zahtjeve s neočekivanih origina. Sigurnosna dokumentacija OpenClaw-a sadrži konfiguracijske primjere.

Odvija li se Vaša autentifikacija prije ili nakon što zahtjev dosegne OpenClaw? Ovo je pitanje koje je najvažnije. Ako OpenClaw upravlja vlastitom autentifikacijom, ranjivost u OpenClaw-u je može zaobići. Ako Vaš reverse proxy upravlja autentifikacijom, zahtjev nikada ne dosegne OpenClaw osim ako nije već verificiran.

Što ne rješavamo

Iskrenost je ovdje važna. Autentifikacija na razini proxyja rješava sigurnost gatewaya. Ne rješava sve.

Ubacivanje promptova je problem na razini aplikacije. Vješto sastavljana poruka može potencijalno prevariti agenta da poduzme neželjene radnje. Ovo je aktivno područje istraživanja u cijeloj AI industriji i nijedan pružatelj hostinga to danas ne može u potpunosti spriječiti.

Zlonamjerno ponašanje vještina izvršava se unutar konteksta agenta. Ako instalirate vještinu koja eksfiltrira podatke putem dopuštenog izlaznog HTTPS prometa, proxy autentifikacija to ne može zaustaviti. Ono što naša infrastruktura radi jest ograničavanje radijusa eksplozije: svaka instanca radi u svom vlastitom Kubernetes podu s mrežnom izolacijom, smanjenim capabilities, seccomp-om i datotečnim sustavom root samo za čitanje. Kompromitirani agent ne može dosegnuti druge agente ili sustav domaćina. Kubernetes operator provodi ove zadane postavke za svaku instancu.

Povjerenje u LLM pružatelja ovisi o Vašem planu. Ako koristite vlastite API ključeve (plan Light), Vaši razgovori prolaze kroz pružatelja kojeg konfigurirate, i primjenjuje se njegova politika privatnosti. Na planu Pro usmjeravamo promet kroz naš vlastiti AI gateway s unaprijed konfiguriranim pružateljima. Ne trebate predavati svoje API ključeve OpenClaw instanci ili vjerovati da je ključ treće strane sigurno pohranjen. Gateway upravlja vjerodajnicama pružatelja u Vaše ime, a Vi ih nikada ne vidite niti izravno ne upravljate.

Sigurnost funkcionira u slojevima. Mi se brinemo za infrastrukturne slojeve. Izazovi na razini aplikacije su stvarni i vrijedi ih razumjeti.

Sigurnost je arhitekturna odluka

Sigurnosna kriza OpenClaw-a nije o jednom CVE-u ili jednoj seriji zlonamjernih vještina. Radi se o alatu dizajniranom za localhost koji na internet implementiraju stotine tisuća ljudi, s autentifikacijom koja se odvija unutar aplikacije koju bi trebala štititi.

Premještanje autentifikacije na razinu proxyja nije značajka. To je arhitekturna odluka. Znači da kada sljedeći OpenClaw CVE izađe (a izaći će), autentificirani zahtjevi će i dalje biti verificirani prije nego dodirnu aplikaciju. Napadačka površina je strukturalno manja.

Tu smo odluku donijeli prvog dana. Svaka OpenClaw.rocks instanca radi iza potpisanih kolačića, ForwardAuth verifikacije i bearer tokena po instanci. Bez gateway tokena u pregledniku. Bez statičkih vjerodajnica za eksfiltriranje. Bez logike autentifikacije unutar ranjive aplikacije.

Ako želite pročitati više o tome kako implementiramo OpenClaw na Kubernetes s potpunim sigurnosnim ojačavanjem, vodič za implementaciju to detaljno pokriva.

Ako jednostavno želite agenta koji radi i ostaje siguran bez razmišljanja o svemu ovome, upravo to smo izgradili.

Započnite na OpenClaw.rocks ili istražite Kubernetes operator otvorenog koda ako preferirate upravljati vlastitom infrastrukturom.