Clawdbot: setki instancji narażonych na wyciek

Projekt agenta AI o nazwie Clawdbot zyskał ogromną popularność w bardzo krótkim czasie. Na GitHubie zdobył tysiące gwiazdek, a twórcy reklamowali go jako „AI, która naprawdę wykonuje zadania”.

Użytkownicy masowo instalowali agenta na swoich urządzeniach, powierzając mu prywatne dane. Niedługo po publikacji narzędzia badacze bezpieczeństwa zaczęli zwracać uwagę na liczne podatności, o których informowali w kolejnych analizach i postach.

Jak działa Clawdbot?

Clawdbot nie jest zwykłym chatbotem. To agent AI połączony z lokalnym oprogramowaniem użytkownika, działający w modelu self-hosted. Agent AI to system sztucznej inteligencji, który nie tylko odpowiada na pytania, ale także samodzielnie wykonuje zadania, podejmuje decyzje na podstawie kontekstu i ma dostęp do zasobów systemowych, takich jak pliki czy aplikacje.

Problemy z bezpieczeństwem narzędzia

Niestety, bezpieczeństwo agenta AI od początku było poważnym wyzwaniem. Clawdbot posiada poważne podatności, które mogą narazić użytkowników na wyciek danych, a nawet przejęcie systemów.

Badacze bezpieczeństwa opublikowali ciekawe znaleziska na platformie X. Jednym z nich był użytkownik Jamieson O’Reilly, który opisał problem w wątku opublikowanym 23 stycznia 2026 r. Zwrócił w nim uwagę na błędne konfiguracje w bramie agentów AI.

O’Reilly wykorzystał wyszukiwarkę Shodan do wyszukiwania instancji panelu Control UI. Odkrył w ten sposób setki publicznie dostępnych instancji.

Skan za pomocą Shodana ujawnił ponad 900 publicznie dostępnych instancji bramek Clawdbot pozbawionych mechanizmów uwierzytelniania, działających na standardowych portach sieciowych. Oznacza to, że każdy użytkownik internetu mógł uzyskać dostęp do danych, a nawet je odczytywać lub modyfikować.

Mechanizm autoryzacji w Clawdbot domyślnie ufa połączeniom lokalnym localhost). Gdy użytkownik przesyła ruch przez reverse proxy (np. nginx), cały ruch może wyglądać dla systemu jak połączenie lokalne, co prowadzi do obejścia zabezpieczeń i umożliwia pełny dostęp do panelu sterowania i API bez hasła. Nawet jeśli portal był uwierzytelniony, wiele instancji ujawniało:

• klucze do usług LLM (Anthropic Claude, OpenAI),
• tokeny do komunikatorów (Telegram, Slack, WhatsApp),
• pliki z historią konwersacji,
• możliwość wykonywania poleceń systemowych na hostowanej maszynie.

W skrajnych przypadkach atakujący uzyskiwał uprawnienia do wykonania kodu („remote code execution”) z pełnymi prawami użytkownika lub nawet roota.

Uprawnienia agentów

Problem Clawdbota leży jednak głębiej. To nie kwestia samego błędnego skonfigurowania, a naszego podejścia do korzystania z technologii AI i zaufania jakie pokładamy w narzędzia sztucznej inteligencji.

• Po pierwsze, Clawdbot z założenia ma bardzo szerokie uprawnienia. Może czytać prywatne wiadomości, zarządzać tokenami i wykonywać systemowe polecenia, aby faktycznie pełnić rolę asystenta. Takie uprawnienia są wysoko w hierarchii zaufania, co znacząco zwiększa ryzyko, jeśli agent zostanie przejęty. Może być przydatny w codziennych zadaniach, ale czy powinniśmy mu pozwalać na, na przykład, czatowanie z naszymi bliskimi?

• Po drugie granice zaufania w tym przypadku zostają mocno zatarte. Systemy bezpieczeństwa klasycznie opierają się na zasadzie least privilege (dostarczaniu tylko niezbędnych uprawnień). Ta architektura łamie tę zasadę, ponieważ agent działa stale i ma szerokie możliwości. W efekcie z jednej strony zabezpieczamy swoje konta wieloskładnikowym uwierzytelnianiem i restrykcyjnymi politykami dostępu, a z drugiej oddajemy nielimitowany dostęp do prywatnych dokumentów agentowi AI wystawionemu bezpośrednio do sieci.

Dodatkowo sam sposób przetwarzania treści przez LLM sprawia, że system jest podatny na prompt injection, czyli atak polegający na wprowadzaniu złośliwych instrukcji do treści (np. w e-mailu), które agent może błędnie potraktować jako polecenie. W praktyce oznacza to, że nawet sama treść wysyłana do agenta może prowadzić doniezamierzonych działań lub ujawnienia wrażliwych danych.

Czy Clawdbot można używać bezpiecznie?

Oficjalna dokumentacja sugeruje pewne praktyki bezpieczeństwa, jak na przykład ograniczenie dostępu, kontrolę uprawnień i monitoring logów, ale w praktyce wiele instancji użytkowników nie stosowało się do tych zasad i było uruchamianych „od razu do sieci”. Clawdbota zdecydowanie bezpieczniej używać w środowisku odizolowanym, takim jak dedykowany serwer czy sandbox. Nie oznacza to, że narzędzie nie jest dostępne dla zwykłych użytkowników, ale warto pamiętać o potencjalnych zagrożeniach wynikających z błędnie skonfigurowanych instancji.