DB-GPT, Langchain-Chatchat, Letta, piflow: 15 CVE dla agentów AI z narzędziem shell. Problemem jest domyślny docker-compose, nie pojedynczy bug

20 października 2026 w nocy VulnCheck jako CNA opublikował 15 CVE w self-hostowanych platformach agentów AI. W NVD wszystkie pojawiły się w ciągu około 10 sekund, a w każdym rekordzie CVE.org w credits są te same trzy nazwiska. Cztery z nich mają CVSS 4.0 9.3 i ten sam mechanizm: agent ma zarejestrowane narzędzie do uruchamiania komend, API nie wymaga logowania, a domyślny docker-compose publikuje port na wszystkich interfejsach. Większość nie ma wersji naprawionej, a jeden projekt nie dostanie jej nigdy. Dla VM to nie jest piętnaście ticketów do patchowania, tylko pytanie, kto w firmie postawił takie stacki i gdzie one słuchają.

Piętnaście CVE w jednej tabeli

Opisy i zakresy pochodzą z rekordów CNA w NVD i CVE.org, oceny z NVD, a kolumnę „Wersja naprawiona” uzupełniłem na podstawie PyPI, wydań na GitHubie i plików w repozytoriach na 20.10.2026. W kolumnie „Kto może” PR:N oznacza brak logowania, a UI:P to sytuacja, w której atakujący nie mówi do agenta wprost, tylko podrzuca mu instrukcje w treści, którą agent czyta.

W tej fali są trzy różne klasy problemu i warto je rozdzielić, zanim trafią do jednej kolejki. Pierwsza to brak uwierzytelnienia przed narzędziem shell albo interpreterem kodu: 77932, 75128, 109442 i 77936. Tu wystarczy jedno żądanie HTTP do portu, a skutek to kod na hoście albo w kontenerze. Druga to stacki, w których trzeba mieć konto, ale konto bywa dostępne dla każdego, np. przez samorejestrację w JoySafeter albo przez „any registered user” w Coze Studio: 77934, 77935, 109443, 77926, 77937, 77938 i 109441. Trzecia to obejście akceptacji człowieka przez prompt injection: 109444, 77930 i 109440. Ta ostatnia grupa wymaga, żeby agent przeczytał spreparowaną treść, ale nie wymaga, żeby atakujący miał jakikolwiek dostęp do samego serwera.

Wspólny mianownik: trzy domyślne ustawienia, które razem dają RCE

Opisy CVE czyta się jak listę bugów w kodzie. Pliki w repozytoriach pokazują jednak, że w czterech najpoważniejszych przypadkach o ekspozycji decyduje to, jak projekt każe się uruchomić. Sprawdziłem to w plikach, do których linkuje CNA, i w aktualnych gałęziach głównych.

• Brak uwierzytelnienia albo uwierzytelnienie na niby. W DB-GPT funkcja get_user_from_headers jest opisana w kodzie komentarzem Mock User Info i zawsze zwraca użytkownika z role="admin": z nagłówkiem user_id albo bez niego. W Letta middleware z hasłem jest dodawany tylko wtedy, gdy LETTA_SERVER_SECURE ma wartość true albo serwer dostał --secure. Dostarczony compose.yaml tego nie ustawia, za to ustawia LETTA_DEBUG=True. W Langchain-Chatchat trasa /tools/call nie ma żadnej zależności sprawdzającej tożsamość.
• Narzędzie shell zarejestrowane domyślnie. Langchain-Chatchat rejestruje narzędzie shell oparte na ShellTool z LangChain. piflow ma exec_shell, DB-GPT shell_interpreter i code_interpreter, Letta POST /v1/tools/run. Dla agenta to funkcja, nie błąd. Błędem staje się dopiero w połączeniu z dwoma pozostałymi punktami.
• Port na wszystkich interfejsach. DB-GPT publikuje 5670:5670 dla webservera i 3306:3306 dla MySQL. Letta publikuje 8283, 8083, 80 (nginx) i 5432 (PostgreSQL). Dokumentacja Dockera mówi wprost, że port opublikowany bez adresu hosta trafia na 0.0.0.0 i [::], „potentially making them available to the outside world”. Langchain-Chatchat w ustawieniach ma DEFAULT_BIND_HOST = "0.0.0.0" na wszystkim poza Windows (porty 7861 i 8501), a jego compose używa network_mode: "host". piflow w server.py uruchamia uvicorn z host="0.0.0.0".

