Přes 135 000 instancí OpenClaw je vystaveno na internetu. Kritická zranitelnost umožňuje vzdálené spuštění kódu jedním kliknutím z jakéhokoli prohlížeče. Výzkumníci našli přes 1 100 škodlivých skillů šířících Atomic Stealer na ClawHub. Microsoft publikoval blogový příspěvek s názvem „Running OpenClaw Safely”, který začíná konstatováním, že „pro většinu prostředí může být vhodným rozhodnutím jej nenasazovat.” Belgické národní centrum pro kybernetickou bezpečnost vydalo vládní varování. Cisco označilo osobní AI agenty jako OpenClaw za „bezpečnostní noční můru.”

Toto není šíření paniky. Jsou to fakta od nezávislých bezpečnostních výzkumníků, podnikových dodavatelů a vládních agentur. Pokud provozujete instanci OpenClaw, týká se vás to.

Co se pokazilo

OpenClaw byl navržen pro localhost. Nainstalujete si ho na počítač, komunikujete přes lokální webové rozhraní a on plní úkoly vaším jménem. Bezpečnostní model předpokládal, že osoba přistupující k rozhraní je osoba sedící u klávesnice.

Pak OpenClaw přeskočil z 9 000 na přes 200 000 hvězdiček na GitHub během několika týdnů. Lidé ho nasadili na VPS servery, vystavili na internet a propojili se svými komunikačními kanály. Předpoklad localhost se v měřítku zhroutil. (Celé spektrum možností nasazení a jejich bezpečnostní kompromisy jsme probrali v samostatném průvodci.)

CVE-2026-25253: vzdálené spuštění kódu jedním kliknutím

Nejzávažnější zranitelností je CVE-2026-25253, hodnocená CVSS 8.8. OpenClaw nevalidoval hlavičky origin u WebSocket. Takto útok funguje:

  1. Oběť navštíví škodlivou webovou stránku (nebo stránku se škodlivou reklamou).
  2. JavaScript na té stránce otevře WebSocket spojení na localhost:18789, výchozí port OpenClaw.
  3. Protože prohlížeč je na stejném počítači, spojení obchází veškerá pravidla firewallu.
  4. Útočník exfiltruje gateway autentizační token přes WebSocket.
  5. S tokenem má útočník plnou kontrolu: přístup ke shellu, čtení/zápis souborů a spouštění příkazů.

Navázání na localhost nepomáhá. Útok se otáčí přes vlastní prohlížeč oběti. Analýza SOCRadar prochází celý řetězec.

Škodlivé skilly a útoky na dodavatelský řetězec

Výzkumníci nalezli 341 škodlivých skillů na ClawHub začátkem února. Toto číslo od té doby vzrostlo na přes 1 100. Kampaň ClawHavoc šíří Atomic Stealer prostřednictvím skillů, které vypadají legitimně, ale obsahují skryté kroky ke spuštění příkazů. Skilly jsou Markdown soubory. Skrytá instrukce, která říká „spusť tento shell příkaz”, se snadno vloží a těžko odhalí.

  1. února útok na dodavatelský řetězec Cline šel ještě dál. Kompromitovaný npm token byl použit k publikaci verze Cline CLI, která tiše instalovala OpenClaw na počítače vývojářů. Útok cílil na samotný build pipeline.

Výzkumníci nyní odhalili šest dalších zranitelností v jádru OpenClaw, včetně CVE-2026-27001. OWASP Top 10 pro Agentické Aplikace nyní uvádí mnoho z těchto vzorů jako hlavní rizika. Jak to formuluje analýza Conscia, jedná se o plnohodnotnou bezpečnostní krizi.

Proč gateway token nestačí

Vestavěná autentizace OpenClaw je statický token. Nastavíte ho jednou a každý požadavek ho musí obsahovat. Je to lepší než nic. Ale má zásadní omezení.

Statické tokeny nevypršívají. Pokud token unikne (přes CVE-2026-25253, přes logy, přes škodlivý skill čtoucí proměnné prostředí), útočník má trvalý přístup, dokud si toho nevšimnete a manuálně ho nerotujete.

Statické tokeny nelze omezit v rozsahu. Gateway token poskytuje plný přístup. Neexistuje způsob, jak někomu dát přístup pouze ke čtení nebo omezit, co může autentizovaná relace dělat.

Statické tokeny nelze svázat s uživatelem. Pokud tři lidé sdílejí token, neexistuje auditní stopa o tom, kdo co udělal.

Většina návodů na nasazení na VPS doporučuje umístit OpenClaw za nginx s basic auth. To je lepší, ale stále jde o statický přihlašovací údaj. Pokud ho někdo zachytí (odposlech sítě na nešifrovaném spojení, kompromitovaná konfigurace reverse proxy, uniklý soubor .htpasswd), má přístup.

Základní problém je hlubší: autentizace probíhá uvnitř aplikace. Pokud má aplikace zranitelnost, autentizaci lze obejít. CVE-2026-25253 to přesně demonstrovala. Gateway token existoval. Zranitelnost ho extrahovala dříve, než měla aplikace šanci ho ověřit.

