Langflow 1.11.2: osiem luk od A2A i MCP do zdalnego wykonania kodu

Osiem rekordów CVE dotyczących Langflow OSS pojawiło się w NVD tuż po północy 29 sierpnia czasu warszawskiego. Najpoważniejsze z nich to CVE-2026-19295 z oceną 9,9 oraz CVE-2026-19286 z oceną 9,8. Pierwsza pozwala uwierzytelnionemu użytkownikowi ominąć politykę wyłączającą własne komponenty i uruchomić polecenia systemowe. Druga otwiera wykonanie Pythona bez uwierzytelnienia przez publiczną ścieżkę Agent-to-Agent.

Dzisiejszą nowością jest publikacja i indeksacja spójnych rekordów CVE. Biuletyny IBM ukazały się 21 i 24 sierpnia. To rozróżnienie jest istotne: nie należy przedstawiać luk jako odkrytych dziś, ale 29 sierpnia skanery, rejestry ryzyka i procesy vulnerability management zyskały jednoznaczne identyfikatory. Wszystkie opisane problemy dotyczą Langflow OSS od wersji 1.0.0 do 1.11.1. IBM zaleca aktualizację do 1.11.2 i nie podaje obejścia zastępującego poprawkę.

Ta fala jest wartościową lekcją projektowania platform agentowych. Nie zawiódł jeden filtr. Zawiodła spójność egzekwowania reguł między publicznym A2A, MCP, starszymi endpointami budowania flow, funkcją tworzącą schemat wejściowy i klientami modeli z konfigurowalnym adresem bazowym.

Dwie krytyczne ścieżki wykonania kodu

CVE-2026-19286 dotyczy publicznego wykonania Agent-to-Agent. Inne publiczne powierzchnie Langflow używały kontroli validate_public_flow_no_code_execution, która miała blokować flow zawierające komponenty wykonujące kod. Ścieżka A2A nie wywoływała tej samej kontroli. Jeżeli operator opublikował agent flow z auth_type=none i włączył A2A, zdalny, nieuwierzytelniony klient mógł doprowadzić do wykonania Pythona w procesie backendu.

Ważne jest prawidłowe odczytanie warunków. Samo posiadanie podatnej biblioteki nie oznacza automatycznie publicznego RCE. Potrzebne są włączona funkcja A2A i odpowiednio opublikowany flow bez uwierzytelnienia. Gdy warunki zachodzą, atak nie wymaga konta ani interakcji użytkownika, stąd CVSS 3.1: 9,8.

CVE-2026-19295 wykorzystuje inną granicę. Użytkownik mogący zapisać flow wprowadza spreparowaną wartość pola type, a następnie uruchamia budowanie wrapper flow, który się do niego odwołuje. Kontrolowana wartość dociera do obsługi ForwardRef w Pydantic, gdzie wykonywana jest przez eval() z dostępnymi wbudowanymi funkcjami Pythona. Skutek to dowolne polecenia systemowe w kontekście procesu Langflow.

Ta ścieżka omija LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, ponieważ nie modyfikuje pola, które mechanizm traktuje jako jawny kod. Zabezpieczenie patrzyło na nazwę wejścia, nie na to, czy jego wartość ostatecznie trafi do interpretera. Właśnie dlatego CVSS wynosi 9,9: wymagane jest konto o niskich uprawnieniach, ale udane wykonanie przekracza granicę bezpieczeństwa i przejmuje poufność, integralność oraz dostępność serwera.

Trzecia luka wykonania kodu, CVE-2026-18729 (8,8), dotyczy komponentu PythonFunction i prywatnego kanału tweak komponentu RunFlow. IBM opisuje niespójność: ścieżka filtrowała dosłowną nazwę pola code, lecz nie stosowała wspólnej kontroli pól kodu używanej gdzie indziej. Uwierzytelniony użytkownik mógł więc ominąć to samo ustawienie hardeningowe inną drogą.

Pięć luk na granicach tożsamości, plików i sieci

Pozostałe problemy nie powinny zostać zepchnięte na dalszy plan tylko dlatego, że mają niższe oceny. Mogą dostarczyć sekretu, danych lub punktu zaczepienia potrzebnego do kolejnego etapu incydentu.

CVE-2026-18891, 8,2: funkcja uwierzytelniania projektu MCP pomijała domyślne auth_type=none w zbiorze trybów wymagających klucza API. Na transportach Streamable HTTP i SSE-message nieuwierzytelniony klient mógł zostać rozwiązany jako superużytkownik systemowy, gdy MCP Composer był włączony. IBM nazywa to niepełną poprawką wcześniejszej ochrony.
CVE-2026-18899, 7,5: publiczny endpoint budowania flow przekazywał niezwalidowany parametr files do warstwy storage. Traversal przechodził przez niezwalidowany segment flow_id, omijając istniejącą kontrolę pozostania ścieżki w katalogu. Skutkiem był nieuwierzytelniony odczyt plików dostępnych dla procesu.
CVE-2026-18904, 8,2: publiczne metadane flow ujawniały user_id właściciela. Anonimowy klient mógł ponownie użyć go jako client_id, zderzyć się z przestrzenią sesji właściciela, odczytać historię publicznego playgroundu i wstrzyknąć do niej wiadomości.
CVE-2026-19294, 6,4: starsze endpointy budowania pozostawały aktywne, lecz nie miały kontroli własności obiektu obecnej w nowszym odpowiedniku. Zalogowany użytkownik mógł wyliczać oraz wykonywać prywatne komponenty flow innego tenant’a i odczytywać wartości osadzone w grafie.
CVE-2026-18545, 4,3: wspólna ścieżka tworzenia klientów modeli akceptowała kontrolowane przez tenant’a adresy bazowe dla dostawców takich jak ChatOllama i ChatOpenAI bez uruchomienia ochrony SSRF używanej przez konektory. Zalogowany użytkownik mógł kierować zapytania backendu do loopbacku, usług wewnętrznych lub metadanych chmurowych.

