CVE-2026-9198: Langflow wydawał tokeny superużytkownika każdemu, a następnie wykonywał to, co przesłano

Komunikat IBM dotyczący CVE-2026-9198 opisuje przejęcie Langflow OSS za pomocą dwóch żądań: wywołanie punktu końcowego automatycznego logowania platformy zwraca token bearer superużytkownika każdemu, kto o niego poprosi, a drugie wywołanie przesyła kod Python do punktu końcowego walidacji kodu, który go uruchamia. Producent rejestruje obie połowy tego łańcucha pod osobnymi identyfikatorami — CVE-2026-9103 dla braku uwierzytelniania, CVE-2026-8481 dla wykonania — i ocenia połączenie na 9,8 w CVSS 3.1, dostępne przez sieć bez uprawnień i bez interakcji użytkownika. Domyślne wdrożenia w wersjach od 1.0.0 do 1.10.0 są podatne; poprawką jest 1.10.1, a IBM nie podaje żadnego obejścia. Amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury dodała CVE do swojego katalogu Known Exploited Vulnerabilities 4 sierpnia 2026 r., z federalnym terminem remediacji 7 sierpnia. Wpis, jego znaczniki wagi i szkód oraz powiązane wpisy są przechowywane w Orca AI Incident Archive, który wymienia ten incydent wraz z resztą serii.

Łańcuch, w trzech biuletynach IBM

IBM publikuje tę lukę jako trzy dokumenty, a nie jeden, i to czytanie ich razem sprawia, że mechanizm staje się czytelny. Cały łańcuch to CVE-2026-9198, problem wstrzyknięcia kodu w kategorii CWE-94, oceniony na 9,8 z wektorem AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — dostępny z sieci, o niskiej złożoności, bez uprawnień, bez interakcji użytkownika i o wysokim wpływie na poufność, integralność i dostępność. Jego pierwsza połowa, CVE-2026-9103, to brak uwierzytelniania dla funkcji krytycznej w kategorii CWE-306, również 9,8. Jego druga połowa, CVE-2026-8481, to znowu CWE-94, ale oceniona na 9,9: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, niskie uprawnienia zamiast żadnych oraz zmieniony zakres.

9,9 to uczciwa część arytmetyki. Punkt końcowy walidacji kodu nigdy sam z siebie nie był otwarty dla osób postronnych — IBM opisuje go jako lukę, która pozwalała „dowolnemu uwierzytelnionemu użytkownikowi wykonywać dowolne polecenia systemowe z pełnymi uprawnieniami procesu serwera Langflow”. To, co czyni ten łańcuch nieuwierzytelnionym, to pierwsza połowa: punkt końcowy automatycznego logowania, który według IBM „wystawia długotrwałe tokeny bearer superużytkownika bez wymagania uwierzytelnienia, gdy konfiguracja AUTO_LOGIN jest włączona (domyślnie włączona)”. Biuletyn dodaje, że tokeny mają 365-dniowy okres ważności, i odnotowuje drugą ścieżkę ekspozycji, która przyciąga mniej uwagi — permisywne domyślne ustawienia współdzielenia zasobów między źródłami, zezwalające na źródła z symbolami wieloznacznymi wraz z poświadczeniami, co według IBM „może umożliwić kradzież tokenów przy okazji odwiedzenia dowolnych witryn”.

Część dotycząca wykonania jest warta uwagi. Podsumowanie IBM stwierdza, że walidator „skompilował i wykonał kod przesłany przez użytkownika, w tym ewaluacje zachodzące w czasie definiowania funkcji, takie jak argumenty domyślne i dekoratory”, oraz że atakujący mógłby zatem przemycić wykonywalne wyrażenie do parametru domyślnego lub dekoratora. To nie jest przenośnia dotycząca niebezpiecznego kodu: dekorator jest ewaluowany, gdy otaczająca instrukcja def jest konstruowana, więc żądanie, którego jedynym deklarowanym celem jest sprawdzenie składni funkcji, nadal uruchamia wszystko, co jest do niego dołączone. Powiązany komunikat doradczy samego IBM stwierdza to samo w jednym zdaniu — walidacja i wykonanie były tą samą operacją. Poprawka odnotowana w biuletynie CVE-2026-8481 polegała na „usunięciu wykonywania kodu ze ścieżki walidacji i wykonywaniu wyłącznie kontroli kompilacji”.