Proto jsme vybudovali OpenClaw.rocks s autentizací na úrovni proxy. Následující sekce podrobně vysvětlují architekturu. Pokud chcete jednoduše zabezpečenou instanci bez toho, abyste si to vše stavěli sami, podívejte se na naše plány.

Jak zabezpečujeme gateway

U OpenClaw.rocks probíhá autentizace na vrstvě proxy, dříve než požadavek vůbec dosáhne OpenClaw podu. Jedná se o strukturální rozdíl, nikoli pouze o konfigurační.

Zde je třívrstvá architektura.

Když přistupujete ke své instanci OpenClaw přes dashboard OpenClaw.rocks, server vygeneruje podepsaný cookie. Formát je:

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

Cookie má TTL 4 hodiny a automaticky se obnovuje každých 45 minut. Je omezen na cestu /gw/{instanceId}, takže jeden cookie nelze použít pro přístup k jiné instanci. Je HttpOnly (JavaScript ho nemůže číst), Secure (odesílán pouze přes HTTPS) a SameSite=Lax (neodesílán při cross-origin požadavcích). HMAC je ověřován pomocí časově bezpečného porovnání, aby se zabránilo časovým útokům.

I když někdo zachytí hodnotu cookie, nemůže podvrhnout nový bez podpisového tajemství. A cookie sám o sobě neobsahuje přihlašovací údaje, které by poskytovaly přímý přístup k OpenClaw.

Vrstva 2: Traefik ForwardAuth

Každý požadavek na instanci OpenClaw prochází přes Traefik, náš reverse proxy. Před předáním požadavku Traefik zavolá auth-gate endpoint, který ověří podepsaný cookie.

Jedná se o čistou HMAC verifikaci. Žádné databázové volání. Žádné síťové požadavky na Supabase nebo jakýkoli jiný servis. Rozhodnutí je učiněno v mikrosekundách.

Pokud je cookie neplatný, vypršelý nebo chybí, požadavek je odmítnut na vrstvě proxy. Požadavek nikdy nedosáhne OpenClaw. To je klíčový rozdíl. V typickém nastavení musí sám OpenClaw rozhodnout, zda požadavek povolí nebo odmítne. Pokud má OpenClaw zranitelnost ve své autentizační logice, útočník se může protáhnout. V našem nastavení OpenClaw nikdy nevidí neautentizovaný provoz.

Vrstva 3: Injekce gateway tokenu

Každá instance OpenClaw má vestavěný gateway token. Je to stejný token, který byste si nakonfigurovali sami při self-hostingu. Rozdíl je v tom, jak se dostane k podu.

V typickém nastavení self-hostingu vložíte token do konfiguračního souboru, možná ho uložíte do proměnné prostředí a doufáte, že nikdy neunikne. Váš prohlížeč ho musí odesílat s každým požadavkem, což je přesně způsob, jakým ho CVE-2026-25253 exfiltrovala.

V našem nastavení je při vytvoření instance vygenerován kryptograficky náhodný 32bajtový token a uložen jako Kubernetes Secret. Traefik ho injektuje jako hlavičku Authorization u každého předaného požadavku. Prohlížeč ho nikdy nevidí. Nikdy se neobjeví v konfiguračním souboru, který byste mohli omylem commitnout. Nikdy necestuje přes WebSocket, který by škodlivá stránka mohla unést. Token existuje, ale žije výhradně uvnitř clusteru a pohybuje se pouze mezi Traefikem a podem.

Proč tato architektura blokuje CVE-2026-25253

Útočný řetězec CVE-2026-25253 exfiltruje gateway token přes WebSocket. Pojďme projít, co se stane, když tento útok cílí na instanci OpenClaw.rocks:

  1. JavaScript útočníka se pokusí otevřít WebSocket k OpenClaw podu.
  2. Spojení nejprve narazí na Traefik. Traefik zkontroluje podepsaný cookie.
  3. Škodlivá stránka je na jiném originu. Cookie SameSite=Lax se neodesílá při cross-origin WebSocket spojeních. Požadavek je odmítnut.
  4. I kdyby byl cookie nějak připojen, stránka útočníka ho nemůže přečíst (HttpOnly). Není co exfiltrovat.
  5. I kdyby cookie unikl, neobsahuje bearer token. Bearer token je injektován Traefikem, nikdy není vystaven prohlížeči. Útočník ho nemůže rekonstruovat.

Není co ukrást, protože prohlížeč nikdy nedrží skutečné přihlašovací údaje. Útočná plocha, kterou CVE-2026-25253 exploituje, jednoduše neexistuje.

Bezpečnostní checklist OpenClaw pro self-hostery

Ne každý chce spravovaný hosting, a to je v pořádku. Pokud provozujete vlastní instanci OpenClaw, zde je praktický checklist pro rok 2026.

