Infrastruktura AI jest bardziej podatna niż cokolwiek innego co kiedykolwiek zbadaliśmy. Mamy teraz liczby.

Pod koniec marca 2026 roku zespół Intruder opublikował wyniki skanowania ponad dwóch milionów hostów z infrastrukturą AI. Jedno zdanie z raportu opisuje wynik: "The AI infrastructure we researched is more vulnerable, exposed, open, and misconfigured on average than any other software we've ever investigated."

To jest firma specjalizująca się w testach penetracyjnych która przez lata skanowała każdą kategorię oprogramowania. Powiedziała że infrastruktura AI jest gorsza niż wszystko inne. Łącznie.

Przez kwiecień cyberflux opisywał pięć frameworków AI z krytycznymi podatnościami — Marimo, SGLang, LMDeploy, LiteLLM, Flowise. Intruder dostarcza teraz kontekst statystyczny który pokazuje że te incydenty to były widoczne czubki znacznie większego problemu.

Liczby z skanowania

Spośród ponad 2 milionów hostów z około milionem wystawionych usług:

1 652 API Ollama wystawione bez żadnego uwierzytelnienia z ponad 5 200 wystawionych na internet. Ollama to silnik do uruchamiania lokalnych modeli językowych — każde wystawione API daje pełny dostęp do modelu i wszystkich danych które przetwarza.

2 650+ instancji Flowise wystawionych na internet. Pisaliśmy o Flowise CVE-2025-59528 z wynikiem CVSS 10.0 — 92 z tych instancji eksponowały przepływy agentowe, prompty i integracje bez żadnej ochrony.

12 000+ instancji Open WebUI wystawionych na internet — 24 bez jakiegokolwiek uwierzytelnienia.

25 instancji Langflow bez uwierzytelnienia z ponad 300 wystawionych. Langflow to platforma IBM do budowania aplikacji AI — ta sama którą OX Security demonstrowało jako wektor ataku przez STDIO w MCP.

I jeden szczegół który Intruder opisuje lakonicznie: dla jednego nienazywanego narzędzia AI, ponad 90% instancji miało poważne znane podatności. Tydzień później znaleziono nowe RCE w tym narzędziu — i żadna z tych instancji nadal nie była zaktualizowana.

ClawdBot jako case study wszystkiego na raz

Intruder opisał swoje badanie jako reakcję na "aferę ClawdBot." To jest historia która doskonale ilustruje dlaczego te liczby są takie jakie są.

ClawdBot to otwartoźródłowy asystent AI który stał się wirusowy w weekend 24-25 stycznia 2026 roku. W ciągu 72 godzin tysiące użytkowników wdrożyło go na własnych maszynach. Architektura jest ambitna: agent który łączy duże modele językowe z platformami komunikacyjnymi (Telegram, Slack, WhatsApp, Signal, Discord), ma dostęp do lokalnego systemu plików i może wykonywać polecenia systemowe, zapamiętuje kontekst rozmów i działa jako stały proces w tle.

Brzmi jak świetne narzędzie produktywności. W opisie technologicznym — wygląda jak trojan zdalnego dostępu z interfejsem konwersacyjnym. Guardz ujmuje to precyzyjnie: "Everything starts with a developer who triggers a command in their terminal to set up a new AI tool. He doesn't realize he's essentially inviting a 'Remote Access Trojan with a personality' into his environment."

W ciągu kilku dni od wirusowej adopcji badacz Jamieson O'Reilly przeszukał Shodan wyszukując unikalny tag tytułu HTML panelu administracyjnego "Clawdbot Control" — i znalazł setki publicznych instancji. Wiele bez żadnego hasła. Konfiguracje z kluczami API Anthropic, tokenami Telegram i Slack, miesiącami historii prywatnych rozmów — dostępne dla każdego kto wpisał właściwe zapytanie w Shodan.

Mechanizm był klasyczny i przewidywalny: ClawdBot obsługuje kryptograficzne uwierzytelnienie urządzeń przez protokół challenge-response. Dla połączeń z localhost uwierzytelnienie jest automatycznie pomijane — bo to środowisko lokalne, skąd niebezpieczeństwo. Gdy ClawdBot działa za odwrotnym proxy na tej samej maszynie, zewnętrzny ruch trafia przez 127.0.0.1 — i jest traktowany jak lokalny. Bezpieczne domyślne ustawienie dla środowiska deweloperskiego stało się dziurą bezpieczeństwa w środowisku produkcyjnym.