Jedną niewielką rozbieżność warto odnotować, ponieważ wpływa ona na polowanie na zagrożenia. Powiązany bulletin podaje punkt końcowy tokena jako /api/v1/auto_login, podobnie jak Cloud Security Alliance i Field Effect; osobny bulletin IBM dotyczący CVE-2026-9103 podaje go jako /api/v1/login/auto_login. Oba dokumenty IBM opisują ten sam punkt końcowy i żaden z nich nie myli się co do zachowania. Ścieżka wykonania jest wszędzie zapisana identycznie: POST /api/v1/validate/code.

Skąd pochodzą daty

Archiwum datuje ten rekord na 6 sierpnia 2026 r. Wpis w katalogu CISA, odczytany 30 października 2026 r., odnotowuje dodanie jako 4 sierpnia 2026 r. i wyznacza termin remediacji na 7 sierpnia. Otaczające doniesienia przypadają po obu stronach daty archiwum, a nie na nią: firma Field Effect opublikowała 5 sierpnia, a cvetodo i krajowy zespół ds. reagowania na incydenty komputerowe w Tajlandii opublikowały 7 sierpnia. Wpis na liście, wynikający z niego termin i artykuły na jego temat to trzy różne zdarzenia, więc te daty się nie wykluczają — ale dwudniowa różnica między polem archiwum a polem CISA jest powodem, by zajrzeć do katalogu, gdy dokładny dzień ma znaczenie.

Ustalenie daty ujawnienia jest trudniejsze, a źródła rzeczywiście się nie zgadzają. Strona biuletynu IBM dotycząca łańcuchowego CVE podaje datę pierwotnej publikacji 2 lipca 2026 oraz datę modyfikacji 17 sierpnia 2026. Field Effect datuje ujawnienie przez IBM na 2 lipca. Nota badawcza Cloud Security Alliance z 18 sierpnia podaje datę ujawnienia oraz towarzyszącego mu wydania 1.10.1 jako 17 lipca; cvetodo twierdzi tak samo. Między tymi dwoma odczytami jest piętnaście dni i żaden z dokumentów nie jest niedbały, więc ten artykuł nie rozstrzyga między nimi. W każdym razie jest ustalone, że poprawka została opublikowana przed umieszczeniem w wykazie KEV oraz że 1.10.1 to wydanie, które ją zawierało.

Dokładna treść wpisu CISA w jego własnych polach jest węższa niż jego nagłówek. Produkt figuruje u dostawcy IBM jako produkt Langflow; luka jest opisana jako „taka, która pozwala nieuwierzytelnionym atakującym uzyskać pełne zdalne wykonanie kodu w domyślnych wdrożeniach Langflow”; znane wykorzystanie w kampaniach ransomware odnotowano jako Nieznane; triage kryminalistyczny jest oznaczony jako wymagany na mocy BOD 26-04; a wymagane działanie polega na zastosowaniu środków zaradczych zgodnie z instrukcjami dostawcy albo na zaprzestaniu używania produktu, gdy środki zaradcze są niedostępne.

Zapis wykorzystania

Wpis CISA twierdzi, że luka została wykorzystana w rzeczywistych atakach. Publiczne dowody stojące za tym twierdzeniem są słabsze, niż sugeruje ocena 9,8. Ani IBM, ani CISA nie wskazały aktora zagrożenia ani nie opublikowały szczegółów zaobserwowanej kampanii — Field Effect mówi to wprost, a nic w trzech biuletynach IBM ani we wpisie KEV temu nie przeczy.

Zamiast tego istnieje telemetria dostawcy przekazywana z drugiej ręki. Notatka Cloud Security Alliance powołuje się na KEVIntel w kwestii twierdzenia, że próby wykorzystania odnotowano począwszy od „około 6 lipca 2026 r.”, kilka tygodni przed ujawnieniem według własnych obliczeń sojuszu, oraz że do połowy sierpnia łączne próby wzrosły do setek, pochodząc z kilkuset unikalnych adresów internetowych rozproszonych w dziesiątkach krajów. Te liczby pochodzą od jednej firmy monitorującej i nie pojawiają się w żadnym innym źródle przejrzanym na potrzeby tego artykułu. Są tu podane, ale nie potwierdzone.

Warto przyjrzeć się bliżej dacie rozpoczęcia. Jeśli próby rzeczywiście rozpoczęły się około 6 lipca, to jest to cztery dni po dacie komunikatu widniejącej na stronie IBM i jedenaście dni przed datą 17 lipca podawaną przez dwa inne źródła. Telemetria nie potwierdza zatem ani nie obala żadnej z tych dat ujawnienia; Cloud Security Alliance podaje oba wyjaśnienia, nie dokonując wyboru, opisując wczesną aktywność albo jako niezależne odkrycie przez oportunistycznych skanerów, albo jako wyciek szczegółów technicznych przed skoordynowanym ujawnieniem.