Do tego dochodzi czwarty element, który nie jest AI w ogóle: baza danych dołączona do stacka z hasłem z repozytorium. W DB-GPT MYSQL_ROOT_PASSWORD jest wpisane na stałe w docker-compose.yml i na main 20.10 wciąż jest to samo. W Letta domyślne POSTGRES_PASSWORD to letta, a według CVE-2026-77936 konto ma uprawnienia superusera, więc COPY PROGRAM daje komendy systemowe na hoście bazy. Jest jeszcze jeden szczegół z dokumentacji Dockera, ważny dla każdego, kto liczy na firewall hosta: na Ubuntu z ufw ruch do opublikowanych portów kontenera omija reguły ufw, bo Docker kieruje go w tablicy nat przed łańcuchami INPUT. „Mam ufw” nie znaczy więc „port jest zamknięty”.

Moja ocena: każdy z tych elementów osobno jest typowy dla projektu uruchamianego lokalnie na laptopie. Razem, na maszynie wirtualnej z publicznym adresem albo w płaskiej sieci biurowej, dają nieuwierzytelnione RCE z kluczami API do dostawców LLM w zmiennych środowiskowych. Ten sam wzorzec opisywałem przy Cua computer-server i CISA Malcolm: finding to konfiguracja dostarczona przez projekt, nie linia kodu.

„Through X” znaczy zwykle: nie ma czego wgrać

Zakres „through 0.8.2” albo „≤ 0.3.1.3” w opisie CNA wygląda jak zwykła granica wersji. Tutaj prawie zawsze oznacza, że podatna jest najnowsza dostępna wersja. Status per projekt na 20.10.2026:

• DB-GPT: 0.8.2 z 26.08.2026 to najnowsze wydanie na PyPI i GitHubie. Projekt jest aktywny (commity z 19.10), ale w repozytorium nie ma advisory GHSA, a docker-compose.yml na main wygląda tak samo jak w commicie wskazanym przez CNA.
• Langchain-Chatchat: 0.3.1.3 na PyPI pochodzi z 23.07.2024, ostatni push do repozytorium z 10.11.2025. Repozytorium ma prawie 39 tys. gwiazdek i nie jest zarchiwizowane. Moja ocena: to profil projektu, który jest szeroko wdrożony i praktycznie nieutrzymywany, jak w przypadku UpTrain.
• piflow: v2.0.1 z 31.07.2026 to najnowsze wydanie, brak advisory w repozytorium.
• Letta: tu sytuacja jest najbardziej jednoznaczna. SECURITY.md w letta-ai/letta mówi: „The legacy Letta V1 Python server is retired, unsupported, and receives no fixes or security updates. It should not be used in production.” Wycofane są też obrazy letta/letta „regardless of tag”. Rozwój przeniósł się do letta-ai/letta-code. Ostatni tag serwera to 0.16.8 z 14.05.2026.
• Coze Studio: dla 77934 „poprawka” w 0.5.0 to jedna linia w docker/.env.example: CODE_RUNNER_TYPE="local" zmienione na "sandbox" (commit z 17.10.2025). Ktoś, kto wcześniej skopiował .env.example do .env i potem zaktualizował obrazy, nadal ma local. To moja interpretacja mechanizmu, nie zdanie z advisory. 77935 (IDOR) obejmuje także najnowszą 0.5.1.
• OpenSRE: zakres kończy się na 0.1.2026.10.19, a projekt wydaje wersje codziennie. 0.1.2026.10.20 wyszła 20.10 o 01:16:47 UTC, minutę przed publikacją CVE w NVD. W tym wydaniu execution_allowed() w subprocess_presenter.py nadal zwraca True, a w changelogu nie widzę wpisu o tym błędzie. Czy 0.1.2026.10.20 jest podatna: niepotwierdzone. Skaner porównujący wersje uzna ją jednak za niepodatną.
• EvoScientist: jedyna czysta historia. Issue, commit i release notes v0.2.5 są w referencjach CVE, aktualna wersja na PyPI to 0.3.7.
• JoySafeter, Aix-DB: najnowsze wydania (1.0.0 i 1.2.4) w zakresie. LangAlpha: zakres opisany datą 2026.09.07, a wydania na GitHubie mają tagi desktop-v0.2.5, więc nie potrafię ustalić, czy istnieje wersja poza zakresem. Niepotwierdzone.

