Jeśli używasz Langflow — zaktualizuj natychmiast do wersji 1.3.0 lub nowszej i obróć wszystkie poświadczenia przechowywane w instancji: tokeny API, klucze do połączonych usług, sekrety integracji. Sama łatka nie wystarczy, jeśli klucze już wyciekły. Termin CISA dla agencji federalnych minął dziś, 4 czerwca — dla wszystkich innych to rozsądny próg, nie sufit.
21 maja CISA dodała CVE-2025-34291 — krytyczną podatność w platformie Langflow — do katalogu Known Exploited Vulnerabilities. CVSS 9.4. Powód wpisu: aktywna eksploatacja w praktyce, w tym przez irańską grupę państwową MuddyWater, która używa jej do uzyskania początkowego dostępu do sieci celów.
Ale najważniejsze w tej historii nie jest samo RCE. Najważniejsze jest to, co atakujący dostaje po RCE — i dlaczego platformy AI workflow są celem innej kategorii niż zwykła aplikacja webowa.
Co dokładnie jest podatne
Langflow to platforma low-code do budowania przepływów pracy agentów AI — wizualne łączenie modeli, narzędzi i usług w automatyzacje. Jest popularna właśnie dlatego, że upraszcza spinanie wielu usług w jeden przepływ.
Podatność CVE-2025-34291 jest błędem walidacji pochodzenia (origin validation error), który — jak opisała firma Obsidian Security w grudniu 2025 — łączy trzy słabości leżące jedna na drugiej: nadmiernie permisywną konfigurację CORS, brak ochrony przed CSRF, i endpoint, który z założenia pozwala na wykonanie kodu. To jest kombinacja, która przechodzi przez code review, gdy wszyscy się spieszą.
Każda z tych trzech słabości z osobna byłaby problemem do naprawienia. Razem tworzą łańcuch: brak walidacji pochodzenia i brak CSRF pozwalają atakującemu wywołać z zewnątrz endpoint, który wykonuje kod — prowadząc do przejęcia konta i zdalnego wykonania kodu na instancji Langflow.
Sednem nie jest RCE. Sednem jest skarbiec.
Tu jest teza, która czyni tę podatność groźniejszą, niż sugeruje nawet CVSS 9.4.
Jon McLachlan z Cyberbase ujmuje to wprost: groźne nie jest RCE na samej instancji Langflow. Groźne jest to, co Langflow przechowuje. Platforma workflow tego typu trzyma tokeny dostępu i klucze API do każdej usługi, z którą się integruje. Udany exploit na instancji Langflow staje się więc włamaniem do skarbca kluczy — z poświadczeniami do tuzina połączonych aplikacji SaaS.
Obsidian Security nazwało to „kaskadową kompromitacją" (cascading compromise) — i to określenie jest trafne. Atakujący nie zatrzymuje się na przejętej instancji Langflow. Używa kluczy w niej przechowywanych, by wejść do każdej usługi downstream: dostawców modeli, baz danych, integracji SaaS, wewnętrznych narzędzi automatyzacji, środowisk chmurowych. Jedno wejście, wiele poświadczeń.
To jest dokładnie ta zmiana, którą opisywaliśmy w Radarze jako infrastrukturę AI stającą się linią frontu, i którą widzieliśmy przy Miasmie zbierającej tożsamości chmurowe. Cel ataku przesuwa się z danych na klucze. Platforma AI jest atrakcyjna nie dlatego, że ma cenne dane w środku, ale dlatego, że ma klucze do wszystkiego dookoła. Im więcej usług spina przepływ AI, tym większy skarbiec — i tym większy blast radius jednego RCE.
MuddyWater i dlaczego to znaczy „nie tylko MuddyWater"
Szczegół, który podnosi wagę tej podatności: w marcu 2026 Ctrl-Alt-Intel udokumentował, że irańska grupa MuddyWater używa CVE-2025-34291 do uzyskania początkowego dostępu.
MuddyWater to grupa powiązana z irańskim Ministerstwem Wywiadu (MOIS), z długą historią kradzieży poświadczeń jako pierwszego ruchu. Raport OASIS Security opisuje kampanię zgodną z tradecraftem MuddyWater, wymierzoną w sektory krytyczne Bliskiego Wschodu — Egipt, Izrael, Zjednoczone Emiraty Arabskie — z masowym rozpoznaniem pod kątem CVE-2025-34291 i przejściem od skanowania podatności do nadużycia poświadczeń, w tym brute-force na systemy poczty OWA.
Dla MuddyWater Langflow jest racjonalnym wyborem właśnie z powodu mechanizmu skarbca: jeden przyczółek, wiele poświadczeń. To jest dokładnie to, czego szuka aktor, którego pierwszym ruchem jest kradzież danych dostępowych.
Ale McLachlan wyciąga z tego wniosek, który jest ważniejszy niż sama atrybucja: jeśli MuddyWater używa czegoś jako wektora początkowego dostępu, można założyć, że dwie czy trzy inne grupy znalazły tę samą ścieżkę niezależnie. Atrybucja do konkretnej grupy państwowej nie oznacza, że to zagrożenie niszowe. Oznacza, że ścieżka jest na tyle wartościowa, że sięgnął po nią aktor państwowy — a to jest sygnał dla wszystkich pozostałych.
„KEV to podłoga, nie sufit"
Jest tu wątek, który łączy ten wpis z dzisiejszym tekstem o wycieku NTLM bez CVE i majowym o CERT-In — filozofia priorytetyzacji łatania.
CVE-2025-34291 trafił do KEV 21 maja. Ale eksploatacja przez MuddyWater była dokumentowana już w marcu — dwa miesiące wcześniej. To jest ta sama obserwacja, którą McLachlan cytuje za gościem swojego podcastu: KEV to podłoga, nie sufit. Jeśli coś jest w katalogu znanych eksploatowanych podatności, już jesteś spóźniony — faktyczna eksploatacja zaczęła się tygodnie albo miesiące wcześniej.
To samo widzieliśmy dziś z dwóch innych stron: Microsoft odmawiający CVE realnemu błędowi i HTTP/2 Bomb, gdzie łatka stała się mapą dla AI. Wspólny wniosek: katalogi i numery CVE są niezbędne, ale są wskaźnikiem opóźnionym. Organizacja, która traktuje wpis do KEV jako moment rozpoczęcia działania, reaguje na coś, co dla atakujących jest już historią.
Warto też odnotować, że w tym samym tygodniu CISA otworzyła publiczny formularz nominacji do KEV — pozwalając badaczom i firmom zgłaszać podatności do katalogu. To jest przyznanie wprost, że wewnętrzny pipeline CISA nie nadąża za wolumenem ujawnień — katalog był aktualizowany sześć razy w dwa tygodnie i liczy już około 1600 pozycji. Crowdsourcing wejścia to próba skrócenia tej pętli opóźnienia.
Co zrobić
Zaktualizuj Langflow do wersji 1.3.0 lub nowszej. Jeśli instancja była wystawiona na internet, zakładaj, że poświadczenia w niej przechowywane mogły wyciec.
Obróć wszystkie sekrety przechowywane w Langflow — tokeny API, klucze do usług downstream, poświadczenia integracji. To jest krok, którego sama łatka nie zastępuje: jeśli atakujący już zebrał klucze, naprawa podatności nie unieważnia tego, co ukradł.
Zinwentaryzuj wszystkie platformy AI workflow w organizacji, nie tylko Langflow. McLachlan wskazuje na strukturalnie podobne ryzyko w n8n, Make, Zapier z integracjami AI, Pipedream i innych builderach agentów. Wzorzec skarbca — low-code orkiestrator AI trzymający poświadczenia do wielu systemów — powtarza się w całej kategorii. Trzeba wiedzieć, które są w użyciu, gdzie są hostowane i do czego mają dostęp.
Przejrzyj, jak wykrywasz kradzież tokenów OAuth i nadużycie kluczy API. Jeśli twój stos detekcji jest skupiony głównie na endpoincie i sieci, nie zobaczysz fazy kaskady — ruchu SaaS-do-SaaS — dopóki poświadczenia nie zostaną już użyte gdzieś downstream. To jest nowy rodzaj ruchu bocznego, a narzędzia widoczności w większości programów jeszcze za nim nie nadążają.
Zaktualizuj plan reagowania na incydenty o scenariusz kaskady integracji AI. Jeśli instancja Langflow zostanie przejęta — kogo wołasz w każdej usłudze downstream, by unieważnić tokeny? Jak szybko obrócisz poświadczenia w kilkunastu połączonych aplikacjach? Jeśli odpowiedź brzmi „jakoś byśmy to ogarnęli", to jest luka do zamknięcia przed incydentem.
Źródła
The Hacker News — wpis CVE-2025-34291 do KEV i kontekst MuddyWater: https://thehackernews.com/2026/05/cisa-adds-exploited-langflow-and-trend.html
Cyberbase / Jon McLachlan — analiza „skarbca kluczy" i znaczenia dla obrońców: https://www.cyberbase.ai/blog/cisa-kev-langflow-apex-one-what-security-leaders-should-do
OASIS Security — kampania zgodna z tradecraftem MuddyWater wymierzona w Bliski Wschód: https://oasis-security.io/blog/260414-Iran
Ctrl-Alt-Intel — pełny profil MuddyWater i lista eksploatowanych CVE: https://ctrlaltintel.com/research/MuddyWater/
Obsidian Security — pierwotna analiza łańcucha trzech słabości w Langflow: https://www.obsidiansecurity.com/blog/langflow-cve-2025-34291
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ł