Wspólną przyczyną architektoniczną jest duplikacja decyzji bezpieczeństwa. Gdy każda trasa samodzielnie ustala, czy sprawdzić kod, własność, autoryzację i docelowy adres, nowa lub zachowana dla kompatybilności ścieżka łatwo omija regułę.

Kto jest narażony i jak ustalić ekspozycję

Najpierw zinwentaryzuj instancje, obrazy kontenerowe, zależności aplikacji oraz środowiska notebookowe zawierające Langflow OSS. Wersja wyświetlana w interfejsie nie zawsze odpowiada obrazowi uruchomionemu przez orkiestrator, dlatego potwierdź digest obrazu i wersję pakietu w aktywnym procesie. Zakres podatny według IBM to 1.0.0–1.11.1.

Następnie sprawdź warunki funkcjonalne. Czy A2A jest dostępne z sieci niezaufanej? Czy istnieją opublikowane flow z auth_type=none? Czy MCP Composer i transporty HTTP/SSE są aktywne? Czy rejestracja użytkowników jest szeroka, a konta mogą tworzyć lub importować flow? Czy proces ma dostęp do sekretów chmurowych, tokenów modeli, bazy Langflow, katalogów współdzielonych albo gniazda kontenerowego?

Ostatnie pytanie decyduje o realnym blast radius. Kod uruchomiony jako odizolowany, bezsekretowy użytkownik w kontenerze z ograniczonym egress ma inny skutek niż ten sam kod w procesie z kluczem dostawcy AI, tożsamością workload, zapisem do wspólnego wolumenu i dostępem do wewnętrznych API.

Aktualizacja i działania po poprawce

Priorytetem jest przejście do Langflow OSS 1.11.2 lub nowszego wydania dostawcy. Aktualizację przeprowadź na kopii środowiska z reprezentatywnymi flow, ponieważ poprawki obejmują walidację i autoryzację kilku ścieżek. Testy regresji powinny potwierdzić działanie A2A, MCP, publicznych flow, klientów modeli i importowanych schematów bez przywracania niebezpiecznych wyjątków.

Do czasu aktualizacji ogranicz ekspozycję sieciową A2A, MCP i publicznych endpointów, wyłącz nieużywane funkcje oraz zablokuj rejestrację kont. Nie traktuj tego jako pełnego rozwiązania: IBM nie podaje oficjalnego obejścia, a kilka luk działa przez różne powierzchnie. Egress procesu powinien przechodzić przez kontrolowany proxy lub politykę sieciową blokującą loopback, link-local, prywatne zakresy i endpointy metadanych, o ile nie są jawnie potrzebne.

Po wdrożeniu poprawki unieważnij tokeny sesji, przejrzyj konta i opublikowane flow. Jeżeli instancja była publiczna lub wykryto podejrzane budowanie grafów, rotuj sekrety dostępne dla procesu: klucze modeli, JWT, dane bazowe, tokeny chmurowe i poświadczenia konektorów. Sama zmiana wersji nie odbiera sekretu, który wcześniej wyciekł.

Detekcja i analiza incydentu

W logach szukaj publicznych wywołań A2A prowadzących do komponentów kodowych, nietypowych wartości type, budowania wrapper flow przez konta, które zwykle tego nie robią, oraz użycia prywatnego kanału tweak. Dla MCP istotne są sesje bez klucza API, którym przypisano tożsamość systemową. Dla traversal analizuj nietypowe wartości files i flow_id, ale nie zapisuj w publicznym systemie pełnej zawartości odczytanych plików.

Zdarzenia SSRF najlepiej wykrywać na warstwie egress: połączenia procesu Langflow do adresów loopback, link-local, RFC1918 i niezatwierdzonych hostów modeli. W przypadku kolizji przestrzeni sesji koreluj client_id, user_id, adres źródłowy oraz kolejność odczytu i zapisu wiadomości. Sama obecność publicznego flow nie jest IOC; znaczenie ma nieoczekiwany kontekst wykonania.

Zachowaj historię konfiguracji, manifesty wdrożenia, digesty obrazów, listę flow, logi proxy i orkiestratora oraz zdarzenia tożsamości. Jeśli doszło do wykonania kodu, traktuj serwer lub kontener jako potencjalnie przejęty i odbuduj go z zaufanego artefaktu zamiast polegać wyłącznie na usunięciu podejrzanego flow.

Fakty źródłowe i wnioski Breachroad

Mechanizmy, warunki, oceny CVSS, zakres wersji i wydanie 1.11.2 pochodzą z biuletynów IBM oraz rekordów CVE. Segmentacja funkcji, proponowana kolejność rotacji i sygnały detekcyjne są wnioskami obronnymi Breachroad. Źródła producenta nie informują o aktywnym wykorzystaniu tych ośmiu luk w konkretnych atakach. Podatna instancja oznacza ekspozycję, nie automatyczny dowód kompromitacji.

Źródła pierwotne

Platforma agentowa łączy kod, modele, dane i poświadczenia, więc jej granice zaufania trzeba testować łącznie. Na warsztatach z bezpiecznych wdrożeń AI uczymy modelowania takich przepływów i bezpiecznego egzekwowania polityk. Organizacje potrzebujące weryfikacji technicznej mogą objąć publiczne flow, MCP, A2A i egress kontrolowanym AI red teamingiem.