Cognition CVE-2026-109437: unauth RCE agenta naprawione w lipcu, CVE w październiku. Wersja 0.13.0 to warunek konieczny, ale nie wystarczający

19 października VulnCheck opublikował CVE-2026-109437 dla Cognition, serwera do uruchamiania agentów AI zbudowanego na LangGraph Deep Agents. Ocena: 9.8 w CVSS 3.1. Opis: API bez uwierzytelnienia i agent, który domyślnie wykonuje polecenia w lokalnej powłoce. Wydanie naprawcze 0.13.0 pochodzi jednak z 27 lipca. Kusi więc prosty wniosek: kto ma 0.13.0 lub nowszą wersję, jest bezpieczny od trzech miesięcy. To prawda tylko częściowo. 0.13.0 zamyka domyślną ścieżkę do powłoki, ale nie dodaje uwierzytelnienia API. Plik docker-compose.yml z repozytorium projektu, także w najnowszym wydaniu, sam włącza flagę, którą poprawka wyłączyła.

Co opisuje CVE

Według rekordu CNA Cognition przed 0.13.0 łączy dwie wartości domyślne. Agent pracuje na lokalnym backendzie powłoki, czyli ma narzędzie wykonujące polecenia bezpośrednio w systemie, na którym działa serwer. API, przez które tworzy się sesję i wysyła wiadomość do agenta, nie wymaga żadnego uwierzytelnienia. Kto dosięgnie portu HTTP, może więc skłonić agenta do uruchomienia poleceń jako proces serwera. Skutek: RCE bez poświadczeń i bez interakcji użytkownika.

Strona Lasso dodaje kilka szczegółów, które są ważne dla oceny skutków. Lokalny backend przekazuje do poleceń zmienne środowiskowe, w tym GH_TOKEN. Mechanizm scopingu sesji jest domyślnie wyłączony, a po włączeniu opiera się na nagłówkach deklarowanych przez samego klienta, bez podpisu ani sekretu. Nie jest więc granicą uwierzytelnienia. Narzędzie powłoki nie wymaga domyślnie zatwierdzenia przez człowieka (interrupt_on wyłączone) i nie jest blokowane listą narzędzi.

To ten sam schemat, który opisywałem przy piętnastu CVE dla DB-GPT, Langchain-Chatchat, Letty i innych. Pochodzi zresztą z tej samej fali zgłoszeń VulnCheck i tych samych badaczy. Różnica: tu istnieje wersja naprawiona i właśnie dlatego łatwo zamknąć finding za wcześnie.

Data CVE to nie data poprawki

Między wydaniem poprawki a publikacją CVE minęły prawie trzy miesiące. Dla VM ma to dwa skutki. Po pierwsze, „nowe Critical” z 19 października nie jest zero-dayem. Kto aktualizuje Cognition na bieżąco, ma wersję spoza zakresu od lipca. Po drugie, changelog 0.13.0 nie nazywa tego problemu wprost. Sekcja „Security” mówi o tym, że wdrożenia produkcyjne „do not silently fall back to host-local paths”, a sekcja „Breaking Changes” o migracji, w której „Mixed v0.12/v0.13 writers are unsupported”. Kto w lipcu odłożył aktualizację z powodu migracji schematu, nie miał w changelogu sygnału, że odkłada poprawkę bezpieczeństwa.

Dodatkowa pułapka inwentarzowa: GHSA ma typ „unreviewed” i pustą listę pakietów, a rekord NVD nie ma CPE. Narzędzia SCA dopasowujące advisory do pakietu nie mają się czego chwycić. Nie pomoże też nazwa: projekt w pyproject.toml nazywa się cognition, a pakiet o tej nazwie na PyPI to niezwiązany projekt innego autora. Dopasowanie po nazwie pakietu da fałszywy wynik w obie strony.

Co naprawdę zmienia 0.13.0

W settings.py wersji 0.13.0 pojawia się ustawienie unsafe_local_execution (zmienna COGNITION_ALLOW_UNSAFE_LOCAL_EXECUTION) z wartością domyślną False. Changelog opisuje je jako tryb „fail closed for unsupported host/local execution [...] unless explicit development flags are enabled”. Domyślny backend nadal nazywa się local, ale bez flagi serwer ma odmówić wykonania na hoście. Tego zachowania nie testowałem, opieram się na kodzie ustawień i changelogu.