Strona advisory VulnCheck ma pole „mitigation” i we wszystkich piętnastu przypadkach jest puste. Lasso na stronie CVE-2026-77932 podaje „Remediation”, ale to zalecenia dla twórców kodu (prawdziwe uwierzytelnienie, sandbox dla interpreterów), a nie kroki dla wdrożenia. Czy twórcy projektów dostali zgłoszenia przed publikacją, ze źródeł nie wynika: niepotwierdzone.

Dlaczego skaner tego nie znajdzie

Trzy powody, wszystkie widoczne w danych z 20.10.

• Brak CPE. Żaden z piętnastu rekordów w NVD nie ma konfiguracji CPE. Rekordy DB-GPT mają status „Deferred”, pozostałe „Received”. Skaner, który dopasowuje podatności po CPE, nie ma do czego dopasować.
• purl wskazuje nie to, co uruchomiono. Rekordy CVE.org mają purl, np. pkg:pypi/dbgpt-app, pkg:pypi/langchain-chatchat, pkg:pypi/letta. Typowe wdrożenie to jednak obraz kontenera z Docker Hub, a nie pip install. Narzędzie SCA, które patrzy na pakiety Pythona na hoście, nie zobaczy obrazu letta/letta:latest.
• Ta sama nazwa, inny produkt. Pakiet letta na PyPI do 0.16.8 (14.05.2026) to serwer. Od 0.32.13 (17.09.2026) pod tą samą nazwą jest „Letta Code: stateful agents in your terminal”, z linkiem do letta-ai/letta-code. Kto ma letta 0.34.12, ma inny produkt i według zakresu CNA nie jest podatny. Kto ma serwer z obrazu, nie ma żadnej wersji, którą skaner mógłby porównać. W obu przypadkach wynik skanu nie odpowiada na pytanie, czy w sieci stoi wycofany serwer z otwartym API.

Do tego dochodzi kwestia inwentarza, i to moja ocena, a nie dane z advisory. Takie stacki rzadko przechodzą przez proces wdrożeniowy IT. Stawia je zespół data science na maszynie z GPU, ktoś z biznesu na VM w chmurze do proof of concept albo programista na stacji roboczej. Nie mają właściciela w CMDB, nie mają agenta EDR w kontenerze, a docker compose up -d z README jest dla nich instrukcją wdrożenia. Pisałem o tym przy Langflow i LightLLM: VM dowiaduje się o takim stacku zwykle wtedy, gdy ktoś inny już go znalazł.

Jak to znaleźć u siebie

Poniższe komendy są moje, wyprowadzone z plików compose i kodu wskazanego przez CNA. Nie testowałem ich na exploitach i nie są dowodem braku podatności. Porty i nazwy obrazów to wartości domyślne, a ktoś mógł je zmienić.

Na hostach Letta sprawdź, czy kontener ma ustawione LETTA_SERVER_SECURE=true. Brak tej zmiennej przy domyślnym compose oznacza według opisu 77936 API bez hasła:

Na hostach Langchain-Chatchat z kodu wynika, że GET /tools zwraca listę zarejestrowanych narzędzi, również bez logowania. Jeśli na liście jest shell, a port 7861 odpowiada spoza hosta, warunek z CVE-2026-75128 jest spełniony. To sprawdzenie nie wywołuje narzędzia. Rób je tylko na własnych systemach:

Po stronie sieci warto dopisać te porty do skanu zewnętrznego i do przeglądu reguł security group w chmurze. Szczególnie 3306 i 5432 na maszynach, które w CMDB nie są serwerami baz danych.

Brak wersji naprawionej, czyli kompensacja

Skoro dla większości projektów nie ma czego wgrać, plan musi zaczynać się od ekspozycji. Kolejność według mnie:

