Firma VulnCheck ostrzegła na początku września, że przestępcy zaczęli aktywnie wykorzystywać CVE-2026-0768 — krytyczną podatność w Langflow, niskokodowej platformie do budowania aplikacji i agentów opartych na sztucznej inteligencji. Luka ma ocenę CVSS 9.8 i pozwala na zdalne wykonanie dowolnego kodu w Pythonie bez żadnego uwierzytelnienia. Celem ataków nie jest jednak sam Langflow, tylko to, co trzymają w nim użytkownicy: klucze do OpenAI, poświadczenia AWS i klucze SSH.
Na czym polega błąd
Langflow ma edytor własnych komponentów, a w nim funkcję sprawdzania fragmentu kodu przed uruchomieniem. Endpoint walidatora przyjmuje parametr z kodem od użytkownika i przekazuje go dalej do pythonowej funkcji exec() — bez odpowiedniej weryfikacji i, co gorsza, bez wymogu zalogowania. Napastnik wysyła więc zwykłe żądanie HTTP do wystawionej w internecie instancji i dostaje wykonanie kodu z uprawnieniami roota.
Podatność dotyczy wszystkich wydań do wersji 1.4.2 włącznie. Zgłoszono ją przez program ZDI już w lipcu 2025 roku, a publicznie ujawniono jako zero-day w styczniu 2026. Aktywna eksploatacja ruszyła 29 sierpnia 2026 — VulnCheck zaobserwowała ciągły ruch z około dwudziestu adresów IP w ponad sześciu krajach, w dużej mierze z Rosji, a same pułapki firmy w Wielkiej Brytanii odnotowały ponad 360 prób ataku w kilka dni.
Co napastnicy robią po wejściu
Schemat jest powtarzalny i mało wyrafinowany, bo nie musi być inny. Po uzyskaniu wykonania kodu skrypty odpytują zmienne środowiskowe, przeszukują katalogi w poszukiwaniu plików konfiguracyjnych, wyciągają klucze API i dane dostępowe do chmury, a następnie sprawdzają możliwość połączeń SSH do innych maszyn.
To ważne rozróżnienie: instancja Langflow rzadko sama w sobie jest cennym łupem. Cenne jest to, że w typowym wdrożeniu przechowuje ona komplet sekretów potrzebnych do działania agentów — token do modelu językowego, klucz do bucketa S3, dostęp do bazy wektorowej, czasem poświadczenia do wewnętrznego API. Przejęcie jednego serwera daje więc od razu dostęp do kilku innych usług, w dodatku takich, na których łatwo zarobić: skradzione klucze do modeli LLM są odsprzedawane i wykorzystywane do generowania treści na cudzy rachunek.
Szerszy problem: stos AI jako nowa powierzchnia ataku
Sprawa Langflow nie jest odosobniona. Według VulnCheck przed rokiem 2026 znany był tylko jeden przypadek wykorzystywanej w praktyce luki w tym projekcie. W samym 2026 doszło do tego jedenaście kolejnych podatności zgłoszonych jako atakowane, a łączna liczba udanych ataków na instancje podatne na trzy z nich przekroczyła 15 tysięcy.
Przyczyna jest dość prozaiczna. Narzędzia do budowania aplikacji AI powstawały szybko, w atmosferze wyścigu, i trafiały do produkcji jako pojedyncze kontenery wystawione „tymczasowo” do internetu, żeby zespół mógł się do nich dostać. Wiele z nich domyślnie nie ma uwierzytelnienia albo ma je opcjonalne. Do tego dochodzi konstrukcja, w której wykonywanie kodu użytkownika jest funkcją, a nie błędem — co bardzo zawęża margines na pomyłkę w walidacji. Efekt jest taki, że skanery przestępców przeczesują dziś internet w poszukiwaniu paneli Langflow, Flowise czy podobnych rozwiązań równie chętnie, jak kiedyś szukały niezałatanych WordPressów.
Co zrobić
Podstawą jest aktualizacja Langflow do wersji nowszej niż 1.4.2. Jeżeli instancja była dostępna publicznie w ostatnich tygodniach, samo załatanie nie zamyka sprawy — trzeba założyć, że sekrety wyciekły. Klucze API do OpenAI i innych dostawców modeli, poświadczenia chmurowe i klucze SSH z takiej maszyny należy unieważnić i wygenerować od nowa, a nie tylko „na wszelki wypadek zmienić hasło”.
Znacznie ważniejsza jest jednak zmiana samego podejścia. Panel Langflow nie ma powodu być osiągalny z całego internetu. Schowanie go za VPN, reverse proxy z uwierzytelnieniem albo zwykłym ograniczeniem po adresie IP wycina cały ten wektor, niezależnie od tego, jaka luka zostanie znaleziona w kolejnym wydaniu. Warto też odejść od trzymania długożyciowych kluczy w zmiennych środowiskowych na rzecz krótkotrwałych tokenów oraz ustawić limity wydatków i alerty na kontach u dostawców modeli — nietypowy skok zużycia bywa pierwszym sygnałem, że ktoś korzysta z naszego klucza.
Na koniec sprawdźmy, czy w firmie nie działają zapomniane instancje narzędzi AI postawione kiedyś do testów. To właśnie one, nieaktualizowane i nikomu niepotrzebne, najczęściej stają się punktem wejścia.
Podsumowanie
CVE-2026-0768 to podręcznikowy przykład tego, jak wygląda dziś atak na infrastrukturę AI: banalny technicznie, zautomatyzowany i nastawiony nie na dane w systemie, lecz na klucze otwierające inne systemy. Narzędzia do budowania agentów trafiły do firm szybciej, niż zdążyły dorobić się sensownych domyślnych ustawień bezpieczeństwa. Do czasu, aż to się zmieni, obowiązek pilnowania, żeby nie stały otworem, spoczywa na tych, którzy je wdrażają.
źródło: https://www.securityweek.com/hackers-start-exploiting-critical-langflow-vulnerability/