CVE-2025-3248 w Langflow: krytyczne RCE bez logowania

CVE-2025-3248 to krytyczna podatność Langflow umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia. Luka ma CVSS 9,8, dotyczy wersji wcześniejszych niż 1.3.0, a 5 maja 2025 r. trafiła do katalogu CISA Known Exploited Vulnerabilities. Wystawiona do Internetu instancja narzędzia do budowania przepływów AI może więc stać się bezpośrednim punktem wejścia do serwera, sekretów modeli i połączonych systemów.

Co zrobić teraz: zaktualizuj Langflow do wspieranej wersji co najmniej 1.3.0, usuń interfejs administracyjny z publicznego Internetu, obróć klucze dostępne procesowi i przeanalizuj logi. Wpis KEV oznacza potwierdzone wykorzystanie, dlatego patchowanie bez threat huntingu jest niepełne.

CVE-2025-3248 — najważniejsze fakty

Parametr	Wartość
Produkt	Langflow
Podatne wersje	wszystkie wcześniejsze niż 1.3.0
Wersja z poprawką	1.3.0 i nowsze wspierane wydania
CVSS	9,8 — krytyczna
Dostęp	zdalny, bez uwierzytelnienia
Przyczyna	brak uwierzytelnienia i niebezpieczna walidacja kodu
Skutek	wykonanie dowolnego kodu w kontekście procesu Langflow
CISA KEV	tak, dodano 5 maja 2025 r.
Publiczny materiał PoC	tak, techniczna analiza Horizon3.ai

Opis i wersje potwierdzają rekord NVD, poprawka projektu oraz wydanie Langflow 1.3.0.

Gdzie znajduje się błąd

Langflow pozwala budować graficzne workflow łączące modele językowe, prompty, źródła danych, narzędzia i własny kod. Taka funkcjonalność z natury operuje blisko granicy wykonania kodu, dlatego endpointy walidujące komponenty muszą mieć szczególnie restrykcyjną kontrolę dostępu.

Podatność dotyczyła endpointu /api/v1/validate/code. Jego zadaniem było sprawdzanie kodu Pythona przesyłanego przez aplikację. Według opisu CVE zdalny użytkownik mógł wywołać tę funkcję bez uwierzytelnienia, a przetwarzanie prowadziło do wykonania kontrolowanej treści. Problem łączył więc dwie klasy słabości: brak uwierzytelnienia dla krytycznej funkcji oraz code injection.

Techniczny root cause i poprawka

Rekord NVD klasyfikuje problem jako połączenie CWE-306 — Missing Authentication for Critical Function oraz CWE-94 — Improper Control of Generation of Code. To dwie oddzielne granice, które zawiodły jednocześnie: route krytycznej funkcji nie wymagał tożsamości, a jej zamierzona logika pracowała na kodzie. Projektowy pull request 6911 dodał zależność bieżącego aktywnego użytkownika do walidacji kodu. Jest to potwierdzona zmiana istotna dla bezpieczeństwa; nie należy na jej podstawie wymyślać dodatkowych, nieudokumentowanych warunków exploita.

W praktyce ścieżka danych wyglądała następująco: zewnętrzny klient docierał do API, route przekazywał treść do funkcji walidacyjnej, a proces Python wykonywał pracę w swoim kontekście systemowym. Reverse proxy, kontener i IAM nie były przyczyną CVE, ale decydowały o osiągalności oraz zasięgu po wykonaniu kodu.

Model powierzchni ataku Langflow

Granica	Dowód do zebrania	Znaczenie dla ryzyka
Internet/VPN → proxy	publiczny DNS, reguły ingress i opublikowane path	ustala, kto może dotrzeć do podatnego API
proxy → Langflow	rewrite, allowlista tras i bypass do portu backendu	filtr na edge nie pomaga, jeśli backend ma inną drogę
obraz → runtime	wersja pakietu, tag i niezmienny digest	potwierdza, czy poprawka rzeczywiście działa
proces → sekrety	env, mounty, workload identity i tokeny	wyznacza zakres możliwej ekspozycji
proces → sieć	egress policy, DNS i dostęp do usług wewnętrznych	wyznacza możliwość dalszego ruchu

Pełna analiza endpointu powinna korzystać z macierzy z technicznego pentestu API, a wymaganie uwierzytelnienia i walidacji można mapować do OWASP ASVS 5.

To istotna lekcja dla aplikacji AI. Sama warstwa modeli nie musi mieć podatności, aby system został przejęty. Najbardziej niebezpieczną częścią może być klasyczny endpoint API otaczający kreator agentów, interpreter kodu, konektor lub narzędzie automatyzacji.

Jaki jest realny wpływ na środowisko AI

Kod wykonuje się z uprawnieniami procesu Langflow i ograniczeniami kontenera lub hosta. W praktyce proces może posiadać:

klucze API do modeli OpenAI, Anthropic, Google lub usług chmurowych;
tokeny do baz wektorowych, repozytoriów, SaaS i systemów automatyzacji;
dostęp do plików z konfiguracją, historii flow i danych przesyłanych do RAG;
łączność z usługami wewnętrznymi niedostępnymi z Internetu;
uprawnienia zapisu do wolumenów albo współdzielonych katalogów;
możliwość wykonywania narzędzi przypisanych agentom.

Dlatego skutek nie powinien być oceniany jako „przejęcie jednego panelu”. Langflow może pełnić funkcję koncentratora zaufania dla wielu systemów. Nawet jeżeli działa w kontenerze, dostępne sekrety i ruch wychodzący mogą wystarczyć do dalszego przemieszczania się.

Publiczny PoC i zasady bezpiecznej walidacji

Horizon3.ai opublikował techniczną analizę i materiał exploit/PoC dla CVE-2025-3248. Nie należy kopiować żądań do produkcyjnej instancji „dla sprawdzenia”. Nawet niewinnie wyglądający kod może zmienić dane, uruchomić proces lub spowodować incydent.

Bezpieczna walidacja powinna zaczynać się od pasywnych dowodów:

ustal wersję pakietu, obrazu kontenera i digest wdrożenia;
sprawdź, czy panel oraz API są dostępne z Internetu, VPN lub innych segmentów;
potwierdź, że reverse proxy nie publikuje niepotrzebnych ścieżek API;
odtwórz konfigurację w izolowanym laboratorium bez prawdziwych sekretów;
jeżeli potrzebny jest test dynamiczny, użyj nieszkodliwego znacznika i uzgodnionego rules of engagement;
po aktualizacji wykonaj retest oraz kontrolę, że stary Pod lub obraz nie pozostał na żadnym węźle.

Każdy publiczny PoC trzeba najpierw przejrzeć statycznie. Repozytoria podszywające się pod exploity bywają nośnikiem malware wymierzonego w badaczy.

Bezpieczna walidacja ekspozycji i triage

Na produkcji nie trzeba wykonywać żadnego kodu, aby podjąć decyzję. Zbierz wersję i digest, potwierdź routing do /api/v1/validate/code, ustal źródła mogące dotrzeć do backendu i zinwentaryzuj sekrety procesu. Test sieciowy może ograniczyć się do zwykłej odpowiedzi aplikacji na nieszkodliwe żądanie bez treści wykonawczej. W laboratorium używaj kopii konfiguracji, syntetycznych tokenów i sinku egress należącego do testera.

Drzewo decyzji dla CVE-2025-3248

Langflow nie występuje — zamknij alert po udokumentowaniu produktu i właściciela usługi.
Wersja co najmniej 1.3.0, wspierana i potwierdzona digestem — sprawdź, czy route bez tożsamości jest odrzucany, następnie wykonaj regresję legalnego workflow.
Wersja podatna, ale API odizolowane — aktualizuj pilnie; zachowaj dowód segmentacji, lecz nie traktuj go jako trwałej poprawki.
Wersja podatna i osiągalna — natychmiast ogranicz dostęp, zachowaj telemetrykę, zaktualizuj oraz rozpocznij analizę poświadczeń.
Podatna instancja ma model keys, cloud identity albo dostęp do sieci wewnętrznej — rotacja i hunting obejmują każdy osiągalny system, nie tylko host Langflow.
Widać proces potomny, nietypowy egress lub użycie klucza — przejdź do procedury incydentowej i odbudowy z zaufanego obrazu.

CISA wyznaczyła dla podmiotów objętych BOD 22-01 termin 26 maja 2025 r., ale dla każdej organizacji ważniejszy jest fakt potwierdzonego wykorzystania. Zarządzanie podatnościami oparte na ryzyku i ekspozycji powinno automatycznie podnosić priorytet KEV.

Naprawa i ograniczenie ekspozycji

Aktualizacja

Minimalną wersją usuwającą opisaną lukę jest Langflow 1.3.0. Ponieważ od 2025 r. wydano kolejne poprawki, w praktyce należy instalować najnowsze wspierane wydanie zgodne z aplikacją, a nie zatrzymywać się na historycznym minimum. Po wdrożeniu sprawdź wersję działającego procesu i usuń stare obrazy z aktywnych manifestów.

Dostęp do panelu

Interfejsy do budowania i wdrażania flow nie powinny być publiczne tylko dlatego, że publiczna jest aplikacja korzystająca z flow. Oddziel runtime od panelu administracyjnego. Dostęp operatorów ogranicz przez prywatną sieć, silne SSO i MFA, a na proxy stosuj jawne listy dozwolonych ścieżek.

Izolacja sekretów

Nie przekazuj procesowi Langflow jednego szerokiego pliku .env. Stosuj osobne tożsamości workloadów, krótkotrwałe tokeny, ograniczone role i menedżer sekretów. Jeżeli instancja była podatna i osiągalna, klucze dostępne procesowi trzeba obrócić, nawet bez jednoznacznego alarmu EDR.

