Ponad 135 000 instancji OpenClaw jest wystawionych w Internecie. Krytyczna podatność umożliwia zdalne wykonanie kodu jednym kliknięciem z dowolnej przeglądarki. Badacze znaleźli ponad 1100 złośliwych skilli dystrybuujących Atomic Stealer przez ClawHub. Microsoft opublikował wpis na blogu zatytułowany „Running OpenClaw Safely”, który zaczyna się od stwierdzenia, że „dla większości środowisk właściwą decyzją może być rezygnacja z wdrożenia.” Belgijskie krajowe centrum cyberbezpieczeństwa wydało ostrzeżenie rządowe. Cisco nazwało osobistych agentów AI takich jak OpenClaw „koszmarem bezpieczeństwa.”

To nie jest szerzenie paniki. To fakty od niezależnych badaczy bezpieczeństwa, dostawców korporacyjnych i agencji rządowych. Jeśli prowadzisz instancję OpenClaw, to Cię dotyczy.

Co poszło nie tak

OpenClaw został zaprojektowany dla localhost. Instalujesz go na swoim komputerze, komunikujesz się przez lokalny interfejs webowy, a on wykonuje zadania w Twoim imieniu. Model bezpieczeństwa zakładał, że osoba uzyskująca dostęp do interfejsu to osoba siedząca przy klawiaturze.

Potem OpenClaw przeskoczył z 9 000 do ponad 200 000 gwiazdek na GitHub w ciągu kilku tygodni. Ludzie wdrażali go na serwerach VPS, wystawiali w Internecie i podłączali do swoich kanałów komunikacyjnych. Założenie localhost przestało działać na dużą skalę. (Omówiliśmy pełne spektrum opcji wdrożeniowych i ich kompromisy bezpieczeństwa w osobnym przewodniku.)

CVE-2026-25253: zdalne wykonanie kodu jednym kliknięciem

Najpoważniejszą podatnością jest CVE-2026-25253, oceniona na CVSS 8.8. OpenClaw nie walidował nagłówków origin WebSocket. Oto jak działa atak:

  1. Ofiara odwiedza złośliwą stronę internetową (lub stronę ze złośliwą reklamą).
  2. JavaScript na tej stronie otwiera połączenie WebSocket do localhost:18789, domyślnego portu OpenClaw.
  3. Ponieważ przeglądarka znajduje się na tym samym komputerze, połączenie omija wszelkie reguły firewalla.
  4. Atakujący eksfiltruje token uwierzytelniania gateway przez WebSocket.
  5. Z tokenem atakujący ma pełną kontrolę: dostęp do powłoki, odczyt/zapis plików i wykonywanie poleceń.

Powiązanie z localhost nie pomaga. Atak wykorzystuje własną przeglądarkę ofiary jako punkt wejścia. Analiza SOCRadar opisuje pełny łańcuch ataku.

Złośliwe skille i ataki na łańcuch dostaw

Badacze znaleźli 341 złośliwych skilli na ClawHub na początku lutego. Ta liczba wzrosła od tego czasu do ponad 1100. Kampania ClawHavoc dystrybuuje Atomic Stealer przez skille, które wyglądają na legalne, ale zawierają ukryte kroki wykonywania poleceń. Skille to pliki Markdown. Ukryta instrukcja mówiąca „uruchom tę komendę powłoki” jest łatwa do osadzenia i trudna do wykrycia.

17 lutego atak na łańcuch dostaw Cline poszedł jeszcze dalej. Skompromitowany token npm został użyty do opublikowania wersji CLI Cline, która po cichu instalowała OpenClaw na maszynach deweloperów. Atak był wymierzony w sam pipeline budowania.

Badacze ujawnili teraz sześć dodatkowych podatności w rdzeniu OpenClaw, w tym CVE-2026-27001. OWASP Top 10 dla Aplikacji Agentowych wymienia teraz wiele z tych wzorców jako główne ryzyka. Jak ujmuje to analiza Conscia, to jest pełnowymiarowy kryzys bezpieczeństwa.

Dlaczego token gateway nie wystarczy

Wbudowane uwierzytelnianie OpenClaw to statyczny token. Ustawiasz go raz, a każde żądanie musi go zawierać. To lepsze niż nic. Ale ma fundamentalne ograniczenia.

