Ataki wykorzystują agenta OpenClaw AI

Najnowsze badania bezpieczeństwa ujawniły, że OpenClaw, powszechnie używana platforma agentów AI hostowana samodzielnie, może zostać zmanipulowana w celu wykonywania działań kontrolowanych przez atakujących lub ujawniania poufnych informacji za pomocą pozornie nieszkodliwych danych wejściowych.

W niezależnych badaniach badacze zademonstrowali dwie różne metody ataku. Jedna polegała na umieszczaniu ukrytych instrukcji w udostępnionych kontaktach, wizytówkach vCard i pinezkach lokalizacji. Druga wykorzystywała starannie spreparowane wiadomości e-mail phishingowe, aby przekonać agenta AI do ujawnienia poufnych informacji biznesowych.

Mimo że OpenClaw w wersji 2026.4.23 usunął jedną z tych luk, szerszy problem pozostaje niezmieniony: agenci AI, którzy ufają przychodzącym informacjom, mogą stać się potężnym narzędziem dla atakujących.

Niewidoczne polecenia ukryte na widoku

Pierwszy atak miał na celu zbadanie sposobu, w jaki OpenClaw przetwarza pewne obiekty wiadomości przed wysłaniem ich do bazowego modelu dużego języka (LLM).

W przeciwieństwie do treści internetowych, które są wyraźnie oznaczane jako niezaufane przed dotarciem do modelu, rekordy kontaktów, wizytówki vCard i etykiety lokalizacji były wstawiane bezpośrednio do monitów, bez żadnego wskazania, że pochodzą z niezaufanych źródeł. Stworzyło to okazję do szybkiego wstrzyknięcia.

Atak wykorzystywał sposób serializacji danych kontaktowych przez OpenClaw. Udostępnione kontakty były konwertowane do prostego formatu zawierającego jedynie imię i nazwisko oraz numer telefonu. Ponieważ w nazwach kontaktów dozwolone są znaki takie jak nawiasy kątowe, atakujący mogli osadzać złośliwe instrukcje, które wyglądały na część danych kontaktowych. Ponadto nazwy kontaktów są często skracane w komunikatorach, uniemożliwiając ofiarom dostrzeżenie ukrytego ładunku.

Ta sama technika okazała się skuteczna w przypadku pól pełnych nazw vCard i współdzielonych etykiet lokalizacji. Podczas testów z kompilacjami zapoznawczymi Gemini 3.1 Pro, ukryte instrukcje skutecznie przekonały agenta do pobrania i wykonania kodu z serwera kontrolowanego przez badacza. Co ciekawe, próby ukrycia instrukcji w obrazach zakończyły się niepowodzeniem, prawdopodobnie dlatego, że współczesne modele sztucznej inteligencji przeszły intensywne szkolenie w zakresie ataków typu prompt injection opartych na obrazach. Ataki typu message-object pozostają jednak mniej znane obecnym modelom.

Naukowcy ostrzegali, że domyślna funkcjonalność pamięci OpenClaw może nasilić zagrożenie. Pojedynczy złośliwy kontakt lub szeroko rozpowszechniony obiekt współdzielony może potencjalnie narazić na atak wielu agentów, jeśli nie zostaną zastosowane odpowiednie zabezpieczenia sandboxingowe.

Po ujawnieniu informacji OpenClaw wydał wersję 2026.4.23, która oddziela nazwy kontaktów, pola vCard i etykiety lokalizacji od treści komunikatów, umieszczając je w dedykowanym, niezaufanym kanale metadanych. Badacze zauważyli również, że podobne wzorce projektowe pojawiły się w innych osobistych asystentach AI, co wskazuje na wyzwanie dla całej branży, a nie na problem specyficzny dla danej platformy.

Wzrost liczby agentów phishingowych

Drugi projekt badawczy podszedł do problemu z innej perspektywy: stosując inżynierię społeczną.

Naukowcy zbudowali agenta testowego o nazwie Pinchy i połączyli go ze skrzynką odbiorczą Gmaila, wypełnioną realistycznymi, ale syntetycznymi wiadomościami biznesowymi i pozornie poufnymi danymi. Następnie zespół przeprowadził cztery symulacje phishingu, korzystając z Google Gemini 3.1 Pro i OpenAI Codex GPT-5.4.

Badanie odróżniało tradycyjne ataki typu instant injection od tego, co badacze określali mianem „phishingu agentowego”. Podczas gdy instant injection ukrywa złośliwe instrukcje w danych, phishing agentowy opiera się na wiarygodnych żądaniach przesyłanych legalnymi kanałami komunikacji. Atak jest skuteczny, ponieważ agent podejmuje działanie, zanim odpowiednio zweryfikuje tożsamość nadawcy.

Jak inżynieria społeczna pokonała kontrolę bezpieczeństwa

Symulacje phishingu przyniosły niepokojące rezultaty. Pomimo działania zgodnie ze ścisłymi instrukcjami weryfikacji tożsamości nadawcy, agent nie zrealizował dwóch scenariuszy eksfiltracji danych:

Fałszywy e-mail podszywający się pod lidera zespołu prosił o dostęp do środowiska testowego podczas sfabrykowanego incydentu produkcyjnego. Agent zlokalizował i przesłał fałszywe dane uwierzytelniające AWS IAM, ciągi połączeń z bazą danych oraz dane uwierzytelniające SSH w postaci zwykłego tekstu.

W drugim e-mailu poproszono o rutynowy, cotygodniowy eksport danych klientów na potrzeby kwartalnej prezentacji przeglądu działalności. Agent przesłał syntetyczną bazę danych zawierającą informacje o 247 klientach korporacyjnych, w tym dane kontaktowe i wartości umów.