2.6 CVE dziennie i trzy nazwy w tydzień

To co nastąpiło po odkryciu O'Reilly jest właściwą miarą stanu bezpieczeństwa projektu który zbiera kilkadziesiąt tysięcy obserwujących w kilka dni.

CVE-2026-25253: łańcuch dwóch podatności do wykonania kodu na bocie. CVE-2026-25157: wstrzyknięcie poleceń. Kolejne podatności przez następne dni. Intruder w swoim raporcie opisuje projekt jako uśredniający 1.5-2.6 CVE dziennie. Dla porównania: Android — jeden z największych projektów oprogramowania na świecie, atakowany przez tysiące badaczy — dostaje łatki raz w miesiącu.

27 stycznia, kilka dni po wybuchu afery, Anthropic wysłało prawny wniosek o zmianę nazwy. Projekt przemianował się na Moltbot. Tego samego dnia konta @clawdbot na X i GitHubie — z ponad 60 000 obserwujących — zostały natychmiast przejęte przez oszustów promujących fałszywy token kryptowalutowy $CLAWD. 29 stycznia kolejne przemianowanie: OpenClaw, ze względu na kolejny spór o znaki towarowe.

Trzy nazwy w tydzień, aktywne konta przejęte przez scammerów, 2000+ wystawionych bramek na Shodan — i przez cały ten czas projekt rósł i był wdrażany przez deweloperów w środowiskach produkcyjnych.

O'Reilly opublikował też dowód koncepcji ataku supply chain na ClawdHub — marketplace umiejętności dla Moltbot. Przesłał pozornie legalną umiejętność, sztucznie zawyżył licznik pobrań do ponad 4000, i obserwował jak deweloperzy z siedmiu krajów pobrali zatraty pakiet. "The payload pinged my server to prove execution occurred, but I deliberately excluded hostnames, file contents, credentials, and everything else I could have taken." To samo co Shai-Hulud przez PyPI — tylko że marketplace umiejętności AI zamiast rejestru pakietów Python.

Dlaczego infrastruktura AI jest gorsza niż inne oprogramowanie

Intruder odpowiada na to pytanie wprost: "secure practices are being undone by eagerness to deliver tools as quickly as possible."

Ale jest głębsza warstwa. Oprogramowanie webowe przez trzy dekady nauczyło się pewnych podstawowych wzorców bezpieczeństwa — HTTPS jako standard, uwierzytelnienie jako domyślne, dane wejściowe użytkownika jako niezaufane. Te wzorce zostały wdrożone boleśnie przez lata naruszeń, regulacji i audytów.

Infrastruktura AI zaczyna od zera. Twórcy budują szybko, priorytetyzują użyteczność, wdrażają w środowiskach "testowych" które zostają produkcyjne, i nie mają jeszcze presji regulacyjnej ani kultury bezpieczeństwa która ukształtowała poprzednią generację oprogramowania webowego. LiteLLM naprawił SQL injection dwiema liniami kodu— ale te dwie linie były w ścieżce uwierzytelnienia przez rok.

Do tego dochodzi problem który NSA i CISA opisały tydzień temu w wytycznych dla agentów AI: każdy agent który przetwarza zewnętrzne wejście i ma jednocześnie dostęp do zasobów i uprawnień do wykonywania poleceń — jest architektonicznie podatny na wstrzyknięcie. ClawdBot przetwarzał wiadomości z Telegrama, Slacka i Signala jako polecenia dla agenta mającego dostęp do systemu plików i powłoki systemowej. SlowMist dokumentuje aktywne kampanie exfiltrujące klucze portfeli kryptowalutowych przez wstrzyknięcie przez email i wiadomości do Clawdbot.

Intruder opisuje amplifikację ryzyka w środowiskach z dostępem do narzędzi: "These misconfigurations are even worse when agents have access to tools like code interpreting, which makes the blast radius much bigger when the attacker discovers sandboxing server-side is also weak, and the infra is not in a DMZ."

"Shadow AI" jako kategoria problemu