Czego 0.13.0 nie zmienia: uwierzytelnienia API. Changelog mówi wprost, że „credentials, tenant authorization, and billing policy” zostają „outside Cognition and under builder/operator control”. Dokumentacja bezpieczeństwa na gałęzi głównej ma tabelę odpowiedzialności z wierszem „API authorization | Gateway/proxy layer — Cognition assumes authenticated callers”. To świadoma decyzja architektoniczna, a nie przeoczenie. Dla VM oznacza jednak, że połowa przyczyny opisanej w CVE (CWE-306) nie jest usunięta przez aktualizację, tylko przeniesiona na wdrażającego.

Compose z repozytorium cofa poprawkę

Plik docker-compose.yml w tagu v0.13.0, a także w 0.16.3 i na gałęzi głównej, zawiera:

Komentarz nad tymi liniami jest uczciwy: „explicitly unsafe standalone development backend”, polecenia wykonują się w kontenerze, a nie w produkcyjnym sandboksie. Lasso w zaleceniach pisze to samo: nie ustawiać tej flagi poza izolowanym środowiskiem deweloperskim i usunąć ją z wdrożeń opartych na tym pliku. Problem polega na tym, jak takie pliki są używane w praktyce. Szybki start z README korzysta z compose. Instancja „na chwilę do testów” postawiona na VM w chmurze z publicznym IP zostaje często na dłużej. Docker publikuje 8000:8000 na wszystkich interfejsach. Taka instancja ma wersję ≥ 0.13.0, więc skaner wersji pokaże „naprawione”, a zachowanie jest takie jak przed poprawką. Wykonanie odbywa się wprawdzie w kontenerze, a nie bezpośrednio na hoście, ale w tym kontenerze są klucze do modeli, poświadczenia bazy z tego samego pliku i tokeny przekazane w środowisku.

Ten rozkład pokazuje, że CVE-2026-109437 jest w praktyce findingiem konfiguracyjnym z komponentem wersji, a nie odwrotnie. Podobny przypadek, w którym dwa pozornie niewinne defaulty składają się w unauth RCE, opisywałem przy Cua computer-server.

CVSS 4.0 ma tu rację z AT:P

CNA dało w CVSS 4.0 AT:P (wymagane warunki ataku), a w CVSS 3.1 nie ma odpowiednika tej metryki, stąd 9.8 wobec 9.2. Rekord nie wyjaśnia, jaki warunek ma na myśli. Moje odczytanie: chodzi o to, że agent musi mieć skonfigurowany model i lokalny backend, a instancja musi być osiągalna. Po aktualizacji do 0.13.0 ten warunek przestaje być spełniony domyślnie, ale wraca przy compose z repozytorium. Do rejestru wpisałbym więc ocenę zależną od konfiguracji, a nie od wersji: 9.x dla instancji z flagą albo bez bramki uwierzytelniającej, niską dla instancji spełniających ostatni wiersz tabeli.

Co powinien zrobić VE

1. Znajdź instancje, nie pakiety. GHSA bez pakietu i brak CPE oznaczają, że SCA nic nie zgłosi. Szukaj kontenerów i obrazów Cognition, procesów nasłuchujących na 8000 z endpointem /health i repozytoriów, w których leży kopia docker-compose.yml projektu. Zwróć uwagę na zespoły data science i R&D, które stawiają takie serwery poza CMDB.
2. Sprawdź konfigurację, nie tylko wersję. Dla każdej instancji ustal, czy w środowisku kontenera jest COGNITION_ALLOW_UNSAFE_LOCAL_EXECUTION=true lub COGNITION_ALLOW_HOST_TOOLS=true, jaki jest COGNITION_SANDBOX_BACKEND i na jakim interfejsie opublikowany jest port. Wystarczy docker inspect albo przegląd manifestów.
3. Wersja < 0.13.0: aktualizacja z zaplanowaną migracją (changelog wymaga wstrzymania zapisów przed migracją schematu), a do tego czasu odcięcie portu od niezaufanych sieci.
4. Wersja ≥ 0.13.0 z flagą: traktuj jak podatną. Usuń flagę albo przełącz backend na docker, kubernetes lub MicroVM, które dokumentacja projektu opisuje jako izolację procesów.
5. Każda wersja: API za bramką lub reverse proxy z uwierzytelnieniem i bez bezpośredniej ekspozycji portu. To nie jest opcjonalne utwardzenie, tylko brakująca połowa poprawki. Zgodnie z zaleceniem Lasso rozważ też wymaganie zatwierdzenia przez człowieka dla narzędzia execute u agentów, które przetwarzają niezaufane dane.
6. Jeśli instancja była publicznie osiągalna z lokalnym backendem: zakładaj kompromitację poświadczeń dostępnych w środowisku (klucze do API modeli, GH_TOKEN, hasło bazy) i zrotuj je. Brak potwierdzonego wykorzystania w źródłach publicznych nie mówi nic o Twojej instancji.
7. Kryterium zamknięcia: wersja ≥ 0.13.0 i brak flagi i uwierzytelniająca bramka przed API, potwierdzone na działającej instancji. Samą wersję traktuj jako warunek konieczny.

