TL;DR: Zidentyfikowano cztery luki w platformie do zarządzania środowiskami cyfrowymi OpenClaw. Połączone w łańcuch ataku nazwany „Claw Chain” [^1], pozwalają na ominięcie piaskownicy, kradzież danych, eskalację uprawnień i trwałe przejęcie kontroli nad systemem [^2]. Dostawca udostępnił już poprawioną wersję oprogramowania [^3].

[CALLOUT] “W skrócie: Jeśli używasz OpenClaw, Twoja instancja może być podatna na zdalne przejęcie. Atak jest trudny do wykrycia, ponieważ jego kroki maskują się jako normalne operacje agenta [^4]. Priorytetem jest natychmiastowa aktualizacja do wersji 2026.4.22 [^3].”

Wektor ataku

Badacze z firmy Cyera ujawnili zestaw czterech podatności w oprogramowaniu OpenClaw [^5], które mogą być wykorzystane sekwencyjnie do przeprowadzenia złożonego ataku [^2]. Łańcuch, nazwany „Claw Chain” [^1], pozwala operatorowi na eskalację od początkowego, ograniczonego wykonania kodu do pełnej i trwałej kontroli nad hostem [^6].

Analiza wskazuje na czterostopniowy proces [^7]:

Krok 1: Początkowe wykonanie kodu w piaskownicy

Atak rozpoczyna się od uzyskania możliwości wykonania kodu wewnątrz piaskownicy OpenShell, która jest częścią platformy OpenClaw. Wektor początkowy może być różny — złośliwa wtyczka, atak typu prompt injection lub przetworzenie skompromitowanych danych z zewnętrznego źródła [^8]. Na tym etapie operator ma ograniczone możliwości, działając w izolowanym środowisku.

Krok 2: Wykradanie danych i rekonesans

Po uzyskaniu przyczółka w piaskownicy, atakujący wykorzystuje dwie luki do przełamania izolacji i odczytania wrażliwych danych z systemu hosta.

  • CVE-2026-44115: Luka w walidacji danych wejściowych, która pozwala na ominięcie listy dozwolonych poleceń. Operator może osadzić tokeny rozszerzenia powłoki w dokumencie typu heredoc, aby wykonać niezatwierdzone komendy w czasie działania systemu [^9].
  • CVE-2026-44113: Luka typu race condition (Time-of-Check to Time-of-Use, czyli błąd wynikający z odstępu czasu między sprawdzeniem warunku a jego użyciem) w OpenShell. Pozwala ona na ominięcie ograniczeń piaskownicy i odczyt plików spoza zamierzonego katalogu [^10].

Połączenie tych dwóch podatności może umożliwić odczyt plików systemowych, poświadczeń, kluczy API i innych wewnętrznych artefaktów systemu [^11] [^12].

Krok 3: Eskalacja uprawnień do poziomu właściciela

Zdobytą wiedzę operator wykorzystuje do eskalacji uprawnień. Służy do tego luka CVE-2026-44118, czyli niewłaściwa kontrola dostępu [^13]. Problem leży w tym, że OpenClaw ufało kontrolowanej przez klienta fladze senderIsOwner bez weryfikacji jej z uwierzytelnioną sesją [^14]. W rezultacie klient bez uprawnień mógł podszyć się pod właściciela, zyskując kontrolę nad konfiguracją bramy, harmonogramem zadań (cron) i zarządzaniem całym środowiskiem wykonawczym [^13] [^15].

Krok 4: Ustanowienie trwałości (persistence)

Ostatnim krokiem jest zapewnienie sobie stałego dostępu do skompromitowanego systemu. Operator wykorzystuje do tego najpoważniejszą z luk, CVE-2026-44112. Jest to kolejna podatność typu TOCTOU (race condition) w backendzie piaskownicy OpenShell [^16]. Pozwala ona na ominięcie zabezpieczeń i przekierowanie operacji zapisu plików poza dozwolony katalog [^16].

