Cztery luki w OpenClaw pozwalają na kradzież danych, eskalację uprawnień i trwałe utrzymanie dostępu

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

W połowie maja 2026 roku ujawniono zestaw czterech podatności w platformie OpenClaw, które mogą zostać połączone w jeden skuteczny łańcuch ataku. Problemy obejmują mechanizmy izolacji sandboxa, walidację poleceń oraz kontrolę uprawnień w środowisku uruchomieniowym agenta AI. W praktyce oznacza to, że naruszenie jednego punktu wejścia może doprowadzić do odczytu wrażliwych danych, przejęcia wyższych uprawnień, a następnie utrzymania trwałej obecności w środowisku.

Sprawa jest szczególnie istotna dla organizacji korzystających z agentów AI zintegrowanych z systemami plików, komunikatorami, usługami SaaS i wewnętrzną infrastrukturą. Tego typu platformy często operują na sekretach, tokenach i danych biznesowych, dlatego ich kompromitacja może mieć znacznie szersze skutki niż pojedynczy incydent aplikacyjny.

W skrócie

Badacze opisali cztery podatności: CVE-2026-44112, CVE-2026-44113, CVE-2026-44115 oraz CVE-2026-44118. Dwie z nich dotyczą błędów TOCTOU przy operacjach odczytu i zapisu plików w sandboxie OpenShell, jedna pozwala ominąć mechanizm allowlisty poleceń, a ostatnia umożliwia eskalację uprawnień przez błędne zaufanie do flagi właściciela sesji.

CVE-2026-44112: obejście granic sandboxa podczas zapisu plików
CVE-2026-44113: odczyt plików spoza dozwolonego obszaru
CVE-2026-44115: ujawnienie sekretów przez obejście walidacji poleceń
CVE-2026-44118: eskalacja uprawnień do kontekstu właściciela

Wszystkie błędy zostały poprawione w wersji OpenClaw 2026.4.22. Ich połączenie pozwala przejść od wykonania kodu w sandboxie do eksfiltracji danych, przejęcia kontroli nad agentem i ustanowienia trwałego dostępu.

Kontekst / historia

OpenClaw to samohostowana platforma łącząca agentów AI z zewnętrznymi usługami, środowiskami wykonawczymi, systemem plików oraz kanałami komunikacji. Z perspektywy operacyjnej to rozwiązanie wygodne, ale z perspektywy bezpieczeństwa tworzy nową i złożoną powierzchnię ataku. Agent może bowiem przetwarzać dane z wielu źródeł, wykonywać polecenia oraz korzystać z poświadczeń o szerokim zakresie dostępu.

Według ujawnionych informacji podatności zgłoszono producentowi w kwietniu 2026 roku, poprawki opublikowano 23 kwietnia 2026 roku, a publiczne omówienie zagrożenia pojawiło się 15 maja 2026 roku. Dodatkowo wskazano, że podatne instancje były szeroko eksponowane w internecie, co podnosi znaczenie ryzyka dla środowisk produkcyjnych.

Analiza techniczna

Najpoważniejsza luka, CVE-2026-44112, dotyczy operacji zapisu w sandboxie OpenShell. To klasyczny błąd typu time-of-check/time-of-use, w którym ścieżka pliku zostaje uznana za bezpieczną podczas walidacji, ale między sprawdzeniem a faktycznym zapisem może zostać podmieniona, na przykład przy użyciu dowiązania symbolicznego. W efekcie zapis może trafić poza dozwolony katalog, co umożliwia modyfikację konfiguracji i ustanowienie trwałości.

Druga luka, CVE-2026-44113, wykorzystuje podobny mechanizm, ale w ścieżce odczytu. Atakujący może uzyskać dostęp do plików znajdujących się poza zakładanymi granicami sandboxa, w tym do konfiguracji, sekretów, poświadczeń lub innych zasobów, które nie powinny być dostępne dla procesu agenta.