Publiczny kod exploita jest lepiej udokumentowaną częścią. Field Effect przypisuje publiczny opis łańcucha „publicznemu proof-of-concept opublikowanemu w lipcu 2026 r.” w repozytorium github.com/0xdak/CVE-2026-9198_exploit i twierdzi, że kod pokazuje pozyskanie tokena superużytkownika przez punkt końcowy automatycznego logowania, a następnie użycie go wobec punktu końcowego walidacji. Field Effect nie łączy autora tego repozytorium z żadnym zaobserwowanym wykorzystaniem, podobnie jak ten artykuł. Żadne z przejrzanych źródeł nie zgłasza również potwierdzonej kradzieży danych uwierzytelniających z wykorzystanego hosta: opis pozyskiwania danych uwierzytelniających, który ogólnie towarzyszy podatnościom Langflow, jest oceną dotyczącą tego, co takie host przechowuje, omówioną poniżej, a nie ustaleniem dotyczącym jakiejkolwiek nazwanej ofiary w tym zapisie.

Ustalony, zgłoszony i nieustalony

• Ustalono, że CVE-2026-9198 łączy brak uwierzytelniania w punkcie końcowym automatycznego logowania z wykonaniem kodu w punkcie końcowym walidacji kodu; że IBM ocenia ten łańcuch na 9,8 w ramach CWE-94, a jego dwie części na 9,8 i 9,9; że domyślne wdrożenia Langflow OSS w wersjach od 1.0.0 do 1.10.0 są dotknięte na platformach Windows, macOS i Linux; że 1.10.1 stanowi poprawkę, a IBM nie publikuje żadnego obejścia; oraz że CISA dodała CVE do katalogu KEV z federalnym terminem 7 sierpnia 2026 r. Trzy biuletyny IBM są dokumentami źródłowymi i są zgodne ze sobą co do mechanizmu.

• Niezależnie powtórzone. ThaiCERT powtórzył w swoim komunikacie doradczym z 7 sierpnia 2026 r. ten sam łańcuch obejmujący dwa punkty końcowe, tę samą ocenę 9,8, ten sam zakres podatnych wersji i to samo rozwiązanie w wersji 1.10.1, a ponadto dodał mechanizm kontroli sieciowej, którego nie zawierają biuletyny IBM: nie wystawiać interfejsu administracyjnego Langflow do publicznego internetu i uzyskiwać do niego dostęp wyłącznie przez VPN lub ściśle określoną listę dozwolonych adresów. To potwierdzenie interpretacji komunikatu przez organ rządowy, który nie ma żadnego interesu w brzmieniu tekstu dostawcy — a nie niezależne odkrycie luki.

• Zgłoszone, niepotwierdzone. Każda liczba dotycząca wykorzystania: setki prób, kilkaset adresów, dziesiątki krajów, począwszy od około 6 lipca. Są to dane jednej firmy monitorującej, przekazane przez jednostkę badawczą. Wykaz CISA potwierdza, że doszło do wykorzystania, nie podając jego skali, a w przeglądanym tu materiale nie pojawia się żadne drugie źródło telemetrii.

• Nie ustalono. Brak wskazanej ofiary i wskazanego podmiotu sprawczego. Brak atrybucji do państwa lub grupy przestępczej. Brak potwierdzonej liczby instancji Langflow dostępnych z internetu — cvetodo poinformowało 7 sierpnia, że IBM nie odpowiedział na pytania dotyczące skali wykorzystania — i od tego czasu nie pojawiło się żadne oświadczenie dostawcy określające tę liczbę. Archiwum ocenia ten wpis na poziomie ufności A i nie oznacza go jako spornego, a nic z przeanalizowanych tu materiałów go nie podważa; luki te są lukami w publicznie dostępnych dowodach, a nie w twierdzeniu, że ta podatność istnieje i została wykorzystana.

• Celowo wykluczone.Komunikat doradczy ThaiCERT również opisuje w tym samym tygodniu automatyczne skanowanie kierowane przez AI, ale wiąże je z innym produktem z tej samej partii CISA, a nie z Langflow. Nie stanowi on dowodu dotyczącego tego rekordu i nie jest tu w tej roli wykorzystywany.

Co się zmieniło po debiucie giełdowym?

