Dwa tygodnie temu opisaliśmy trzy luki tej samej klasy w Langflow i postawiliśmy tezę, która brzmiała może zbyt teoretycznie: to nie jest niechlujstwo jednego zespołu, tylko właściwość konstrukcji, która będzie wracać, dopóki nie zmieni się samej konstrukcji. Łatanie endpointu po endpoincie nazwaliśmy gaszeniem kolejnych zapałek, gdy problemem jest to, że cała podłoga jest z drewna.
21 lipca CISA dodała do katalogu aktywnie eksploatowanych podatności CVE-2026-0770 — kolejną lukę w Langflow, tym razem pozwalającą nieuwierzytelnionemu atakującemu wykonać kod jako root, w ataku o niskiej złożoności. Federalne agencje dostały termin do piątku. Ale najważniejsze jest to, gdzie ta luka siedzi: w endpoincie /api/v1/validate/code. Tym samym, w którym w kwietniu 2025 znaleziono brak uwierzytelnienia — lukę oznaczoną CVE-2025-3248, przez którą w lipcu wszedł agentowy ransomware JADEPUFFER. Załatano ją, dodając wymóg logowania. Teraz ten sam endpoint wykonuje cudzy kod ponownie, przez parametr, którego przy tamtej naprawie nikt nie sprawdził.
To jest siódma odrębna podatność Langflow, która trafiła do aktywnej eksploatacji. I pierwszy raz, gdy amerykańska agencja federalna musiała wydać w tej sprawie wiążący nakaz.
Ta sama drzwi, inna klamka
Mechanizm CVE-2026-0770 opisali badacze Trend Micro, którzy go znaleźli i zgłosili. Luka tkwi w obsłudze parametru exec_globals przekazywanego do endpointu walidacji kodu. Problem, w ich sformułowaniu, wynika z dołączenia zasobu ze sfery kontrolowanej przez podmiot niezaufany — czyli z tego, że dane, którymi steruje ktoś z zewnątrz, trafiają tam, gdzie decydują o tym, co zostanie wykonane. Efekt: atakujący wykonuje kod w kontekście roota, bez logowania, bez skomplikowanego łańcucha.
Warto zestawić to z poprzednimi trzema, bo dopiero wtedy widać wzorzec w pełnej okazałości. CVE-2025-3248 — ten sam endpoint walidacji przyjmował dowolny kod w Pythonie i przekazywał go do wykonania bez wymogu logowania; naprawiono, dodając uwierzytelnienie. CVE-2026-33017 — ta sama klasa błędu na endpoincie budującym publiczne przepływy, który z definicji nie może wymagać logowania; naprawiono, ograniczając, co ten endpoint przyjmuje. CVE-2026-10134 — komponent wykonujący kod Pythona przez exec(), gdzie wykonywany tekst pochodził z pola kontrolowanego przez atakującego. A teraz CVE-2026-0770 — powrót do pierwszego endpointu, innym parametrem.
Cztery numery CVE, cztery łatki, jeden niezmienny wzorzec: dane kontrolowane przez użytkownika docierają do miejsca, w którym Langflow wykonuje kod, i nie ma między nimi piaskownicy. Za każdym razem naprawiano konkretną ścieżkę. Za każdym razem znajdowała się następna — a teraz okazało się, że nawet ścieżka uznana za zamkniętą miała drugie wejście.
Eksploatacja trwała, gdy pisaliśmy, że nie ma paniki
Tu wypada uczciwość wobec czytelnika, bo w naszym wpisie sprzed dwóch tygodni jest zdanie, które trzeba dziś skorygować.
Napisaliśmy wtedy, trzymając dyscyplinę i słusznie unikając alarmizmu, że opisywana luka jest załatana, a jej eksploatacja bez logowania wymaga dodatkowego warunku — więc to lekcja architektoniczna, nie zero-day w toku. To było prawdziwe wobec CVE-2026-10134. Ale w tle działo się co innego: firma KEVIntel odnotowała pierwsze próby wykorzystania CVE-2026-0770 już 27 czerwca, a Sysdig obserwował eksploatację innej luki Langflow, CVE-2026-55255, od 25 czerwca. Gdy pisaliśmy o wzorcu jako o problemie projektowym do przemyślenia, ten wzorzec był już od dziesięciu dni wykorzystywany w praktyce, w innym miejscu tego samego kodu.
To nie unieważnia tamtej tezy — raczej ją potwierdza mocniej, niż byśmy chcieli. Ale pokazuje granicę naszego własnego podejścia: gdy postawi się diagnozę „to wróci", łatwo potraktować konkretną, załataną lukę jako mniej pilną, podczas gdy realnym pytaniem jest, którym wariantem wzorzec właśnie wraca. Rozstrzygnięcie „załatane, więc spokojnie" dotyczy jednego numeru CVE, nie klasy.
Czego szukali atakujący
Dane KEVIntel pozwalają zobaczyć, co się faktycznie działo, a nie tylko czego się obawiano. Przed dodaniem luki do katalogu CISA odnotowano ponad 220 prób eksploatacji z 64 unikalnych adresów IP. Większość aktywności to były sprawdzenia wykonania komend i rozpoznanie systemu — czyli standardowe skanowanie. Ale nie wszystko.
Założyciel KEVIntel, Ryan Dewhurst, opisuje, że zaobserwowano też próby pobrania skryptów drugiego etapu oraz sięgania po zmienne środowiskowe, metadane chmury i pliki z poświadczeniami. W innych relacjach pojawia się to samo: instalacja złośliwego oprogramowania oraz wyciąganie poświadczeń AWS, zmiennych środowiskowych i metadanych kontenera.
To jest dokładnie ta lista, którą opisywaliśmy w czerwcu, nazywając Langflow skarbcem kluczy. Platforma do budowania aplikacji AI z natury trzyma w swoim środowisku klucze do wszystkiego, co łączy — modeli, baz, usług chmurowych. Wykonanie kodu na niej nie jest końcem ataku, tylko wejściem do magazynu. Atakujący, którzy sięgali po metadane chmury i pliki poświadczeń, zachowywali się dokładnie tak, jak przewiduje ta teza: nie interesował ich Langflow, tylko to, co Langflow trzyma w kieszeni.
Co z tego wynika dla obrońcy
Pilna czynność jest prosta i nie budzi wątpliwości: zaktualizuj Langflow, a jeśli twoja instancja jest wystawiona do internetu, potraktuj to priorytetowo, bo eksploatacja trwa od blisko miesiąca i nie ogranicza się do skanowania.
Druga rzecz jest ważniejsza i wynika wprost z charakteru tych ataków. Skoro napastnicy sięgali po poświadczenia, sama łatka nie wystarczy — trzeba założyć możliwy wyciek. Rekomendacja jest konkretna: przejrzyj historyczne żądania do /api/v1/validate/code, sprawdź aktywność na hoście, ogranicz dostęp do funkcji walidacji i rotuj wszystkie poświadczenia, które mogły być dostępne dla procesu Langflow — klucze API, dane chmurowe, tokeny do baz. Jeśli twoja instancja była wystawiona w czerwcu i lipcu, rotacja nie jest ostrożnością, tylko higieną powypadkową.
Trzecia jest architektoniczna i to ona jest właściwą lekcją tej serii. Cztery łatki na tę samą klasę problemu w kilkanaście miesięcy — w tym powrót do endpointu uznanego za naprawiony — pokazują, że nie da się tego rozwiązać po stronie dostawcy szybciej, niż atakujący znajdują kolejne warianty. Jedyne, co realnie zmniejsza skutek, jest po twojej stronie: nie uruchamiaj narzędzia, którego funkcją jest wykonywanie dostarczonego kodu, z żywymi kluczami produkcyjnymi w zasięgu procesu, z nieograniczonym dostępem do sieci wewnętrznej i z możliwością sięgnięcia po endpointy metadanych chmury. Traktuj wykonanie kodu na takiej platformie jako stan spodziewany, nie incydent, i buduj granice wokół tego założenia. To jest ta sama zasada, którą postawiliśmy przy Cordyceps — są luki, które nie są błędem do naprawienia, lecz właściwością konstrukcji, i wobec nich obroną jest izolacja, nie kolejna łatka.
Jedna myśl na koniec
Najbardziej pouczające w tej historii nie jest to, że w Langflow znaleziono kolejną lukę. Jest to, że znaleziono ją tam, gdzie już raz szukano — na endpoincie załatanym rok wcześniej, przez parametr, którego przy tamtej naprawie nie objęto. Łatka zamknęła jedną drogę do wykonania kodu i pozostawiła drugą, bo naprawiano konkretne wejście, a nie zdolność, do której to wejście prowadziło. Dopóki tak się łata, każda naprawa jest zaproszeniem do poszukania obok. A gdy CISA po raz pierwszy wydaje w sprawie platformy do budowania agentów AI wiążący nakaz z terminem na trzy dni, to znaczy, że etap „lekcja architektoniczna do przemyślenia" właśnie się skończył.
Źródła
BleepingComputer — informacja o nakazie CISA, opis mechanizmu luki w parametrze exec_globals z cytatami badaczy Trend Micro oraz dane KEVIntel o ponad 220 próbach eksploatacji z 64 adresów IP i charakterze obserwowanych ładunków: https://www.bleepingcomputer.com/news/security/cisa-orders-feds-to-patch-actively-exploited-langflow-rce-flaw/
SecurityOnline — potwierdzenie dodania CVE-2026-0770 do katalogu KEV 21 lipca 2026 wraz z trzema innymi podatnościami oraz kontekst Binding Operational Directive 26-04: https://securityonline.info/cisa-kev-four-exploited-vulnerabilities/
TechTimes — analiza wcześniejszego wejścia Langflow do katalogu KEV jako pierwszej platformy orkiestracji agentów AI, z liczbą odrębnych podatności Langflow w aktywnej eksploatacji: https://www.techtimes.com/articles/319918/20260708/cisa-adds-first-ai-agent-platform-kev-sets-thursday-deadline-4-cves.htm
SecurityWeek — opis wcześniejszej kampanii łączącej lukę IDOR z podatnością zdalnego wykonania kodu w Langflow, obserwowanej przez Sysdig od 26 czerwca: https://www.securityweek.com/cisa-urges-immediate-patching-of-exploited-coldfusion-langflow-joomla-flaws/
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ł