1. Odetnij od sieci. Lasso przy CVE-2026-77932 pisze wprost, że wystawione wdrożenia „should be taken off the network or put behind authentication immediately”. W compose zmień "5670:5670" na "127.0.0.1:5670:5670", a porty baz danych usuń z sekcji ports całkowicie. Webserver DB-GPT łączy się z bazą przez sieć compose (MYSQL_HOST=db), więc publikacja 3306 na hoście nie jest mu potrzebna. Dokumentacja Dockera ostrzega, że w wersjach starszych niż 28.0.0 port opublikowany na 127.0.0.1 był osiągalny z hostów w tym samym segmencie L2, więc sprawdź też wersję Dockera.
2. Uwierzytelnienie przed agentem, ale nie zamiast izolacji. Reverse proxy z logowaniem zamyka grupę PR:N. Nie zamyka grupy PR:L: w Letta CVE-2026-77937 pozwala podszyć się pod innego użytkownika nagłówkiem user_id także przy włączonym haśle serwera, a 77938 daje każdemu, kto uruchamia narzędzia, zmienne środowiskowe serwera. Jeśli stack jest współdzielony przez kilka zespołów, traktuj każdego zalogowanego użytkownika jak osobę z dostępem do shella.
3. Zmień domyślne hasła baz i zrotuj sekrety. Hasło root MySQL w DB-GPT i hasło PostgreSQL w Letta są publiczne w repozytoriach. Jeśli port bazy albo API agenta był osiągalny z zewnątrz, zakładaj wyciek kluczy API do dostawców LLM, haseł do źródeł danych i tokenów Slack ze zmiennych środowiskowych i zrotuj je. To samo dotyczy danych, do których agent miał dostęp, np. baz podłączonych do DB-GPT czy Aix-DB jako źródła.
4. Coze Studio: sprawdź w .env, nie w .env.example, czy CODE_RUNNER_TYPE ma wartość sandbox. Sama aktualizacja do 0.5.x nie zmienia istniejącego pliku.
5. Letta V1: vendor mówi, że nie nadaje się do produkcji i nie dostanie poprawek. To finding typu EOL, a nie podatność do patchowania. Plan to migracja albo wyłączenie, z terminem i właścicielem.
6. Grupa prompt injection (OpenSRE, EvoScientist, LangAlpha): tu port nie jest jedynym wektorem, bo atakujący przychodzi przez alert, wiadomość Slack albo stronę WWW, którą agent czyta. EvoScientist zaktualizuj do 0.2.5 lub nowszej. Dla pozostałych ogranicz uprawnienia procesu agenta i dostęp do sekretów, a tryb headless OpenSRE z shell_run traktuj jako zdalne wykonanie komend przez każdego, kto może wysłać alert.

Jak to zapisać w rejestrze

Piętnaście CVE w jednej kolejce z SLA wyliczonym z CVSS da piętnaście ticketów „brak poprawki, czekamy”. Proponuję inaczej, i to jest moja propozycja, a nie praktyka opisana w źródłach. Jeden finding na wdrożenie (host albo projekt compose), z typem „insecure default” lub „EOL”, a numery CVE jako dowód. Priorytet według ekspozycji: API agenta albo port bazy osiągalny spoza hosta to najwyższy priorytet niezależnie od CVSS. W ocenie w stylu SSVC wychodzi mi: exploitation „none” (brak KEV, brak informacji o atakach), automatable „yes” dla grupy PR:N, bo wystarczy jedno żądanie, technical impact „total”. Datę zamknięcia wyznacza zmiana konfiguracji albo wyłączenie stacka, a nie wydanie wersji, która dla części projektów może się nie pojawić.

Co powinien zrobić VE

(1) Przeszukaj hosty i chmurę pod kątem kontenerów i portów z tej strony, także poza serwerami zarządzanymi przez IT: maszyny z GPU, VM-ki projektowe, stacje robocze zespołów danych. (2) Dla każdego znalezionego stacka ustal właściciela i sprawdź, czy API agenta albo port bazy jest osiągalny spoza hosta. (3) Wystawione wdrożenia z grupy PR:N (DB-GPT, Langchain-Chatchat, piflow, Letta) odetnij od sieci od razu, potem rotuj sekrety. (4) Przepnij publikację portów na 127.0.0.1, usuń publikację portów baz, zmień domyślne hasła. (5) Letta V1 zapisz jako EOL z planem migracji, Coze sprawdź w .env, EvoScientist zaktualizuj. (6) Nie zamykaj findingów na podstawie wersji: OpenSRE 0.1.2026.10.20 i letta 0.34.x na PyPI pokazują, że porównanie z zakresem CNA może dać wynik bez związku z tym, co działa w sieci. (7) Dodaj do polityki prostą regułę dla nowych stacków AI: żaden docker compose up z README bez przeglądu sekcji ports i zmiennych z hasłami.

Powiązane na blogu

• Cua computer-server — dwa pozornie niewinne defaulty składają się w unauth RCE
• CISA Malcolm CVE-2026-90456 — przykładowe .env z publicznym hasłem jako produkcyjny credential
• UpTrain — kiedy EOL powinien być findingiem samym w sobie
• IBM Langflow 1.11.5 — rodziny podatności nie wolno redukować do jednego findingu
• LightLLM CVE-2026-103040 i 103041 — usługi pomocnicze stacka AI jako zdalne RCE
• 12 CVE dla MCP w mniej niż 9 sekund — automatyzacja CVE a jakość danych

Źródła