Środek zaradczy dostawcy to podniesienie wersji i nic więcej. Tabela produktów objętych problemem firmy IBM wymienia Langflow OSS od 1.0.0 do 1.10.0, wskazuje 1.10.1 jako poprawkę i w polu obejść wpisuje „None” — we wszystkich trzech biuletynach. Biuletyn CVE-2026-8481 opisuje zmianę: walidator przestał wykonywać, a zaczął kompilować. Biuletyn CVE-2026-9103, obejmujący część dotyczącą automatycznego logowania, nie opisuje swojej poprawki równie szczegółowo, a żaden z przejrzanych tutaj dokumentów IBM nie podaje daty wydania 1.10.1.

Zalecenia wszystkich pozostałych idą dalej niż zalecenia dostawcy. Cloud Security Alliance zaleca przeprowadzenie aktualizacji, a następnie zweryfikowanie w czasie działania, że punkt końcowy automatycznego logowania nie wydaje już tokenów nieuwierzytelnionym wywołującym, zamiast polegać na ciągu wersji — podanym przez nią powodem jest to, że wcześniejsze łatki Langflow zawierały niekompletne poprawki. Zaleca również wyraźne ustawienie zmiennej środowiskowej LANGFLOW_AUTO_LOGIN na false, aby platforma wymagała prawdziwych danych uwierzytelniających zamiast je generować, oraz traktowanie każdej instancji, która od początku lipca była wystawiona na internet, jako skompromitowanej do czasu przeglądu logów, z rotacją danych uwierzytelniających dla wszystkiego, do czego instancja mogła mieć dostęp: kluczy dostawców modeli, danych uwierzytelniających baz danych i kluczy usług w chmurze. ThaiCERT dodaje część sieciową — brak interfejsu administracyjnego w publicznym internecie, dostęp wyłącznie przez VPN lub listę dozwolonych. Oba zestawy zaleceń pochodzą od badaczy. IBM nie publikuje żadnych.

W materiale źródłowym znajduje się jedna wzmianka o autorze. IBM w swoim potwierdzeniu przypisuje zgłoszenie Harish Kolla, którego nazwa użytkownika GitHub to Har1sh-k. Cloud Security Alliance w notatce z 18 sierpnia określa CVE-2026-9198 jako czwartą odrębną lukę w Langflow polegającą na braku uwierzytelnienia lub obejściu autoryzacji, która trafiła do katalogu CISA w ciągu około pięciu miesięcy, wymieniając trzy wcześniejsze identyfikatory; jej interpretacja jest taka, że wzorzec ten odzwierciedla powtarzające się fragmentaryczne naprawianie jednego modelu uwierzytelniania i wykonywania kodu, a nie niepowiązane defekty. To ujęcie jest oceną sojuszu, przedstawioną w notatce badawczej; nie jest ustaleniem niezależnego audytora, a żadne analizowane tu źródło nie odnotowuje publicznej odpowiedzi maintainerów na nią.

Co lista KEV rozstrzyga, a czego nie rozstrzyga

Katalog CISA jest stwierdzeniem zaobserwowanego wykorzystania, a nie raportem o incydencie, i ten wpis trzyma się tej formuły. Mówi, że luka została wykorzystana; nie mówi, przeciwko komu, przez kogo ani jak często. Wykorzystanie przez ransomware zapisano jako Nieznane. Nic nie zostało skwantyfikowane. Wpis rozstrzyga natomiast jedną kwestię, której nie rozstrzygnie ocena istotności: czy luka przeszła od działającego proof of concept do rzeczywistego wykorzystania. Dla organizacji poza zakresem BOD 26-04 — a jest to większość świata — termin 7 sierpnia nie nakłada żadnego obowiązku, a stojący za nim fakt ma taką samą wagę, jaką miałby, gdyby wiązał się z nim obowiązek.

Cloud Security Alliance wyciąga z tego samego wpisu wniosek operacyjny: że umieszczenie na liście KEV jest wiarygodnym sygnałem, iż eksploatacja wyszła poza etap proof-of-concept, oraz że w przypadku tej luki nastąpiło to około miesiąca po pierwszych odnotowanych próbach. Kto czekał na katalog przed triage’em, według tej interpretacji reagował już na incydent, a nie mu zapobiegał. Czy opisuje to konkretne wdrożenie, to pytanie do jego logów — para punktów końcowych, której należy szukać, to ta udokumentowana przez IBM, a zapis nie wskazuje ani jednej ofiary, względem której można by sprawdzić odpowiedź.