Statyczne tokeny nie wygasają. Jeśli token wycieknie (przez CVE-2026-25253, przez logi, przez złośliwy skill czytający zmienne środowiskowe), atakujący ma stały dostęp, dopóki nie zauważysz i nie wykonasz ręcznej rotacji.

Statyczne tokeny nie mogą być ograniczone w zakresie. Token gateway daje pełny dostęp. Nie ma możliwości nadania komuś dostępu tylko do odczytu lub ograniczenia tego, co uwierzytelniona sesja może robić.

Statyczne tokeny nie mogą być powiązane z użytkownikiem. Jeśli trzy osoby dzielą token, nie ma śladu audytowego, kto co zrobił.

Większość przewodników wdrożeniowych dla VPS zaleca umieszczenie OpenClaw za nginx z basic auth. To lepsze rozwiązanie, ale nadal jest to statyczne dane uwierzytelniające. Jeśli ktoś je przechwci (podsłuch sieciowy na niezaszyfrowanym połączeniu, skompromitowana konfiguracja reverse proxy, wyciekły plik .htpasswd), uzyskuje dostęp.

Fundamentalny problem jest głębszy: uwierzytelnianie odbywa się wewnątrz aplikacji. Jeśli aplikacja ma podatność, uwierzytelnianie może zostać ominięte. CVE-2026-25253 dokładnie to zademonstrował. Token gateway istniał. Podatność wyekstrahowała go, zanim aplikacja w ogóle miała szansę go zweryfikować.

Dlatego zbudowaliśmy OpenClaw.rocks z uwierzytelnianiem na poziomie proxy. Poniższe sekcje wyjaśniają architekturę szczegółowo. Jeśli po prostu chcesz bezpieczną instancję bez budowania tego samodzielnie, zobacz nasze plany.

Jak zabezpieczamy gateway

W OpenClaw.rocks uwierzytelnianie odbywa się na warstwie proxy, zanim żądanie dotrze do poda OpenClaw. To jest różnica strukturalna, nie tylko konfiguracyjna.

Oto trzywarstwowa architektura.

Warstwa 1: Podpisane ciasteczka gateway (HMAC-SHA256)

Gdy uzyskujesz dostęp do swojej instancji OpenClaw przez panel OpenClaw.rocks, serwer generuje podpisane ciasteczko. Format to:

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

Ciasteczko ma TTL wynoszący 4 godziny i odświeża się automatycznie co 45 minut. Jest ograniczone do ścieżki /gw/{instanceId}, więc jedno ciasteczko nie może być użyte do uzyskania dostępu do innej instancji. Jest HttpOnly (JavaScript nie może go odczytać), Secure (wysyłane tylko przez HTTPS) i SameSite=Lax (nie wysyłane przy żądaniach cross-origin). HMAC jest weryfikowany za pomocą porównania stałoczasowego, aby zapobiec atakom czasowym.

Nawet jeśli ktoś przechwyci wartość ciasteczka, nie może sfałszować nowego bez sekretu podpisu. A samo ciasteczko nie zawiera danych uwierzytelniających, które dałyby bezpośredni dostęp do OpenClaw.

Warstwa 2: Traefik ForwardAuth

Każde żądanie do instancji OpenClaw przechodzi przez Traefik, nasz reverse proxy. Przed przekazaniem żądania Traefik wywołuje endpoint auth-gate, który weryfikuje podpisane ciasteczko.

To czysta weryfikacja HMAC. Zero wywołań bazy danych. Zero żądań sieciowych do Supabase ani żadnego innego serwisu. Decyzja jest podejmowana w mikrosekundach.

Jeśli ciasteczko jest nieprawidłowe, wygasłe lub brakuje go, żądanie jest odrzucane na warstwie proxy. Żądanie nigdy nie dociera do OpenClaw. To jest kluczowa różnica. W typowej konfiguracji to sam OpenClaw musi zdecydować, czy zezwolić na żądanie czy je odrzucić. Jeśli OpenClaw ma podatność w swojej logice uwierzytelniania, atakujący może się prześlizgnąć. W naszej konfiguracji OpenClaw nigdy nie widzi nieuwierzytelnionego ruchu.

Warstwa 3: Wstrzykiwanie tokenu gateway