CVE-2026-44115 dotyczy niepełnej walidacji wejścia w mechanizmie kontroli dozwolonych poleceń. Problem wynika z użycia niecytowanych heredoców i ekspansji powłoki, co może prowadzić do ujawnienia zmiennych środowiskowych w czasie wykonania polecenia. W praktyce umożliwia to pozyskanie tokenów API, sekretów i innych wrażliwych danych mimo wcześniejszego przejścia przez kontrolę składniową.

Z kolei CVE-2026-44118 to błąd kontroli dostępu w lokalnym mechanizmie loopback. Jego istotą jest zaufanie do atrybutu informującego, czy nadawca jest właścicielem sesji, bez poprawnego powiązania tej informacji z rzeczywiście uwierzytelnionym kontekstem. W efekcie lokalny proces z prawidłowym tokenem może podszyć się pod właściciela i przejąć kontrolę nad ustawieniami gatewaya, harmonogramami oraz środowiskiem wykonawczym.

Największe zagrożenie wynika z możliwości łączenia tych luk. Scenariusz ataku może rozpocząć się od złośliwej wtyczki, podatności typu prompt injection lub innego skompromitowanego wejścia prowadzącego do wykonania kodu w sandboxie. Następnie napastnik odczytuje pliki i sekrety, przejmuje uprawnienia właścicielskie, a na końcu wykorzystuje lukę zapisu do trwałego osadzenia zmian w środowisku.

Konsekwencje / ryzyko

Ryzyko dla organizacji należy ocenić jako wysokie. Agenty AI coraz częściej działają jako pośrednicy między użytkownikami a krytycznymi systemami wewnętrznymi, a ich aktywność może wyglądać jak legalne operacje biznesowe. To utrudnia detekcję i wydłuża czas wykrycia naruszenia.

Potencjalne skutki obejmują wyciek kluczy API, tokenów bearer, plików konfiguracyjnych, danych użytkowników, historii interakcji, kodu źródłowego oraz dokumentacji. W środowiskach regulowanych zagrożone mogą być również dane osobowe, dane medyczne i informacje objęte tajemnicą zawodową. Szczególnie narażone są wdrożenia dostępne publicznie oraz środowiska, w których agent ma szerokie uprawnienia do usług SaaS i zasobów korporacyjnych.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja OpenClaw do wersji 2026.4.22 lub nowszej. Organizacje powinny jednocześnie założyć, że sekrety dostępne dla procesu agenta mogły zostać ujawnione, dlatego konieczna jest rotacja tokenów, kluczy API i innych poświadczeń.

Zidentyfikować wszystkie instancje OpenClaw, zwłaszcza wystawione do internetu
Ograniczyć ekspozycję sieciową przez uwierzytelnianie, filtrowanie ruchu i segmentację
Zminimalizować uprawnienia agentów AI zgodnie z zasadą najmniejszych uprawnień
Ograniczyć dostęp agentów do sekretów i usług tylko do niezbędnego minimum
Monitorować anomalie w dostępie do plików, zmianach konfiguracji i tworzeniu mechanizmów trwałości
Przeprowadzić przegląd wtyczek, integracji i źródeł danych wykorzystywanych przez agentów

Warto również wdrożyć bardziej szczegółowe logowanie operacji wykonywanych przez agentów, tak aby możliwe było rozróżnienie między legalnym workflow a sekwencjami sugerującymi nadużycie lub próbę eskalacji uprawnień.

Podsumowanie

Przypadek OpenClaw pokazuje, że bezpieczeństwo agentów AI nie może opierać się wyłącznie na deklaratywnej izolacji sandboxa i prostych mechanizmach filtrowania poleceń. Gdy agent ma dostęp do systemu plików, sekretów i integracji biznesowych, pojedyncze błędy logiczne mogą stać się elementami pełnego łańcucha kompromitacji.

Cztery opisane luki tworzą modelowy scenariusz wieloetapowego ataku: od wejścia przez zewnętrzne dane, przez wyciek informacji i eskalację uprawnień, aż po trwałe utrzymanie dostępu. Dla zespołów bezpieczeństwa to wyraźny sygnał, że infrastruktura agentowa wymaga takiego samego rygoru ochrony jak systemy uprzywilejowane i inne krytyczne elementy architektury IT.