• NVD — CVE-2026-77932 (DB-GPT, react-agent) — nvd.nist.gov
• NVD — CVE-2026-77933 (DB-GPT, MySQL root w docker-compose) — nvd.nist.gov
• NVD — CVE-2026-75128 (Langchain-Chatchat, /tools/call) — nvd.nist.gov
• NVD — CVE-2026-109442 (piflow, exec_shell) — nvd.nist.gov
• NVD — CVE-2026-77936 (Letta, compose bez LETTA_SERVER_SECURE) — nvd.nist.gov
• NVD — CVE-2026-77937 (Letta, nagłówek user_id) — nvd.nist.gov
• CVE.org — CVE-2026-77932 (zakres, purl, credits; analogicznie pozostałe czternaście) — cve.org
• VulnCheck — DB-GPT through 0.8.2 Unauthenticated RCE via /api/v1/chat/react-agent — vulncheck.com
• VulnCheck — Langchain-Chatchat through 0.3.1.3 Unauthenticated RCE via /tools/call Endpoint — vulncheck.com
• VulnCheck — Letta through 0.16.8 Insecure Default Configuration — vulncheck.com
• Lasso — CVE-2026-77932 (Known exploit: No, remediation dla twórców kodu) — lasso.security
• DB-GPT — docker-compose.yml na gałęzi main — github.com
• Letta — SECURITY.md (serwer V1 wycofany, bez poprawek) — github.com
• Letta — compose.yaml na gałęzi archive — github.com
• PyPI — pakiet letta (dziś Letta Code) — pypi.org
• Langchain-Chatchat — settings.py (DEFAULT_BIND_HOST, porty 7861 i 8501) — github.com
• Coze Studio — commit fcf40d1 (CODE_RUNNER_TYPE: local na sandbox) — github.com
• EvoScientist — release notes v0.2.5 — github.com
• OpenSRE — release v0.1.2026.10.20 — github.com
• Docker — Port publishing and mapping (domyślnie 0.0.0.0 i [::]) — docs.docker.com
• Docker — Packet filtering and firewalls (Docker i ufw) — docs.docker.com
• CISA Known Exploited Vulnerabilities Catalog (żadnego z piętnastu CVE w wersji 2026.10.16) — cisa.gov

Nota redakcyjna: stan informacji 20 października 2026, na podstawie rekordów NVD API 2.0 dla piętnastu CVE (opisy, oceny CVSS 4.0 i 3.1 od VulnCheck, CWE, status, brak konfiguracji CPE), rekordów CVE.org (zakresy, purl, credits, brak kontenera ADP), stron advisory VulnCheck (data, zakres, puste pole mitigation, brak w KEV), strony Lasso dla CVE-2026-77932, katalogu CISA KEV w wersji 2026.10.16, API FIRST EPSS (brak wyników), PyPI (dbgpt-app, langchain-chatchat, letta, evoscientist), wydań, commitów i zakładki security advisories na GitHubie oraz plików w repozytoriach: docker-compose.yml i auth.py DB-GPT, compose.yaml, app.py, dependencies.py, SECURITY.md i README.md Letta, tool_routes.py, settings.py, shell.py i docker-compose.yaml Langchain-Chatchat, server.py i tools.py piflow, commitu fcf40d1 Coze Studio, subprocess_presenter.py OpenSRE w dwóch wersjach, a także dokumentacji Dockera o publikacji portów i ufw. Nie weryfikowałem: czy istnieje wersja LangAlpha poza zakresem, czy OpenSRE 0.1.2026.10.20 jest nadal podatna, czy twórcy projektów zostali powiadomieni przed publikacją, domyślnego portu piflow, wartości domyślnych w Coze Studio, JoySafeter i Aix-DB poza tym, co mówią opisy CNA, ani tego, czy ktokolwiek wykorzystał te błędy. Strony Lasso przeczytałem tylko dla CVE-2026-77932; podaje ona CVSS 9.8 i dostępność „None”, inaczej niż wektor VulnCheck VA:H. Komendy wykrywania i przykład zmiany w compose to propozycje autora wyprowadzone z plików compose i kodu, nie testowane na exploitach. Podział na trzy klasy, ocena profilu Langchain-Chatchat, interpretacja poprawki Coze dla istniejących plików .env, uwagi o inwentarzu stacków AI poza IT, ocena w stylu SSVC, propozycja zapisu w rejestrze i lista „Co powinien zrobić VE” to oceny autora, nie ustalenia VulnCheck, Lasso ani twórców projektów.