Egress i sandbox

Ogranicz ruch wychodzący do niezbędnych endpointów modeli i danych. Kontener powinien działać jako użytkownik bez uprawnień root, z systemem plików tylko do odczytu tam, gdzie to możliwe, bez dostępu do socketu Dockera i bez niepotrzebnych capabilities. Te kontrole nie naprawiają CVE, ale zmniejszają blast radius.

Więcej warstw kontrolnych — digesty, SBOM, zakaz uprzywilejowanego runtime i politykę wdrożeniową — opisuje przewodnik bezpieczeństwo obrazów kontenerów. Jeżeli Langflow używa workload identity albo prywatnych endpointów modelowych, zakres powinien objąć również pentest chmury AWS, Azure lub GCP.

Weryfikacja naprawy i retest

Retest po aktualizacji powinien potwierdzić jednocześnie bezpieczeństwo i działanie produktu:

wszystkie instancje, Pody i joby używają naprawionej, wspieranej wersji oraz zatwierdzonego digestu;
żądanie bez prawidłowej tożsamości nie uruchamia funkcji walidacji ani skutku ubocznego;
prawidłowo zalogowany użytkownik wykonuje dozwolony workflow zgodnie z rolą;
alternatywna ścieżka, stary prefix API, port backendu i środowisko demo nie omijają kontroli;
sekrety mają nowe wersje, stare tokeny są unieważnione, a provider potwierdza brak późniejszego użycia;
egress policy, filesystem i uprawnienia procesu blokują niepotrzebne możliwości;
logi zawierają principal, route, wynik kontroli i correlation ID bez treści sekretów lub kodu.

Nie uznawaj retestu za zaliczony tylko dlatego, że panel pokazuje nowy numer wersji. Obraz może nie zostać przeładowany, ruch może trafiać do starej repliki albo osobne środowisko demonstracyjne może nadal publikować podatny backend.

Detekcja: czego szukać po CVE-2025-3248

CISA dodała lukę do KEV, co potwierdza wykorzystanie w rzeczywistych atakach. Zespoły powinny skorelować:

żądania do /api/v1/validate/code, szczególnie spoza sieci administracyjnej;
błędy, nietypowe statusy i nagłe serie wywołań API;
procesy potomne interpretera Pythona i polecenia systemowe uruchomione przez usługę;
nieoczekiwane połączenia DNS i HTTP z kontenera lub hosta Langflow;
odczyt plików .env, katalogów sekretów i tokenów service account;
nowe pliki, zadania cykliczne, konta, klucze SSH lub zmiany flow bez właściciela biznesowego;
użycie kluczy modeli z nowych adresów IP po możliwym czasie naruszenia.

Samo wystąpienie ścieżki /api/v1/validate/code w logu nie jest IOC — poprawiona aplikacja może legalnie jej używać po uwierzytelnieniu. Sygnał wysokiej jakości łączy brak principal albo źródło spoza sieci administracyjnej z anomalią procesu, pliku lub egress. Koreluj timestampy proxy, kontenera, EDR, DNS, IAM i dostawcy modelu. Jeżeli runtime nie logował procesów potomnych, brak alertu nie jest dowodem braku wykonania kodu.

Checklista techniczna

Jeżeli logi aplikacji są krótkotrwałe, zabezpiecz logi reverse proxy, platformy kontenerowej, IAM, DNS i dostawców modeli. Dostawca API może być jedynym miejscem pokazującym nadużycie wykradzionego klucza.

Kolejność reakcji dla firmy

Ogranicz ekspozycję panelu i zachowaj obrazy oraz logi do analizy.
Zaktualizuj wszystkie instancje, także środowiska testowe i tymczasowe demo.
Zinwentaryzuj sekrety, sieci i narzędzia dostępne z procesu.
Obróć klucze i unieważnij tokeny zgodnie z priorytetem ryzyka.
Przeprowadź hunting od najwcześniejszej daty publicznej ekspozycji.
Odtwórz naruszone workloady z zaufanych obrazów i wykonaj retest.

Wniosek dla bezpieczeństwa agentów AI

CVE-2025-3248 pokazuje, dlaczego audyt bezpieczeństwa aplikacji AI i LLM musi objąć zwykłe API, kontrolę dostępu, interpretery, sekrety i sieć — nie tylko prompt injection. Platforma agentowa łączy wiele uprzywilejowanych integracji, więc pojedynczy endpoint code execution może mieć wyjątkowo duży wpływ.

Jeżeli Twoja firma używa Langflow lub podobnych kreatorów, autoryzowany red teaming agentów AI może bezpiecznie sprawdzić izolację narzędzi, tożsamości, dane RAG i odporność infrastruktury bez publikowania niebezpiecznych payloadów.