Wprowadzenie do problemu / definicja
CrewAI, otwartoźródłowy framework do budowy i orkiestracji wieloagentowych systemów AI w Pythonie, znalazł się pod lupą badaczy bezpieczeństwa po ujawnieniu zestawu podatności, które w określonych konfiguracjach mogą doprowadzić do wykonania dowolnego kodu, odczytu lokalnych plików oraz dostępu do zasobów wewnętrznych. Problem dotyczy przede wszystkim środowisk, w których agenci korzystają z narzędzi wykonujących kod lub przetwarzających dane pochodzące z niezaufanych źródeł.
Znaczenie sprawy wykracza poza sam framework. To kolejny przykład pokazujący, iż systemy agentowe AI, wyposażone w narzędzia plikowe, sieciowe i wykonawcze, powinny być traktowane jak uprzywilejowane komponenty aplikacyjne, a nie wyłącznie warstwa logiki biznesowej.
W skrócie
Badacze opisali cztery podatności w CrewAI, które można połączyć w jeden łańcuch ataku. Kluczową rolę odgrywa tu narzędzie Code Interpreter oraz mechanizmy awaryjnego przełączania do słabiej zabezpieczonych trybów działania.
- możliwe jest wymuszenie wykonania niebezpiecznych operacji przez prompt injection,
- SSRF może umożliwić dostęp do usług wewnętrznych i metadanych chmurowych,
- błędy w mechanizmie fallback osłabiają model izolacji,
- nieprawidłowa walidacja ścieżek może prowadzić do odczytu lokalnych plików,
- w skrajnym scenariuszu zagrożony jest host uruchamiający aplikację.
Kontekst / historia
Frameworki agentowe coraz częściej integrują funkcje wykonywania kodu, analizy dokumentów, pobierania treści z internetu i komunikacji z usługami zewnętrznymi. Taki model znacząco zwiększa automatyzację, ale jednocześnie rozszerza powierzchnię ataku. W praktyce agent AI może stać się pośrednikiem między niezaufanym wejściem a zasobami o wysokim znaczeniu dla organizacji.
W przypadku CrewAI szczególną uwagę zwrócono na funkcję Code Interpreter, która miała zapewniać uruchamianie kodu Pythona w odizolowanym kontenerze Docker. o ile jednak to środowisko nie działa zgodnie z założeniami, a aplikacja przełącza się do alternatywnego trybu wykonania, izolacja przestaje spełniać swoją rolę. To właśnie ten model awaryjnego działania stał się jednym z głównych źródeł ryzyka.
Analiza techniczna
Łańcuch podatności obejmuje cztery błędy, które mogą działać razem. Pierwsza luka, CVE-2026-2275, dotyczy zachowania Code Interpreter w sytuacji braku dostępu do Dockera. Zamiast bezpiecznie przerwać zadanie, komponent może przełączyć się do alternatywnego mechanizmu wykonania, co w określonych warunkach otwiera drogę do wykonania kodu.
Druga podatność, CVE-2026-2286, ma charakter SSRF i wynika z niewystarczającej walidacji adresów URL przekazywanych do narzędzi wyszukiwania oraz komponentów typu RAG. W efekcie agent może zostać skłoniony do pobierania danych z usług wewnętrznych, interfejsów administracyjnych lub endpointów metadanych środowiska chmurowego.
Trzecia luka, CVE-2026-2287, również wiąże się z logiką środowiska wykonawczego. CrewAI może nieprawidłowo oceniać dostępność Dockera w trakcie działania i ponownie przechodzić do mniej bezpiecznego trybu sandbox. Taki fallback osłabia założenia izolacji i zwiększa ryzyko zdalnego wykonania kodu.
Czwarta podatność, CVE-2026-2285, dotyczy narzędzia do ładowania danych JSON. Brak prawidłowej walidacji ścieżek plików umożliwia odczyt dowolnych plików lokalnych dostępnych dla procesu aplikacji. W praktyce może to oznaczać ekspozycję plików konfiguracyjnych, kluczy API, sekretów, tokenów czy danych sesyjnych.
Najgroźniejszy scenariusz polega na łańcuchowym wykorzystaniu tych błędów. Atakujący nie musi zaczynać od klasycznego exploita sieciowego. Wystarczy, iż wpłynie na zachowanie agenta przez prompt injection bezpośrednie lub pośrednie, na przykład przez dokument, treść strony albo inne źródło danych przetwarzane przez system. Następnie agent może sam uruchomić sekwencję działań prowadzących do rozpoznania środowiska, odczytu zasobów i wyjścia poza zakładany poziom izolacji.
Konsekwencje / ryzyko
Skutki potencjalnego ataku są poważne szczególnie w środowiskach, w których agenci AI mają dostęp do danych produkcyjnych, systemów CI/CD, repozytoriów kodu, usług chmurowych lub narzędzi administracyjnych. Łańcuch podatności może doprowadzić zarówno do wycieku danych, jak i do pełnej kompromitacji środowiska uruchomieniowego.
- wykonanie dowolnego kodu na hoście lub w kontekście procesu aplikacji,
- odczyt poufnych plików z systemu plików,
- kradzież poświadczeń, tokenów i sekretów aplikacyjnych,
- dostęp do usług wewnętrznych przez SSRF,
- naruszenie segmentacji między agentem a infrastrukturą wykonawczą,
- eskalacja prompt injection z poziomu logicznego do pełnego incydentu bezpieczeństwa.
Największe ryzyko wynika z błędnego założenia, iż agent AI jest wyłącznie warstwą aplikacyjną o ograniczonym wpływie na infrastrukturę. W rzeczywistości integracja z interpreterem kodu, loaderami plików i konektorami sieciowymi sprawia, iż kompromitacja logiki bezpieczeństwa może stworzyć realny wektor dostępu początkowego lub ruchu bocznego.
Rekomendacje
Podstawowym krokiem obronnym jest ograniczenie lub całkowite wyłączenie Code Interpreter wszędzie tam, gdzie jego użycie nie jest absolutnie niezbędne. Możliwość wykonywania kodu powinna być wyjątkiem, a nie wygodnym ustawieniem domyślnym.
Organizacje korzystające z CrewAI powinny wdrożyć zasadę fail closed. o ile Docker lub wymagany mechanizm izolacji nie jest dostępny, zadanie powinno zostać przerwane zamiast uruchamiania w trybie zastępczym o słabszych gwarancjach bezpieczeństwa. Należy również przeanalizować wszystkie fallbacki, opcje debugowe oraz zakres uprawnień przypisanych agentom i ich narzędziom.
Istotna jest też ścisła kontrola danych wejściowych. Prompty, dokumenty, wyniki wyszukiwania, treści pobierane z internetu i dane od użytkowników powinny być traktowane jako niezaufane. Oznacza to filtrowanie wejść, ograniczanie funkcji wysokiego ryzyka oraz stosowanie polityk, które uniemożliwiają wykonywanie działań na podstawie niesprawdzonej treści.
Na poziomie sieciowym warto blokować połączenia wychodzące do adresów wewnętrznych, usług metadanych chmurowych i krytycznych segmentów infrastruktury. Taki model znacząco ogranicza skuteczność SSRF choćby wtedy, gdy sama aplikacja nie waliduje adresów URL prawidłowo.
Dodatkowo należy wzmocnić ochronę sekretów i monitorowanie. Poświadczenia powinny być przechowywane w dedykowanych magazynach, ekspozycja w zmiennych środowiskowych powinna zostać ograniczona, a sam proces uruchamiający agentów powinien działać z minimalnym zakresem uprawnień. Warto także monitorować nietypowe wywołania narzędzi, próby dostępu do lokalnych plików, uruchomienia interpretera i zapytania do niestandardowych adresów.
Podsumowanie
Incydent związany z CrewAI pokazuje, iż bezpieczeństwo agentów AI nie kończy się na ochronie przed manipulacją promptem. Gdy system łączy rozumowanie z wykonywaniem kodu, odczytem plików i dostępem do sieci, choćby pozornie pomocnicze błędy mogą zostać przekształcone w skuteczny łańcuch prowadzący do kompromitacji hosta.
Dla zespołów bezpieczeństwa to wyraźny sygnał, iż platformy agentowe należy poddawać takiemu samemu reżimowi hardeningu, segmentacji i monitoringu jak inne komponenty o podwyższonym poziomie uprzywilejowania. Największym zagrożeniem nie jest bowiem pojedyncza luka, ale możliwość połączenia kilku słabości w wieloetapowy scenariusz ataku.
Źródła
- SecurityWeek — https://www.securityweek.com/crewai-vulnerabilities-expose-devices-to-hacking/
- CERT/CC Advisory — https://kb.cert.org/