Każda instancja OpenClaw ma wbudowany token gateway. To ten sam token, który skonfigurowałbyś samodzielnie przy self-hostingu. Różnica polega na tym, jak trafia do poda.

W typowej konfiguracji self-hostingowej wklejasz token do pliku konfiguracyjnego, może przechowujesz go w zmiennej środowiskowej i masz nadzieję, że nigdy nie wycieknie. Twoja przeglądarka musi go wysyłać przy każdym żądaniu, co jest dokładnie sposobem, w jaki CVE-2026-25253 go wyekstrahował.

W naszej konfiguracji kryptograficznie losowy 32-bajtowy token jest generowany przy tworzeniu instancji i przechowywany jako Kubernetes Secret. Traefik wstrzykuje go jako nagłówek Authorization przy każdym przekazanym żądaniu. Przeglądarka go nigdy nie widzi. Nigdy nie pojawia się w pliku konfiguracyjnym, który mógłbyś przypadkowo commitnąć. Nigdy nie podróżuje przez WebSocket, który złośliwa strona mogłaby przejąć. Token istnieje, ale żyje całkowicie wewnątrz klastra, przemieszczając się tylko między Traefikiem a podem.

Dlaczego ta architektura blokuje CVE-2026-25253

Łańcuch ataku CVE-2026-25253 eksfiltruje token gateway przez WebSocket. Przejdźmy przez to, co się dzieje, gdy ten atak jest skierowany na instancję OpenClaw.rocks:

  1. JavaScript atakującego próbuje otworzyć WebSocket do poda OpenClaw.
  2. Połączenie trafia najpierw do Traefika. Traefik sprawdza podpisane ciasteczko.
  3. Złośliwa strona jest na innym originie. Ciasteczko SameSite=Lax nie jest wysyłane przy połączeniach WebSocket cross-origin. Żądanie jest odrzucane.
  4. Nawet gdyby ciasteczko zostało jakoś dołączone, strona atakującego nie może go odczytać (HttpOnly). Nie ma nic do eksfiltracji.
  5. Nawet gdyby ciasteczko wyciekło, nie zawiera tokenu bearer. Token bearer jest wstrzykiwany przez Traefik, nigdy nieeksponowany przeglądarce. Atakujący nie może go odtworzyć.

Nie ma nic do kradzieży, ponieważ przeglądarka nigdy nie posiada prawdziwych danych uwierzytelniających. Powierzchnia ataku, którą CVE-2026-25253 eksploituje, po prostu nie istnieje.

Lista kontrolna bezpieczeństwa OpenClaw dla self-hosterów

Nie każdy chce hostingu zarządzanego, i to jest w porządku. Jeśli prowadzisz własną instancję OpenClaw, oto praktyczna lista kontrolna na 2026 rok.

Czy Twój token uwierzytelniania gateway jest włączony? Uruchom openclaw doctor, aby to sprawdzić. Jeśli uwierzytelnianie gateway jest wyłączone, każdy, kto może dotrzeć do portu 18789, kontroluje Twojego agenta i wszystko, do czego ma dostęp.

Czy Twoja instancja jest za reverse proxy z TLS? Niezaszyfrowane HTTP oznacza, że każdy na ścieżce sieciowej może odczytać Twój token gateway w tranzycie. Użyj nginx, Caddy lub Traefik z ważnym certyfikatem TLS. Let’s Encrypt jest darmowy.

Czy masz najnowszą wersję? CVE-2026-25253 została załatana w v2026.1.29. CVE-2026-27001 została załatana w v2026.2.15. Jeśli używasz starszej wersji, zaktualizuj teraz. Przewodnik hardeningu Adversa AI obejmuje dodatkowe kroki.

Czy przeprowadziłeś audyt zainstalowanych skilli? Kampania ClawHavoc celowała konkretnie w ClawHub. Sprawdź każdy skill, który zainstalowałeś. Jeśli nie zainstalowałeś go samodzielnie, usuń go i zweryfikuj źródło.

Czy Twój reverse proxy waliduje originy WebSocket? To jest konkretny wektor, który eksploitował CVE-2026-25253. Twój reverse proxy powinien odrzucać żądania upgrade WebSocket z nieoczekiwanych originów. Dokumentacja bezpieczeństwa OpenClaw zawiera przykłady konfiguracji.