Wykorzystując tę lukę, atakujący może modyfikować konfigurację, instalować backdoory lub inne złośliwe oprogramowanie, zapewniając sobie trwałą kontrolę nad maszyną [^6] [^17]. Co istotne, według analizy Cyera, poszczególne kroki ataku mogą wyglądać jak normalne, autoryzowane działania agenta OpenClaw, co znacząco utrudnia ich wykrycie przez standardowe systemy monitoringu [^4].

Wskaźniki kompromitacji

Na chwilę obecną nie opublikowano publicznie wskaźników kompromitacji (IoC — Indicators of Compromise, takich jak hashe plików czy adresy IP). Zespoły bezpieczeństwa powinny skupić się na analizie behawioralnej i logów systemowych.

Zalecamy poszukiwanie następujących anomalii w logach OpenClaw i systemów operacyjnych hostów:

  • Nietypowe operacje odczytu plików spoza standardowych ścieżek przez procesy OpenShell (potencjalne wykorzystanie CVE-2026-44113).
  • Wykonywanie poleceń powłoki zawierających nietypowe tokeny rozszerzeń, zwłaszcza w kontekście dokumentów heredoc (potencjalne wykorzystanie CVE-2026-44115).
  • Logi wskazujące na zmiany w konfiguracji, harmonogramie cron lub zarządzaniu środowiskiem przez sesje, które nie powinny mieć uprawnień właściciela (potencjalne wykorzystanie CVE-2026-44118).
  • Nieoczekiwane operacje zapisu plików w krytycznych katalogach systemowych (np. /etc, /usr/bin, C:\Windows\System32) inicjowane przez procesy OpenClaw (potencjalne wykorzystanie CVE-2026-44112).

Co zrobić w 24-48h

Rekomendowane podejście nie zastępuje pełnej analizy incydentu, ale stanowi pierwszy krok w celu ograniczenia ryzyka.

  1. Natychmiastowa aktualizacja: Priorytetem jest aktualizacja wszystkich instancji OpenClaw do wersji 2026.4.22 lub nowszej [^3]. Jest to jedyny skuteczny sposób na załatanie wszystkich czterech opisanych luk [^18]. Dostawca poinformował, że w nowej wersji m.in. wprowadzono oddzielne tokeny dla właściciela i użytkownika, a flaga senderIsOwner jest teraz weryfikowana po stronie serwera [^19].

  2. Threat Hunting: Należy założyć, że jeśli system był publicznie dostępny, mogło dojść do kompromitacji. Zespoły SOC (Security Operations Center) powinny aktywnie przeszukać logi systemowe i aplikacyjne pod kątem opisanych wyżej wskaźników behawioralnych za okres co najmniej ostatnich 30 dni.

  3. Weryfikacja konfiguracji i integralności: Po aktualizacji należy przeprowadzić audyt konfiguracji instancji OpenClaw. Sprawdź harmonogramy zadań (cron), reguły bramy oraz integralność kluczowych plików systemowych na hoście w poszukiwaniu nieautoryzowanych modyfikacji lub backdoorów.

  4. Kontekst polski i NIS2: Dla polskich firm, zwłaszcza podmiotów kluczowych i ważnych w rozumieniu dyrektywy NIS2, incydent ten jest przypomnieniem o konieczności utrzymywania reżimu aktualizacji. Posiadanie niezałatanej platformy z lukami o wysokiej krytyczności może stanowić naruszenie podstawowych zasad higieny cyfrowej wymaganych przez nowe regulacje.

Atrybucja

Zestaw podatności „Claw Chain” został zidentyfikowany i zgłoszony w ramach procedury responsible disclosure przez badacza bezpieczeństwa Vladimira Tokareva [^20]. Nazwę oraz szczegółową analizę łańcucha ataku opublikowała firma cyberbezpieczeństwa Cyera [^1].

Zobacz też