Guardz wskazuje na wymiar który jest trudny do zmierzenia ale prawdopodobnie opisuje największą część ekspozycji: "Do you know if you have any ClawdBot on your endpoints? Well, that can surprise you because users, even not the technical ones, tried it."

Shadow AI to rozszerzenie problemu Shadow IT który organizacje ścigają od dekady — nieautoryzowane narzędzia instalowane przez pracowników poza procesami IT. Poprzednia generacja tego problemu to była nieautoryzowana chmura: Dropbox, Slack, Google Drive zanim IT je zatwierdziło. Nowa generacja to agenty AI: ClawdBot, Moltbot, OpenClaw, kolejne projekty które pojawią się w przyszłym tygodniu.

Różnica jest fundamentalna w skali ryzyka. Nieautoryzowany Dropbox to potencjalny wyciek danych. Nieautoryzowany agent AI z dostępem do powłoki systemowej, historią rozmów z poświadczeniami i integracją z narzędziami komunikacyjnymi — to Guardz precyzyjnie opisuje jako "Remote Access Trojan with a personality." I to RAT który użytkownik zainstalował sam, dobrowolnie, bo tak ładnie działa.

Co zrobić

Dla organizacji z deweloperami na macOS i Linuksie: inwentaryzacja czy którykolwiek pracownik zainstalował ClawdBot, Moltbot lub OpenClaw. Poszukiwanie procesów clawdbot, moltbot lub openclaw w aktywnych procesach i uruchomionych usługach.

Dla instancji Ollama, Flowise, Open WebUI lub Langflow wystawionych na internet: weryfikacja czy uwierzytelnienie jest włączone i poprawnie skonfigurowane po stronie odwrotnego proxy. Intruder dokumentuje że sam interfejs administracyjny "read-only" już stanowi poważne naruszenie — konfiguracje regularnie zawierają klucze API, tokeny i miesiące historii rozmów.

Dla działów IT: rozszerzenie inwentarza zasobów o narzędzia AI uruchomione przez pracowników poza procesem zatwierdzania. Kategoria "narzędzie deweloperskie" nie opisuje już rzeczywistości kiedy to narzędzie ma dostęp do powłoki systemowej i przetwarza zewnętrzne wiadomości.

Podsumowanie

Intruder zeskanował 2 miliony hostów i znalazł że infrastruktura AI jest gorzej zabezpieczona niż cokolwiek innego co kiedykolwiek badali. ClawdBot w ciągu tygodnia zebrał 60 000 obserwujących, przemianował się trzy razy, dostał dziesiątki CVE i miał 2000 wystawionych bramek na Shodan — z historią prywatnych rozmów i kluczami API dostępnymi bez uwierzytelnienia.

To nie jest historia o złym projekcie. To jest historia o wzorcu który będzie się powtarzał przy każdym następnym wirusowym narzędziu AI: szybka adopcja, domyślnie niebezpieczne ustawienia, brak kultury bezpieczeństwa w ekosystemie, wdrożenia produkcyjne które zaczęły się jako testowe.

M-Trends 2026 potwierdził wczoraj że mediana time-to-exploit jest teraz ujemna — eksploity pojawiają się przed łatkami. W środowisku gdzie framework AI dostaje 2.6 CVE dziennie i 90% instancji ma znane podatności, ta mediana nie jest abstrakcją. Jest terminem.

Źródła

Intruder — pełne badanie z danymi liczbowymi dotyczącymi wystawionej infrastruktury AI: https://www.intruder.io/research/from-enterprise-chatbots-to-gooner-caves-exposed-ai-infrastructure-is-rampant

Guardz — analiza techniczna architektury ClawdBot i wektora "RAT with a personality": https://guardz.com/blog/when-ai-agents-go-wrong-clawdbots-security-failures-active-campaigns-and-defense-playbook/

The Register — historia trzech rebrandingów i dowód koncepcji supply chain przez ClawdHub: https://www.theregister.com/2026/01/27/clawdbot_moltbot_security_concerns/

Tenable — zestawienie wszystkich CVE i rekomendacje hardening: https://www.tenable.com/blog/agentic-ai-security-how-to-mitigate-clawdbot-moltbot-openclaw-vulnerabilities

SOCRadar — analiza mechanizmu localhost bypass i implikacji dla architektury agentów: https://socradar.io/blog/clawdbot-is-it-safe/