CVE-2026-8505 dotyczy webhooków Langflow. Przy ustawieniu WEBHOOK_AUTH_ENABLE=False klucz API nie jest poprawnie walidowany, więc znajomość UUID flow wystarcza, by wykonać flow jako jego właściciel. Skutek zależy od tego, co dany flow potrafi: od operacji na danych, przez wywołania integracji, po wykonanie kodu w najgroźniejszych scenariuszach.
WEBHOOK_AUTH_ENABLE=False + znany UUID flow → wykonanie flow jako właściciel → RCE/DoS zależnie od komponentów flow.Attack path
Config-aware triage
Skaner poprawnie wskaże podatną wersję, ale VE musi ustalić: czy endpoint webhooka jest osiągalny, jak ustawiono WEBHOOK_AUTH_ENABLE, czy identyfikatory flow mogą zostać poznane (logi, URL-e, frontend) oraz jakie komponenty i integracje znajdują się wewnątrz flow. Instancja z włączoną autoryzacją webhooków ma zupełnie inny profil ryzyka niż ta z wyłączoną. To kolejny przypadek z serii Langflow, w której liczy się capability, nie etykieta — zob. rodzinę RCE Langflow.
Wyłączona auth nie powinna tworzyć execution path
W infrastrukturze AI i automatyzacji „wykonanie workflow” bywa odpowiednikiem bardzo szerokiego zestawu uprawnień: flow ma dostęp do sekretów, sieci i narzędzi. Ocena podatności powinna więc obejmować capabilities konkretnego flow, sekrety dostępne dla procesu i sieci, do których Langflow ma dostęp. Upgrade do 1.9.1, a do tego czasu włącz autoryzację webhooków lub ogranicz ich osiągalność.
Powiązane na blogu
- Langflow: rodzina RCE — wiele CVE, różne ścieżki
- n8n: resumeToken omija approval — wykonanie workflow bez właściwej kontroli
Źródła
- GitLab Advisory Database — CVE-2026-8505 (langflow) — advisories.gitlab.io
Nota redakcyjna: stan informacji 6 października 2026, na podstawie draftu VMRT i publicznego advisory (GitLab Advisory DB). CVE-2026-8505 (Langflow, fix 1.9.1); exploitable przy WEBHOOK_AUTH_ENABLE=False. Artykuł nie potwierdza aktywnej eksploatacji.