Agent radził sobie znacznie lepiej w przypadku ataków technicznych. Rozpoznawał podejrzane witryny phishingowe, unikał ujawniania prawidłowych danych uwierzytelniających i ostatecznie sygnalizował złośliwą aktywność. Przy bardziej rygorystycznych ustawieniach dostęp do stron phishingowych był całkowicie blokowany. Po wyświetleniu fałszywego ekranu akceptacji OAuth podszywającego się pod aplikację do ewidencji czasu pracy, agent przeanalizował miejsce przekierowania, uznał je za podejrzane i odmówił udzielenia uprawnień.

Badacze doszli do wniosku, że agent często przewyższał ludzi w identyfikowaniu złośliwych adresów URL i fałszywych portali logowania. Miał jednak problemy z kontekstową oceną społeczną, szczególnie gdy prośby wydawały się pochodzić od zaufanych współpracowników. Ta sama cecha, która sprawia, że asystenci AI są użyteczni – chęć niesienia pomocy – stwarza również istotną powierzchnię ataku.

Chociaż OpenAI Codex GPT-5.4 wykazał się większą ostrożnością niż Gemini 3.1 Pro podczas interakcji z zewnętrznymi witrynami lub przesyłania informacji, ostatecznie oba systemy padły ofiarą ataków socjotechnicznych.

Jedna przyczyna, wiele ścieżek ataku

Mimo że oba ataki wykorzystywały różne techniki, wykorzystywały te same podstawowe możliwości:

• Dostęp do informacji prywatnych.

• Możliwość przetwarzania niezaufanych treści.

• Zezwolenie na przesyłanie informacji na zewnątrz.

Gdy te możliwości współistnieją bez odpowiednich środków kontroli, złośliwa wizytówka i przekonujący e-mail phishingowy mogą mieć ten sam skutek: nieautoryzowany dostęp do poufnych danych.

Dalsze badania ujawniły podobne problemy z granicami zaufania w ekosystemie OpenClaw. Przekształcając wcześniejsze ostrzeżenia bezpieczeństwa w reguły analizy statycznej, badacze zidentyfikowali pięć kolejnych luk w zabezpieczeniach wpływających na integrację ze Slackiem, Discordem, Matrixem, Zalo i Microsoft Teams.

Każda luka wynikała z tej samej wady projektowej. Rozszerzenia kanałów opierały się na zmiennych nazwach wyświetlanych zamiast stałych identyfikatorów podczas oceny list dozwolonych. Atakujący mógł zatem zmienić nazwę konta, aby pasowała do zatwierdzonego użytkownika i uzyskać wpływ na agenta. Od tego czasu OpenClaw załatał wszystkie zidentyfikowane problemy.

Rosnące obawy dotyczące szerokich uprawnień agentów

Od momentu premiery OpenClaw był poddawany krytyce ze względu na swoje rozbudowane uprawnienia. Platforma zapewnia dostęp do plików lokalnych, środowisk powłoki i ponad dwudziestu platform komunikacyjnych, co czyni ją niezwykle wydajną, ale jednocześnie bardzo podatną na ataki.

Obawy stały się na tyle poważne, że holenderski urząd ochrony danych osobowych (Autoriteit Persoonsgegevens) odradził osobom prywatnym i organizacjom wdrażanie OpenClaw w systemach zawierających poufne informacje. Urząd wskazał na zagrożenia, takie jak wycieki danych i włamanie na konta.

Budowanie bezpieczniejszych wdrożeń agentów AI

Organizacje korzystające z OpenClaw powinny natychmiast zaktualizować system do wersji 2026.4.23 lub nowszej, aby wyeliminować lukę w zabezpieczeniach obiektów komunikatów. Jednak, poza łataniem, długoterminowa ochrona zależy od kontroli architektonicznych, a nie od szybkiej inżynierii.

Specjaliści ds. bezpieczeństwa zalecają traktowanie plików instrukcji agentów jako egzekwowalnych, kontrolowanych wersji zasad, a nie jedynie jako wskazówek doradczych. Komunikacja wychodząca powinna wymagać zatwierdzenia przed wysłaniem wiadomości do nieznanych odbiorców, zmniejszając tym samym prawdopodobieństwo, że zainfekowani agenci będą rozprzestrzeniać ataki za pośrednictwem zaufanych kont. Uprawnienia dostępu powinny być również powiązane z wiarygodnością źródła ataku, co uniemożliwi agentom przetwarzającym komunikację zewnętrzną automatyczny dostęp do systemów o wysokiej wartości, takich jak platformy zarządzania relacjami z klientami. Działania wysokiego ryzyka, takie jak udostępnianie danych uwierzytelniających i transakcje finansowe, powinny nadal podlegać zatwierdzeniu przez człowieka.

Nierozwiązane wyzwanie zaufania autonomicznego

Oba zespoły badawcze ostatecznie doszły do tego samego wniosku: agentów AI nie należy postrzegać jako narzędzi bezpieczeństwa. Bardziej trafnym modelem jest model młodszego pracownika z szerokim dostępem do systemu, ale ograniczoną zdolnością do rozpoznawania podejrzanych zachowań. Inną użyteczną perspektywą jest postrzeganie ich jako uwierzytelnionych wykonawców, którzy z natury ufają otrzymywanym informacjom.

Obecne środki zaradcze koncentrują się na poprawkach, zabezpieczeniach i kontroli dostępu. Jednak szersze wyzwanie pozostaje nierozwiązane. Agent AI zdolny do odczytywania wiadomości e-mail, wykonywania zadań i działania niezależnie musi, z założenia, ufać danym wejściowym i starać się pomagać użytkownikom. Społeczność zajmująca się cyberbezpieczeństwem nie wypracowała jeszcze uniwersalnego rozwiązania tego fundamentalnego napięcia.