Opisaliśmy JADEPUFFER — pierwszy ransomware w całości poprowadzony przez agenta AI, który wszedł do ofiary przez Langflow, otwartoźródłową platformę do budowania aplikacji LLM, i stamtąd wyssał wszystkie sekrety, jakie znalazł. Wektorem wejścia była luka CVE-2025-3248, załatana w kwietniu 2025. Dziś, niecały tydzień później, IBM publikuje biuletyn o kolejnej luce w tym samym Langflow — CVE-2026-10134 — która daje atakującemu dokładnie to samo: możliwość odczytania każdego sekretu dostępnego platformie, przeczytania i zmodyfikowania każdego przepływu, każdej konwersacji, każdego przesłanego pliku, połączenia się z usługami wewnętrznymi i sięgnięcia po dane uwierzytelniające chmury.
To jest ta sama platforma, ta sama klasa luki, ten sam skutek — trzeci raz w kilkanaście miesięcy. I to nie jest przypadek ani pech. To jest cecha architektury, którą warto nazwać wprost, bo mówi coś ogólniejszego o całej kategorii narzędzi, którym coraz częściej powierzamy klucze do wszystkiego.
Trzy luki, jeden wzorzec, jeden plik
Prześledźmy tę serię, bo dopiero widziana w całości układa się w tezę.
Pierwsza była CVE-2025-3248, ujawniona w kwietniu 2025. Endpoint sprawdzający kod przyjmował dowolny kod w Pythonie i przekazywał go do funkcji exec() — która wykonuje przekazany tekst jako program — bez wymagania logowania i bez żadnej piaskownicy. Botnety eksploatowały ją masowo, CISA wpisała ją na listę aktywnie wykorzystywanych, a w tym tygodniu weszła przez nią agentowa operacja ransomware. Zespół Langflow naprawił ją prosto: dodał wymóg uwierzytelnienia do tego jednego endpointu.
Druga była CVE-2026-33017, z marca 2026. Badacz Aviral Srivastava znalazł tę samą klasę błędu na innym endpoincie tego samego pliku. Publiczne przepływy Langflow — chatboty i narzędzia udostępniane przez link, z założenia dostępne bez logowania — budowane są przez endpoint, który z definicji nie może wymagać uwierzytelnienia, bo inaczej publiczny chatbot przestałby być publiczny. Problem leżał w tym, co ten endpoint dodatkowo przyjmował: opcjonalny parametr z definicją przepływu. Gdy go podać, serwer wykonywał kod z tej definicji zamiast z zapisanej w bazie. Innymi słowy, dało się przysłać kompletnie zmyśloną definicję z dowolnym kodem Pythona, a serwer ją zbudował i uruchomił — bez logowania. Srivastava opisał to jednym zdaniem, które jest sednem całej historii: „ta sama baza kodu, to samo wywołanie exec() na końcu łańcucha, zero piaskownicy — inny endpoint".
Trzecia jest właśnie ujawniona CVE-2026-10134. Mechanizm jest bliźniaczy: komponent wykonujący kod Pythona przez exec(), gdzie wykonywany tekst pochodzi z pola kontrolowanego przez atakującego. I znów są dwie drogi — jedna wymagająca sesji, druga nie, aktywna gdy przepływ oznaczono jako publiczny. Każdy odwiedzający może ją wykorzystać, gdy tylko legalny użytkownik utworzy publiczny przepływ z tym komponentem. Efekt, słowami biuletynu IBM, to pełny dostęp: odczyt wszystkich sekretów procesu, odczyt i modyfikacja całej bazy przepływów i konwersacji, połączenia do usług wewnętrznych, nadużycie endpointów metadanych chmury, ruch boczny w głąb sieci.
Trzy osobne numery CVE. Trzy osobne łatki. Ale jeden wzorzec pod spodem, powtórzony bez zmian: kod kontrolowany przez użytkownika trafia do exec() bez piaskownicy. Za każdym razem naprawiano konkretny endpoint. Za każdym razem wzorzec wracał innym.
Dlaczego to nie jest „kolejny bug do załatania"
Tu dochodzimy do sedna — bo łatwo tę historię przeczytać jako niechlujstwo jednego projektu, a to byłby błąd, który przegapia właściwą lekcję.
Langflow wykonuje kod dostarczony przez użytkownika nie przez pomyłkę, lecz dlatego, że na tym polega jego działanie. To narzędzie, którego całą funkcją jest pozwolić ludziom budować przepływy AI z komponentów zawierających kod, a potem ten kod uruchamiać. Wykonywanie cudzego Pythona to nie efekt uboczny błędu — to podstawowa oferowana zdolność. A to znaczy, że exec() gdzieś w środku jest nieusuwalny. Można go otoczyć uwierzytelnianiem, można go przenieść, można załatać konkretną ścieżkę, którą ktoś znalazł — ale sama zdolność wykonywania dostarczonego kodu zostaje, bo bez niej produkt przestaje być tym, czym jest.
To jest dokładnie ta sama obserwacja, którą postawiliśmy przy Cordyceps: są luki, które nie są pojedynczym błędem do naprawienia, lecz właściwością konstrukcji, wracającą raz za razem, dopóki nie zmieni się samej konstrukcji. Przy Cordyceps była to kompozycja workflow CI/CD, w której niezaufane dane przekraczały granicę zaufania, której nikt nie audytował. Tu jest to platforma, która z definicji wykonuje dostarczony kod, więc każda ścieżka prowadząca do tego wykonania bez odpowiedniej izolacji jest tą samą luką w nowym przebraniu. Łatanie endpointu po endpoincie to gaszenie kolejnych zapałek, gdy problemem jest to, że cała podłoga jest z drewna.
I to jest szersza lekcja o całej kategorii narzędzi, nie o jednym projekcie. Platformy do budowania aplikacji AI — Langflow i jemu podobne — mają wbudowaną powierzchnię ataku, której zwykły serwer aplikacyjny nie ma: wykonują kod i instrukcje jako swoją główną funkcję, i jednocześnie trzymają w środku klucze do wszystkiego, co łączą. To czyni je skarbcami, o których pisaliśmy — a skarbiec, który z projektu wykonuje cudzy kod, jest skarbcem ze skrytką na zawiasach od środka.
Uczciwie: to jest załatane i ma warunki
Zanim wyciągniemy wniosek, trzymajmy dyscyplinę, bo inaczej wpis stałby się alarmem, a nie diagnozą.
CVE-2026-10134 jest naprawiona w Langflow 1.9.4 i nowszych; podatne są wersje od 1.0.0 do 1.9.3. To nie jest zero-day w toku — to lekcja z zamkniętą pętlą naprawy. Eksploatacja bez logowania ma też warunek: przepływ musi być publiczny albo instancja musi działać z domyślnym automatycznym logowaniem. Nie każda instalacja Langflow jest więc podatna z automatu na wariant nieuwierzytelniony. Ale trzeba dodać drugą stronę tej uczciwości: publiczne przepływy to nie egzotyka, lecz standardowy sposób, w jaki Langflow działa w produkcji — chatbot udostępniony przez link to właśnie publiczny przepływ. Warunek, który brzmi jak zabezpieczenie, w praktyce jest spełniony w wielu realnych wdrożeniach.
Pilna czynność jest więc prosta i niealarmowa: zaktualizuj Langflow do 1.9.4 lub nowszej, a jeśli nie możesz od razu — przejrzyj, które przepływy masz oznaczone jako publiczne, i odłącz platformę od internetu tam, gdzie nie musi być wystawiona. To standardowe utwardzanie, nie gaszenie pożaru.
Co z tego wynika dla obrońcy
Pierwszy wniosek jest konkretny. Jeśli używasz Langflow, potraktuj tę aktualizację priorytetowo — nie dlatego, że atak trwa teraz, lecz dlatego, że przez tę samą platformę tydzień temu weszła realna operacja ransomware, a działający kod demonstrujący nową lukę jest już publiczny. I zrób przy okazji to, co i tak trzeba było zrobić po JADEPUFFER: rotuj wszystkie sekrety, które kiedykolwiek były dostępne twojej instancji Langflow, bo cała klasa tych luk służy właśnie do ich odczytania.
Drugi jest architektoniczny i wykracza poza Langflow. Każde narzędzie, którego funkcją jest wykonywanie dostarczonego kodu albo instrukcji — platformy budowania agentów, serwery integracji, wykonawcy przepływów — traktuj jako coś, co prędzej czy później ten kod wykona także dla atakującego. To znaczy, że obroną nie jest łatanie kolejnych ścieżek do exec(), tylko izolacja: takie narzędzie nie powinno działać z żywymi kluczami chmury i produkcji w zasięgu procesu, nie powinno mieć nieograniczonego dostępu do sieci wewnętrznej, i nie powinno móc sięgnąć do endpointów metadanych chmury, które oddają poświadczenia na żądanie. Zakładaj wykonanie kodu jako stan domyślny, nie jako incydent — i buduj granice wokół tego założenia.
Trzeci jest najszerszy i domyka to, co obserwujemy od miesięcy. Powtarzalność tych luk w Langflow nie jest anomalią jednego projektu — jest zapowiedzią tego, jak będzie wyglądać bezpieczeństwo całej warstwy narzędzi AI, którą właśnie masowo wdrażamy. To są narzędzia zaprojektowane, by wykonywać instrukcje i trzymać klucze, czyli robić dokładnie te dwie rzeczy, których połączenie jest najgroźniejsze. Dopóki traktujemy je jak zwykłe aplikacje — łatając pojedyncze dziury i idąc dalej — będą nas zaskakiwać tą samą luką w nowym przebraniu. Zaczną być bezpieczne dopiero wtedy, gdy uznamy, że narzędzie wykonujące cudzy kod jest uprzywilejowaną infrastrukturą, a nie wygodnym dodatkiem do produktywności — i odpowiednio je odizolujemy.
Jedna myśl na koniec
Trzy luki tej samej klasy w tej samej platformie w kilkanaście miesięcy to nie jest opowieść o zespole, który nie umie pisać bezpiecznego kodu. To jest opowieść o tym, co się dzieje, gdy dajemy narzędziu dwie zdolności naraz — wykonywanie dostarczonego kodu i dostęp do wszystkich kluczy — i dziwimy się, że ich połączenie wraca do nas raz za razem jako ta sama podatność. Langflow nie jest tu wyjątkiem. Jest wczesnym, dobrze udokumentowanym przykładem reguły, która dotyczy całej nowej warstwy oprogramowania: platforma, która z projektu robi cudzy kod i trzyma cudze sekrety, będzie przeciekać dopóty, dopóki będziemy ją łatać zamiast izolować. Skarbiec ze skrytką na zawiasach od środka nie potrzebuje mocniejszego zamka. Potrzebuje ściany między skrytką a resztą.
Źródła
IBM — oryginalny biuletyn bezpieczeństwa dla CVE-2026-10134, z opisem mechanizmu (PythonCodeStructuredTool, wykonanie przez exec() w publicznych przepływach) i pełnym zakresem skutków, w tym odczytu wszystkich sekretów procesu i dostępu do metadanych chmury: https://www.ibm.com/support/pages/node/7277559
Langflow / GitHub Security Advisory — techniczny opis nieuwierzytelnionej ścieżki przez endpoint build_public_tmp, z potwierdzonym, w pełni powtarzalnym proof-of-concept: https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx
SonicWall Capture Labs — analiza wcześniejszej luki tej samej klasy (CVE-2026-33017) i wyjaśnienie, jak Langflow przekazuje kod z definicji przepływu do exec() bez piaskownicy: https://www.sonicwall.com/blog/langflow-ai-code-injection-to-rce-flaw
Aviral Srivastava (Medium) — opis znalezienia tej samej klasy luki na innym endpoincie, z kluczową obserwacją o powtarzalności wzorca exec() w tej samej bazie kodu: https://medium.com/@aviral23/cve-2026-33017-how-i-found-an-unauthenticated-rce-in-langflow-by-reading-the-code-they-already-dc96cdce5896
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł