Langflow CVE-2026-0768: dwunasta w tym roku luka w Langflow wykorzystywana w rzeczywistych atakach

CVE-2026-0768 to nieuwierzytelniona luka zdalnego wykonania kodu w Langflow, otwartoźródłowym wizualnym frameworku do składania potoków i agentów dużych modeli językowych, a do końca sierpnia 2026 r. atakujący wykorzystywali ją w rzeczywistych atakach. Luka znajduje się w walidatorze kodu stojącym za edytorem komponentów niestandardowych Langflow: punkt końcowy validate przyjmuje parametr code i wykonuje zawarty w nim kod Python, bez uwierzytelniania i – jak ujmuje to Zero Day Initiative – „w kontekście roota”. Sieć honeypotów Canary firmy VulnCheck odnotowała ponad 50 prób wykorzystania w ciągu kilku godzin od pierwszych wykryć 30 sierpnia 2026 r. i ponad 360 do poniedziałku 1 września – wszystkie wymierzone w czujniki w Wielkiej Brytanii; Caitlin Condon z VulnCheck powiedziała, że ruch źródłowy pochodził głównie z Rosji. Żądania nie były oprogramowaniem ransomware. Odczytywały zmienne środowiskowe zawierające poświadczenia superużytkownika Langflow, klucze API OpenAI oraz klucze dostępu i tajne klucze AWS, a następnie zaglądały do /root/.cache/langflow/secret_key, .ssh i .bash_history. Pełny wpis archiwum dotyczący tego incydentu, obejmujący jego klasyfikacje ważności, pewności i szkód, znajduje się w the Orca AI Incident Archive, obok pozostałych rekordów dotyczących kradzieży poświadczeń i infrastruktury AI, które go otaczają.

Security Affairs opublikował swoją relację 2 września 2026 r.; Ionut Arghire z SecurityWeek poinformował o wykorzystaniu dzień wcześniej, Bill Toulas z BleepingComputer relacjonował to w tym samym tygodniu, a AI Safety Initiative Cloud Security Alliance 4 września dołączyła z notą badawczą, która ponownie omawia mechanizm i dodaje zalecenia. Żadna z relacji przejrzanych na potrzeby tego artykułu nie wymieniła organizacji, której systemy zostały naruszone. Wszystko prowadzi z powrotem do własnych czujników VulnCheck i do biuletynu, który Zero Day Initiative opublikowała w styczniu.

Edytor, który wykonuje to, co ma zweryfikować

Atutem Langflow jest to, że aplikację AI składasz, przeciągając komponenty na kanwę. Komponenty niestandardowe są w Pythonie: edytor pozwala użytkownikowi wkleić kod i nacisnąć przycisk walidacji, a serwer go sprawdza. Według biuletynu ZDI ZDI-26-034 ta weryfikacja uruchamia kod. Zdanie opisujące pierwotną przyczynę w biuletynie to jedna linia — „brak odpowiedniej walidacji ciągu znaków dostarczonego przez użytkownika przed użyciem go do wykonania kodu Python” — a skutkiem jest to, że pojedyncze nieuwierzytelnione żądanie HTTP wykonuje dowolny kod Python na hoście.

Trzy właściwości sprawiają, że staje się to incydentem, a nie zgłoszeniem błędu. Wektor CVSS to AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H z wynikiem 9,8: osiągalny przez sieć, o niskiej złożoności, bez wymaganych uprawnień, bez interakcji użytkownika oraz całkowita utrata poufności, integralności i dostępności. Kontekstem wykonania jest root, dlatego polecenia atakującego, które zarówno Condon, jak i Cloud Security Alliance opisują jako kierujące się do /root/.cache/langflow/secret_key — pliku, którego Langflow używa do szyfrowania przechowywanych danych uwierzytelniających i danych sesji. A punkt końcowy w ogóle nie wymaga danych uwierzytelniających, więc ekspozycja jest funkcją samej osiągalności.

Historia ujawnienia ma znaczenie dla sposobu, w jaki to się potoczyło. Oś czasu ZDI odnotowuje, że zgłoszenie dotarło do konta Langflow na GitHubie 18 lipca 2025 r., prośbę o aktualizacje 11 września 2025 r., prośbę o poprawkę 10 października 2025 r. oraz zawiadomienie o zamiarze opublikowania jako zero-day 10 grudnia 2025 r. ZDI opublikowało biuletyn 9 stycznia 2026 r. Wymienieni badacze to Peter Girnus, William Gamazo Sanchez i Alfredo Oliveira z Trend Research. Baza biuletynów GitHub zawiera ten sam tekst jako GHSA-x5pr-rvjj-j6qm, opublikowany 23 stycznia 2026 r., sklasyfikowany jako CWE-94, i nie wymienia żadnego zakresu wersji, których dotyczy. Deklarowane przez ZDI środki zaradcze nie są poprawką: polegają na „ograniczeniu interakcji z produktem”.

Publiczne doniesienia lokują zakres objętych problemem wersji na wydania Langflow do 1.4.2 włącznie — wersji, względem której zbudowano i przetestowano później dodany moduł Metasploit. Na tym kończy się pewność, a poniższa sekcja dotycząca poprawek wyjaśnia dlaczego.

Co detekcje 360 ustalają, a czego nie ustalają

Canaries firmy VulnCheck to wystawione do internetu czujniki zaprojektowane tak, by wyglądać jak to, czego szuka skanujący atakujący. Firma zaobserwowała pierwsze wykorzystanie CVE-2026-0768 w dniach 29–30 sierpnia 2026 r.: w niedzielę w ciągu kilku godzin wykryto ponad 50 przypadków, a do poniedziałku liczba ta wzrosła powyżej 360. Condon, wiceprezes VulnCheck ds. badań nad zagrożeniami, opisał tę aktywność na LinkedIn jako „mieszankę rozpoznania i pozyskiwania danych uwierzytelniających”, dodając, że ruch źródłowy pochodził głównie z Rosji i „jak dotąd trafiał wyłącznie w Canaries w Wielkiej Brytanii”.

Sekwencja poleceń zarejestrowana przez czujniki jest wystarczająco konkretna, by stanowić playbook. Atakujący odpytywali środowisko o LANGFLOW_SUPERUSER, o zmienne pasujące do OPENAI_API oraz o klucze AWS_ACCESS i AWS_SECRET — trzy rodziny poświadczeń, które host Langflow najprawdopodobniej przechowuje. Odczytali buforowany klucz tajny w /root/.cache/langflow/secret_key. Sprawdzili dostęp do .ssh i zbadali rozmiar .bash_history, co wskazuje, czy operator może przemieszczać się lateralnie, a nie tylko odczytywać sekrety. Społecznościowe opracowanie tego łańcucha, cytowane przez Cloud Security Alliance, dodaje, że ta sama aktywność przeszukiwała drzewa źródeł i pliki .env w poszukiwaniu osadzonych sekretów, eksfiltrowała to, co znalazła, oraz sprawdzała, czy host został już backdoorowany przez wcześniejszego operatora, zanim dodano własną persistence.

To, co to ustala, to fakt, że exploit działa, że został użyty przeciwko wystawionym do internetu instancjom Langflow i że celem były poświadczenia, a nie zakłócenie działania. Nie ustala natomiast ofiary. Kanarki to wabiki; wykrycie jest żądaniem, a nie potwierdzoną kradzieżą. Archiwum klasyfikuje ten zapis jako rzeczywistą szkodę, a szkoda udokumentowana w publicznych źródłach to potwierdzone wykonanie kodu pozyskującego poświadczenia przeciwko wystawionym systemom — a nie nazwana organizacja, której klucze wykorzystano.

Jeden szczegół przeczy zwykłej opowieści o ujawnianiu. Według VulnCheck, gdy rozpoczęto eksploatację, nie istniał publiczny proof-of-concept dla CVE-2026-0768. Komunikat doradczy był dostępny publicznie od prawie ośmiu miesięcy i opisywał lukę wystarczająco precyzyjnie, aby ktoś mógł na podstawie samego tekstu zbudować exploit. Jak podaje The Hacker News, firma interpretuje to jako niezależne opracowanie, a nie ponowne wykorzystanie wyciekłego kodu.

Dwanaście wad, piętnaście tysięcy prób — i gdzie te liczby się załamują

Statystyka, która nadaje temu incydentowi wagę, pochodzi od VulnCheck i warto zacytować ją własnymi słowami firmy, a nie ją parafrazować. „Przed 2026 rokiem dowody wskazywały tylko na jedną lukę w Langflow znaną jako wykorzystywaną w rzeczywistych atakach” – stwierdziła firma. „W 2026 roku sytuacja zmieniła się szybko”. SecurityWeek podaje, że VulnCheck śledzi „11 dodatkowych luk, będących celem ataków i zgłoszonych jako wykorzystywane w rzeczywistych warunkach” w 2026 roku.

Dodaj je, a otrzymasz dwanaście wykorzystanych podatności Langflow, z których jedna pochodzi sprzed tego roku. To nie to samo co dwanaście w 2026 roku, a źródła wahają się między tymi dwoma ujęciami. Nagłówek Forkast nazywa CVE-2026-0768 „12. wykorzystanym CVE Langflow w 2026 roku”, podczas gdy treść tego samego artykułu opisuje tę dwunastkę jako „11 nowych podatności i jedną zidentyfikowaną przed początkiem roku”. Tytuł wpisu podąża za nagłówkiem. Ściśle rzecz biorąc, na 2026 rok przypada jedenaście z dwunastu, a dwunasta — ta znana przed tym rokiem — dopełnia całości.

Liczba 15 000 ma porównywalną wymowę. SecurityWeek, The Hacker News i Forkast przypisują „ponad 15 000 udanych ataków” trzem wskazanym podatnościom: CVE-2026-0769, CVE-2025-3248 i CVE-2026-5027. To duża liczba, ale stanowi sumę dla trzech CVE, a nie dla całego portfolio Langflow na 2026 rok. Ujęcie jej jako prób wykorzystania wobec całego portfolio — jak robi to podsumowanie archiwum — jest szersze niż to, co opublikował VulnCheck.

Poszczególne wpisy stojące za tym wzorcem są udokumentowane. CVE-2025-3248 to luka polegająca na wstrzyknięciu kodu w tym samym punkcie końcowym /api/v1/validate/code, załatana w Langflow 1.3.0 przez zastąpienie wykonywania kodu walidacją ograniczoną wyłącznie do kompilacji, zgodnie z biuletynem doradczym GitHub GHSA-rvqx-wpfh-mfx7, na który powołuje się Cloud Security Alliance — co oznacza, że CVE-2026-0768 to ta sama klasa błędu w tej samej ścieżce kodu, około cztery miesiące po wydaniu tej poprawki. CVE-2026-33017, nieuwierzytelnione RCE w publicznym punkcie końcowym budowania przepływów, zostało uzbrojone w ciągu około 20 godzin od ujawnienia w marcu 2026 r. i wykorzystane do przejęcia poświadczeń OpenAI, Anthropic i AWS, zanim przestawiono się na kopanie kryptowaluty Monero, według relacji Cloud Security Alliance. Nota tej samej organizacji z 12 czerwca 2026 r. obejmuje CVE-2026-5027, lukę typu path traversal w punkcie końcowym przesyłania plików, którą badacze powiązali ze sponsorowaną przez państwo irańską grupą MuddyWater, a jej nota z 4 września odnotowuje CVE-2026-55255, obejście autoryzacji pozwalające uwierzytelnionemu użytkownikowi uruchamiać przepływy innego użytkownika, które 7 lipca 2026 r. trafiło do katalogu Known Exploited Vulnerabilities prowadzonego przez CISA. Te cztery łączy ten sam wzorzec: punkt końcowy, w którym pominięto albo uwierzytelnianie, albo sanityzację, w platformie, której zadaniem jest przechowywanie poświadczeń do wszystkiego, z czym się komunikuje.

Dlaczego platforma orkiestracji jest warta zachodu

Produkcyjna instancja Langflow jest skonfigurowana z kluczami API dostawców, poświadczeniami chmurowymi, parametrami połączenia z bazami danych i sekretami integracji, ponieważ uruchamiane przez nią przepływy potrzebują ich w momencie wywołania. Przejęcie hosta daje więc działający dostęp do każdej usługi, której poświadczenia przechowuje instancja. Skradzione klucze OpenAI lub Anthropic pozwalają atakującemu obciążyć ofiarę kosztami wnioskowania lub podszyć się pod organizację wobec dalszych usług; skradzione klucze AWS otwierają infrastrukturę znacznie wykraczającą poza kontener Langflow. To właśnie ta dźwignia, a nie jakakolwiek zdolność specyficzna dla AI, była celem zaobserwowanych poleceń.

Ocena Cloud Security Alliance jest taka, że nawracanie problemów w czterech różnych podsystemach Langflow w ciągu jednego roku — walidatorze kodu, publicznym punkcie końcowym budowania przepływu, przesyłaniu plików i wykonywaniu przepływów — wskazuje na systemową lukę w inżynierii bezpieczeństwa, a nie na serię niepowiązanych defektów. To ocena sojuszu przedstawiona w notatce badawczej, a nie ustalenie niezależnego audytora, i Langflow nie odpowiedział na nią publicznie w materiałach przejrzanych w tym miejscu.

Co zostało naprawione, a co nadal pozostaje niejasne

To najsłabszy element publicznej dokumentacji i warto dokładnie wyjaśnić dlaczego. Biuletyn ZDI nie wskazuje żadnej wersji z poprawką. Wpis w bazie Snyk dla tego CVE podaje jako wersje podatne wszystkie wersje przed 1.10.1 i zaleca aktualizację do 1.10.1 lub nowszej. Publiczne doniesienia, w tym SecurityWeek i Security Affairs, opisują zakres podatności jako wersje do 1.4.2 włącznie, ale nie wskazują żadnej wersji z poprawką. Cloud Security Alliance zauważyła 4 września, że opiekunowie Langflow nie opublikowali dedykowanego biuletynu bezpieczeństwa wskazującego to CVE oraz że trackery nie zgadzały się co do tego, która wersja faktycznie usunęła podatność — zdaniem sojuszu ta niejednoznaczność przypomina wcześniejszy przypadek Langflow, w którym wersja zgłoszona jako poprawiona nadal pozwalała na wykorzystanie podatności.

Langflow rzeczywiście wydał poprawki we właściwym obszarze i we właściwym dniu. Wersja 1.11.6 została opublikowana 1 września 2026 r., w poniedziałek, gdy liczba trafień w honeypota przekroczyła 360, a jej informacje o wydaniu opisują backport poprawek bezpieczeństwa, w tym „zamknięcie luk w skanowaniu kodu komponentów” i „rozwiązywanie adnotacji bez wykonywania” (pull request 14876). Wersja 1.12.0 ukazała się tego wieczoru. Później kontynuowano dalsze utwardzanie tej samej ścieżki kodu: późniejszy pull request zatytułowany „powstrzymanie validate_code przed wykonywaniem importów” wskazuje, że endpoint validate nadal był zaostrzany tygodnie po pierwszym wykorzystaniu. Żadne z tego nie stanowi oświadczenia dostawcy, że CVE-2026-0768 zostało naprawione w nazwanym wydaniu, i nie znaleziono takiego oświadczenia w źródłach cytowanych w zapisie.

To, co zmieniło się po stronie atakującego, jest jaśniejsze. Moduł exploita Metasploit dla tej luki został otwarty jako pull request 2 września 2026 r. — tego samego dnia, w którym opublikował Security Affairs — i scalony 8 października 2026 r., przetestowany na Langflow 1.4.2. Niezależnie od stanu pierwotnego opracowania, wykorzystywanie tej luki przestało wymagać samodzielnej pracy sześć tygodni po rozpoczęciu jej wykorzystywania.

Zalecana reakcja Cloud Security Alliance to sekwencja łatania i rotacji, a nie samo łatanie: zweryfikuj uruchomioną wersję i przejdź na bieżące stabilne wydanie; każdą instancję wystawioną na internet w wersji, której dotyczy problem, traktuj jako przejętą, dopóki nie zostanie udowodnione inaczej, ponieważ zaobserwowana aktywność to ciche pozyskiwanie danych, a nie widoczne zakłócenia; oraz przeprowadź rotację każdego sekretu, do którego instancja mogła dotrzeć — hasła superużytkownika Langflow, kluczy API dostawców, kluczy dostępu i tajnych kluczy AWS oraz samego klucza tajnego Langflow — ponownie szyfrując przechowywane poświadczenia, a nie tylko zastępując plik. Zaleca również audyt dzienników dostępu pod kątem żądań do punktu końcowego validate, sprawdzenie authorized_keys pod kątem nieznanych kluczy SSH oraz poszukiwanie dowodów, że poprzedni operator już zainstalował backdoor na hoście. Jeśli platforma musi pozostać osiągalna, sugeruje ograniczenie lub wyłączenie punktu końcowego validate i odejście od długotrwałych kluczy o wysokich uprawnieniach przechowywanych bezpośrednio w platformie.

Ustalony, zgłoszony i nieustalony

Ustalono: że CVE-2026-0768 to nieuwierzytelnione RCE w punkcie końcowym validate Langflow, które wykonuje Python jako root, udokumentowane w ZDI-26-034 i odzwierciedlone jako GHSA-x5pr-rvjj-j6qm; że eksploatacja rozpoczęła się 29–30 sierpnia 2026 r.; że VulnCheck odnotował ponad 50 wykryć w ciągu kilku godzin i ponad 360 do 1 września, wobec czujników w Wielkiej Brytanii, przy czym ruch pochodził głównie z Rosji; oraz że zaobserwowane żądania były skierowane na dane uwierzytelniające superużytkownika Langflow, OpenAI i AWS oraz buforowany klucz tajny, .ssh i .bash_history. Pochodzą one z samego biuletynu i z telemetrii VulnCheck, o których niezależnie informowały SecurityWeek, Security Affairs i The Hacker News.

Zgłoszone, niezweryfikowane niezależnie: każda liczba wykryć. Liczby 50, 360 i 15 000 to własne dane VulnCheck, opublikowane przez tę firmę i powtarzane przez redakcje, które podają ją jako źródło; żadna inna sieć honeypotów nie opublikowała potwierdzającej liczby. Przypisanie do rosyjskiej infrastruktury jest również interpretacją ruchu źródłowego dokonaną przez VulnCheck, a nie oceną, którą jakikolwiek rząd lub CERT potwierdziłby w przejrzanych materiałach.

Nie ustalono: że jakakolwiek nazwana organizacja utraciła poświadczenia. W źródłach tego zapisu nie zidentyfikowano żadnej ofiary. Nie ma też potwierdzonej wersji z poprawką: ZDI nie wskazuje żadnej, Snyk podaje 1.10.1, doniesienia podają, że problem dotyczy wersji do 1.4.2, a informacje o wydaniu 1.11.6 opisują poprawki bezpieczeństwa bez wiązania ich z tym CVE. Nie jest też wewnętrznie spójna liczba „dwunasta luka 2026 r.” w jej własnych źródłach, jak przedstawiono powyżej.

To, co powinno niepokoić osoby, które instalują poprawki według harmonogramu

Ośmiomiesięczna luka to najważniejszy wniosek. CVE-2026-0768 opublikowano jako zero-day 9 stycznia 2026 r., z wystarczająco szczegółowym opisem technicznym, by na jego podstawie można było odtworzyć exploit, a mimo to aż do ostatniego weekendu sierpnia nie odnotowano żadnej aktywności wobec czujników VulnCheck. Potem w ciągu trzech dni napłynęło kilkaset prób, ze strony operatorów, którzy – według firmy – nie mieli publicznego exploita, którego mogliby skopiować. Cokolwiek sprawiało, że te instancje przez osiem miesięcy pozostawały niezałatane mimo publicznego krytycznego biuletynu bezpieczeństwa, jest tym samym, co sprawiło, że luka stała się warta wykorzystania, gdy ktoś w końcu napisał kod.

To również domyka pętlę, którą otworzyły wcześniejsze luki CVE w Langflow. CVE-2025-3248 naprawiono, usuwając wykonywanie kodu z tej samej ścieżki validate; CVE-2026-0768 mimo to wykonuje się na tej ścieżce. Poprawka, która usuwa zachowanie, nie usuwając decyzji projektowej, która je wywołała, kupuje czas — a w tym przypadku kupiła około czterech miesięcy.