Końcówka, która miała tylko sprawdzać poprawność kodu, ten kod uruchamiała. Drugą połowę problemu stanowi sąsiednia końcówka, wydająca token administratora każdemu, kto się o niego zgłosi po sieci. Złożenie tych dwóch rzeczy daje przejęcie serwera bez logowania, a producent nie podaje na to obejścia doraźnego. Mowa o Langflow, narzędziu do wizualnego składania przepływów sztucznej inteligencji z gotowych klocków. Amerykańska agencja CISA wpisała tę lukę 4 sierpnia do katalogu podatności wykorzystywanych w atakach. Był to szósty wpis tego samego produktu w piętnaście miesięcy i to ta liczba, a nie sama luka, jest tu najciekawsza.
Jak działa luka, przez którą wchodzi się bez logowania
Producent opisuje mechanizm zaskakująco otwarcie, w dwóch krokach. Pierwsza końcówka odpowiada za automatyczne logowanie i wydaje token superużytkownika dowolnemu rozmówcy po sieci. Druga służy do sprawdzania kodu przed uruchomieniem przepływu. Napastnik bierze token z pierwszej, podaje go drugiej i wysyła własny kod w Pythonie.
Najciekawszy jest powód, dla którego samo “sprawdzenie” kodu wystarcza do jego wykonania. IBM pisze, że walidator uruchamiał dekoratory, argumenty domyślne i adnotacje w momencie definiowania funkcji. Po ludzku: żeby zobaczyć, jak wygląda ta funkcja, program musiał wykonać kawałek podanego kodu. Napastnikowi wystarczyło zmieścić polecenia właśnie tam.
Trzeba dodać jedno zastrzeżenie, bo od niego zależy, kogo to dotyczy. Producent pisze, że luka dotyka wszystkich domyślnych wdrożeń, w których automatyczne logowanie jest włączone, a końcówka sprawdzania kodu dostępna z sieci. To nie jest egzotyczna konfiguracja dla wtajemniczonych. To ustawienia, z którymi narzędzie przychodzi z pudełka.
Ocena tej luki wynosi 9,8 w dziesięciostopniowej skali. Rozbicie noty na składniki pokazuje komplet: atak przez sieć, niska złożoność, bez konta i bez udziału użytkownika. Wpływ na poufność, integralność i dostępność jest w każdym z tych trzech wymiarów wysoki.
Katalog CISA: sześć wpisów jednego produktu w piętnaście miesięcy
Tutaj zaczyna się właściwa historia. Pobraliśmy plik katalogu samodzielnie, w wersji z 14 sierpnia liczącej 1665 pozycji, i policzyliśmy wpisy Langflow. Wyszło sześć: maj 2025, marzec, maj, dwa razy lipiec i sierpień 2026. Pięć z nich przypada na sam rok 2026.
Sama szóstka niewiele mówi, dopóki nie zestawi się jej z resztą katalogu. Zgrupowaliśmy więc po nazwie produktu wszystkie pozycje dodane do katalogu od 1 stycznia 2026 roku. Windows ma jedenaście wpisów, zbiorcza pozycja “Multiple Products” dziewięć, SharePoint sześć, a Langflow pięć. Dalej są Office i Cisco Catalyst SD-WAN Manager, po cztery.
Warto od razu powiedzieć, czego ta lista nie znaczy, bo łatwo ją przeczytać na wyrost. “Multiple Products” to worek zbiorczy, nie produkt. Windows siłą rzeczy zbiera najwięcej wpisów, bo jest wszędzie i ma za sobą dekady kodu. Sam katalog bywa przy tym niekonsekwentny w nazewnictwie. SharePoint figuruje w nim raz jako “SharePoint”, raz jako “SharePoint Server”, więc liczenie po surowej etykiecie rozbija jeden produkt na dwa i zaniża wynik o połowę. Mimo tych zastrzeżeń zostaje fakt niewygodny dla całej kategorii. Narzędzie do budowania przepływów AI, znane wąskiej grupie zespołów technicznych, ma w tym roku w katalogu CISA więcej wpisów niż pakiet Office.
Zmieniło się przy okazji coś jeszcze, drobnego z pozoru. W pięciu wcześniejszych wpisach w rubryce producenta stoi “Langflow”. W szóstym stoi IBM, bo dziś to IBM firmuje ten produkt i to on wydał ostrzeżenie. Zmiana nazwy producenta w katalogu nie przerwała jednak serii podatności.
Kurs n8n 2.0 · Kodożercy
Od zera do własnych automatyzacji, bez doświadczenia
Kurs n8n 2.0 od Kodożerców przeprowadzi Cię krok po kroku przez budowanie prawdziwych automatyzacji. Od webhooków, przez integracje z API, po własne przepływy danych – wszystko bez programowania.
Sprawdź kurs n8n 2.0 →
Ta sama końcówka wpuściła atak, który opisywaliśmy wcześniej
Przy porównywaniu wpisów wyszła rzecz, której nie widać w żadnej relacji. Najstarszy wpis Langflow w katalogu, ten z maja 2025 roku, dotyczy dokładnie tej samej końcówki sprawdzania kodu. Nie jest to ta sama luka, bo mechanizm był inny: wtedy końcówka w ogóle nie wymagała logowania.
Tamta luka posłużyła jako droga wejścia w ataku prowadzonym samodzielnie przez agenta AI. Wystawiona do internetu instancja Langflow była wtedy bramą wejściową. Sysdig szacował wówczas, że do sieci wystawiono około siedmiu tysięcy niezałatanych instalacji. Jest to zarazem jedyny wpis Langflow, przy którym katalog CISA odnotowuje użycie w kampanii szyfrującej dane.
Piętnaście miesięcy później ta sama końcówka wymaga już uwierzytelnienia. Problem w tym, że token do tego uwierzytelnienia wydaje sąsiednia końcówka, i to każdemu. Drzwi zostały zamknięte, tylko klucz leży obok, na wycieraczce. Powtarzalność miejsca, w którym rzecz się psuje, mówi o dojrzałości produktu więcej niż pojedyncza ocena 9,8.
Co zrobić, jeśli macie Langflow u siebie
Zalecenie producenta jest krótkie i nie zostawia pola do negocjacji. Trzeba zaktualizować Langflow OSS do wersji 1.10.1. Podatne są wszystkie wydania od 1.0.0 do 1.10.0 włącznie.
Osobno warto zwrócić uwagę na rubrykę obejść doraźnych w ostrzeżeniu IBM. Widnieje w niej wpis “None”, czyli brak jakiegokolwiek obejścia. To rzadkie i istotne, bo przy większości takich luk producent podaje choćby prowizorkę: zablokuj końcówkę, wyłącz funkcję, ogranicz dostęp. Tutaj nie ma czego zablokować, więc do czasu aktualizacji jedynym sensownym krokiem jest odcięcie usługi od sieci. Nie naprawia to podatności, tylko odbiera napastnikowi drogę dojścia.
Zostaje kwestia terminu, którą trzeba postawić jasno, bo bywa źle rozumiana. Katalog wyznaczył datę 7 sierpnia i ona już minęła. Obowiązek prawny wynika jednak z amerykańskiej dyrektywy i wiąże tamtejsze urzędy federalne. Polska firma nie ma z tego tytułu żadnego zobowiązania. Ma za to najlepszy dostępny sygnał, że tę lukę ktoś już wykorzystuje w praktyce. Sama agencja oznaczyła ją jako aktywnie wykorzystywaną 17 lipca, na trzy tygodnie przed wpisem.
Praktyczny wniosek wykracza poza jedno narzędzie. Warto sprawdzić, co jeszcze z klasy “narzędzia do budowania przepływów i automatyzacji” wisi w firmie z dostępem z internetu. Takie rzeczy stawia się zwykle na szybko i rzadko wracają na listę aktualizacji. Blog opisywał identyczny problem przy luce w n8n, a w sierpniu przy trzech wpisach dodanych jednego dnia. Wzorzec się nie zmienia. Niezałatane narzędzie wystawione na zewnątrz jest tańszym celem niż jakakolwiek nieznana podatność.
Podsumowanie
Krytyczna luka w Langflow pozwala przejąć serwer bez logowania. Jedna końcówka wydaje token superużytkownika każdemu, kto o niego poprosi, a druga wykonuje przysłany kod przy samym sprawdzaniu jego poprawności. Ocena wynosi 9,8 na 10 i dotyczy wdrożeń w konfiguracji domyślnej. Producent nie podaje obejścia doraźnego, więc jedyną naprawą jest aktualizacja do wersji 1.10.1, a do czasu jej wykonania usługę trzeba odciąć od sieci. Ważniejszy od pojedynczego błędu jest jednak kontekst. To szósty wpis tego samego produktu w piętnaście miesięcy i piąty w samym 2026 roku, przez co Langflow ma w tym roku więcej pozycji niż pakiet Office. Najstarszy z tych wpisów dotyczy tej samej końcówki sprawdzania kodu. To przez nią rok wcześniej wszedł do cudzej sieci samodzielny agent szyfrujący dane. Dla zespołu z podobnym narzędziem wystawionym do internetu wniosek jest prostszy niż cała ta historia: sprawdzić wersję i sprawdzić, czy usługa w ogóle musi być widoczna z zewnątrz.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