Je váš gateway autentizační token povolen? Spusťte openclaw doctor pro kontrolu. Pokud je gateway auth vypnutý, kdokoli, kdo se dostane k portu 18789, ovládá vašeho agenta a vše, k čemu má přístup.

Je vaše instance za reverse proxy s TLS? Nešifrované HTTP znamená, že kdokoli na síťové cestě může přečíst váš gateway token při přenosu. Použijte nginx, Caddy nebo Traefik s platným TLS certifikátem. Let’s Encrypt je zdarma.

Máte nejnovější verzi? CVE-2026-25253 byla opravena ve v2026.1.29. CVE-2026-27001 byla opravena ve v2026.2.15. Pokud používáte starší verzi, aktualizujte nyní. Průvodce hardeningem od Adversa AI pokrývá další kroky.

Provedli jste audit svých nainstalovaných skillů? Kampaň ClawHavoc cílila konkrétně na ClawHub. Zkontrolujte každý skill, který jste nainstalovali. Pokud jste ho neinstalovali vy sami, odstraňte ho a ověřte zdroj.

Validuje váš reverse proxy WebSocket originy? Toto je specifický vektor, který CVE-2026-25253 exploitovala. Váš reverse proxy by měl odmítat WebSocket upgrade požadavky z neočekávaných originů. Bezpečnostní dokumentace OpenClaw obsahuje konfigurační příklady.

Probíhá vaše autentizace před nebo po dosažení OpenClaw? Toto je otázka, na které nejvíce záleží. Pokud OpenClaw řeší svou vlastní autentizaci, zranitelnost v OpenClaw ji může obejít. Pokud váš reverse proxy řeší autentizaci, požadavek nikdy nedosáhne OpenClaw, pokud již není ověřen.

Co neřešíme

Upřímnost je zde důležitá. Autentizace na úrovni proxy řeší bezpečnost gateway. Neřeší vše.

Prompt injection je problém na úrovni aplikace. Chytře formulovaná zpráva může potenciálně oklamat agenta, aby provedl nezamýšlené akce. Jedná se o aktivní oblast výzkumu v celém odvětví AI a žádný poskytovatel hostingu to dnes nemůže plně zabránit.

Škodlivé chování skillů běží v kontextu agenta. Pokud nainstalujete skill, který exfiltruje data přes povolený HTTPS odchozí provoz, proxy auth to nemůže zastavit. Co naše infrastruktura dělá, je omezení výbuchového poloměru: každá instance běží ve vlastním Kubernetes podu se síťovou izolací, odebranými capabilities, seccomp a souborovým systémem root v režimu pouze pro čtení. Kompromitovaný agent nemůže dosáhnout na jiné agenty nebo hostitelský systém. Kubernetes operátor vynucuje tato výchozí nastavení pro každou instanci.

Důvěra v poskytovatele LLM závisí na vašem plánu. Pokud používáte vlastní API klíče (plán Light), vaše konverzace procházejí poskytovatelem, kterého nakonfigurujete, a platí jeho zásady ochrany soukromí. U plánu Pro směrujeme provoz přes naši vlastní AI gateway s předkonfigurovanými poskytovateli. Nemusíte předávat své API klíče instanci OpenClaw ani důvěřovat tomu, že klíč třetí strany je bezpečně uložen. Gateway spravuje přihlašovací údaje poskytovatelů vaším jménem a vy je nikdy nevidíte ani přímo nemanipulujete.

Bezpečnost funguje ve vrstvách. My se staráme o infrastrukturní vrstvy. Výzvy na úrovni aplikace jsou reálné a stojí za to jim rozumět.

Bezpečnost je architektonické rozhodnutí

Bezpečnostní krize OpenClaw není o jednom CVE nebo jedné dávce škodlivých skillů. Je o nástroji navrženém pro localhost, který je nasazován na internetu stovkami tisíc lidí, s autentizací, která probíhá uvnitř aplikace, kterou má chránit.

Přesunutí autentizace na vrstvu proxy není funkce. Je to architektonické rozhodnutí. Znamená to, že když příští OpenClaw CVE přijde (a přijde), autentizované požadavky budou stále ověřovány před tím, než se dotknou aplikace. Útočná plocha je strukturálně menší.

Toto rozhodnutí jsme učinili první den. Každá instance OpenClaw.rocks běží za podepsanými cookie, ForwardAuth verifikací a bearer tokeny pro každou instanci. Žádné gateway tokeny v prohlížeči. Žádné statické přihlašovací údaje k exfiltraci. Žádná autentizační logika uvnitř zranitelné aplikace.

Pokud si chcete přečíst více o tom, jak nasazujeme OpenClaw na Kubernetes s kompletním bezpečnostním hardeningem, průvodce nasazením to pokrývá podrobně.

Pokud chcete jednoduše běžícího agenta, který zůstane zabezpečený bez přemýšlení o čemkoli z toho, přesně to jsme vybudovali.

Začněte na OpenClaw.rocks nebo prozkoumejte open-source Kubernetes operátor, pokud dáváte přednost správě vlastní infrastruktury.