Czy Twoje uwierzytelnianie odbywa się przed czy po dotarciu żądania do OpenClaw? To jest pytanie, które ma największe znaczenie. Jeśli OpenClaw obsługuje własne uwierzytelnianie, podatność w OpenClaw może je ominąć. Jeśli Twój reverse proxy obsługuje uwierzytelnianie, żądanie nigdy nie dociera do OpenClaw, chyba że jest już zweryfikowane.

Czego nie rozwiązujemy

Uczciwość jest tu ważna. Uwierzytelnianie na poziomie proxy rozwiązuje bezpieczeństwo gateway. Nie rozwiązuje wszystkiego.

Prompt injection to problem na poziomie aplikacji. Sprytnie sformułowana wiadomość może potencjalnie nakłonić agenta do wykonania niezamierzonych działań. To aktywny obszar badań w całej branży AI i żaden dostawca hostingu nie może tego dziś w pełni zapobiec.

Złośliwe zachowanie skilli odbywa się w kontekście agenta. Jeśli zainstalujesz skill, który eksfiltruje dane przez dozwolony ruch wychodzący HTTPS, uwierzytelnianie proxy nie może tego powstrzymać. To, co nasza infrastruktura robi, to ograniczanie promienia rażenia: każda instancja działa w swoim własnym podzie Kubernetes z izolacją sieci, usuniętymi capabilities, seccomp i systemem plików root tylko do odczytu. Skompromitowany agent nie może dotrzeć do innych agentów ani systemu hosta. Operator Kubernetes wymusza te domyślne ustawienia dla każdej instancji.

Zaufanie do dostawcy LLM zależy od Twojego planu. Jeśli używasz własnych kluczy API (plan Light), Twoje rozmowy przechodzą przez dostawcę, którego skonfigurujesz, i obowiązuje jego polityka prywatności. W planie Pro kierujemy ruch przez nasz własny gateway AI z wstępnie skonfigurowanymi dostawcami. Nie musisz przekazywać swoich kluczy API instancji OpenClaw ani ufać, że klucz strony trzeciej jest bezpiecznie przechowywany. Gateway zarządza danymi uwierzytelniającymi dostawców w Twoim imieniu, a Ty nigdy ich nie widzisz ani nie obsługujesz bezpośrednio.

Bezpieczeństwo to warstwy. My zajmujemy się warstwami infrastruktury. Wyzwania na poziomie aplikacji są realne i warte zrozumienia.

Bezpieczeństwo to decyzja architektoniczna

Kryzys bezpieczeństwa OpenClaw nie dotyczy jednego CVE ani jednej partii złośliwych skilli. Dotyczy narzędzia zaprojektowanego dla localhost, które jest wdrażane w Internecie przez setki tysięcy ludzi, z uwierzytelnianiem, które odbywa się wewnątrz aplikacji, którą ma chronić.

Przeniesienie uwierzytelniania na warstwę proxy to nie funkcjonalność. To decyzja architektoniczna. Oznacza, że gdy pojawi się kolejny CVE OpenClaw (a pojawi się), uwierzytelnione żądania będą nadal weryfikowane przed dotarciem do aplikacji. Powierzchnia ataku jest strukturalnie mniejsza.

Podjęliśmy tę decyzję pierwszego dnia. Każda instancja OpenClaw.rocks działa za podpisanymi ciasteczkami, weryfikacją ForwardAuth i tokenami bearer per instancja. Żadnych tokenów gateway w przeglądarce. Żadnych statycznych danych uwierzytelniających do eksfiltracji. Żadnej logiki uwierzytelniania wewnątrz podatnej aplikacji.

Jeśli chcesz przeczytać więcej o tym, jak wdrażamy OpenClaw na Kubernetes z pełnym hardeningiem bezpieczeństwa, przewodnik wdrożeniowy opisuje to szczegółowo.

Jeśli po prostu chcesz działającego agenta, który pozostaje bezpieczny bez myślenia o tym wszystkim, właśnie to zbudowaliśmy.

Zacznij na OpenClaw.rocks lub poznaj open-source’owy operator Kubernetes, jeśli wolisz zarządzać własną infrastrukturą.