Powiązane na blogu

• DB-GPT, Langchain-Chatchat, Letta, piflow: 15 CVE dla agentów AI z narzędziem shell — ta sama fala zgłoszeń, problemem jest domyślny compose
• Cua computer-server — dwa defaulty składają się w unauth RCE
• HexStrike AI CVE-2026-90619/90620 — unauth remote shell w narzędziu AI, a fixed release nie istnieje
• HackingBuddyGPT CVE-2026-90621 — CVE mówi jedno, źródło pokazuje RCE na stacji operatora

Źródła

• NVD — CVE-2026-109437 (CNA VulnCheck, CVSS 3.1 9.8, CVSS 4.0 9.2, CWE-306, CWE-1188, zakres 0 do <0.13.0, status Deferred) — nvd.nist.gov
• GitHub Advisory Database — GHSA-c2qr-crjw-844g (unreviewed, bez pakietu) — github.com
• CognicellAI/Cognition — release v0.13.0 (changelog z 27.07.2026: strict execution, sekcja Security, breaking changes) — github.com
• CognicellAI/Cognition — docker-compose.yml w tagu v0.13.0 (COGNITION_ALLOW_UNSAFE_LOCAL_EXECUTION=true, port 8000) — github.com
• CognicellAI/Cognition — docs/concepts/security.md (API authorization po stronie bramki) — github.com
• VulnCheck — advisory „Cognition Unauthenticated RCE via Local Shell Backend” — vulncheck.com
• Lasso — CVE-2026-109437 (przyczyna, wpływ, zalecenia) — lasso.security
• CISA Known Exploited Vulnerabilities Catalog (brak CVE-2026-109437 w wersji 2026.10.21) — cisa.gov
• FIRST — EPSS API (CVE-2026-109437, 22.10.2026) — first.org

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 20 października 2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 17:10–19:15 CEST): rekord NVD API 2.0 dla CVE-2026-109437 (opis, obie oceny CVSS z wektorami, CWE, zakres wersji, status), GHSA-c2qr-crjw-844g przez API GitHub (typ unreviewed, brak pakietów), wydanie v0.13.0 i lista wydań przez API GitHub (daty, treść changelogu), pliki docker-compose.yml w tagach v0.12.0, v0.13.0 i v0.16.3, server/app/settings.py w v0.13.0 i v0.16.3, docs/concepts/security.md i pyproject.toml na gałęzi głównej, strony VulnCheck i Lasso, PyPI (pakiet „cognition”), katalog CISA KEV w wersji 2026.10.16 (ponownie sprawdzony 22 października 2026 w wersji 2026.10.21: bez zmian dla opisywanych CVE) oraz API FIRST EPSS. Względem szkicu poprawiłem opis przyczyny: rekord mówi o całkowitym braku uwierzytelnienia API, a nie o „niewłaściwej ochronie”, oraz tezę, że aktualizacja do 0.13.0 sama w sobie zamyka ryzyko. Nie potwierdziłem: czy tryb strict w 0.13.0 rzeczywiście blokuje wszystkie ścieżki wykonania na hoście (nie testowałem), ile instancji Cognition jest dostępnych z internetu, czy ktokolwiek wykorzystał błąd, czy twórcy zostali powiadomieni przed publikacją CVE, jaki warunek CNA miało na myśli przy AT:P ani czy któreś przyszłe wydanie doda uwierzytelnienie API. Tabela stanów, interpretacja AT:P, kryterium zamknięcia i lista działań to oceny autora, nie ustalenia VulnCheck, Lasso ani CognicellAI.