Ataki na Langflow i Ruby on Rails: krytyczne luki otwierają drogę do kradzieży sekretów i przejęcia środowisk AI

Wprowadzenie do problemu / definicja

Aktywnie wykorzystywane podatności w narzędziach do budowy aplikacji AI oraz popularnych frameworkach webowych stają się jednym z najpoważniejszych zagrożeń dla środowisk produkcyjnych. Najnowsze obserwacje pokazują, że atakujący równolegle nadużywają dwóch krytycznych luk: CVE-2026-0768 w Langflow oraz CVE-2026-66066, znanej jako KindaRails2Shell, w ekosystemie Ruby on Rails.

Oba błędy mogą prowadzić do przejęcia wrażliwych danych, a w określonych warunkach również do zdalnego wykonania kodu. To szczególnie niebezpieczne dla organizacji, które łączą aplikacje AI z systemami firmowymi, usługami chmurowymi i zewnętrznymi integracjami.

W skrócie

Badacze bezpieczeństwa zaobserwowali aktywne kampanie wymierzone w podatne instancje Langflow oraz aplikacje Rails korzystające z Active Storage i libvips. W przypadku Langflow problem dotyczy walidatora kodu w edytorze komponentów niestandardowych, co może umożliwić nieuwierzytelnione wykonanie kodu Python po stronie serwera.

W przypadku Ruby on Rails luka pozwala na odczyt dowolnych plików z serwera podczas przetwarzania obrazów. W praktyce może to prowadzić do wycieku sekretów procesu, danych konfiguracyjnych i dalszej eskalacji uprawnień, a nawet do pełnego kompromisu aplikacji.

Langflow: ryzyko nieuwierzytelnionego wykonania kodu.
Ruby on Rails: ryzyko odczytu plików i wycieku sekretów.
Atakujący prowadzą rozpoznanie, zbierają poświadczenia i przygotowują dalsze działania po uzyskaniu dostępu.

Kontekst / historia

Langflow już wcześniej pojawiał się w analizach bezpieczeństwa jako atrakcyjny cel dla operatorów ataków wymierzonych w publicznie dostępne panele do budowy workflow AI. Tego typu platformy są często uruchamiane szybko, testowo lub półprodukcyjnie, a następnie pozostają wystawione do internetu bez odpowiedniego utwardzenia.

To sprawia, że stanowią dogodny cel dla masowego skanowania i automatycznego wykorzystania podatności. W środowiskach AI stawką są nie tylko dane użytkowników, ale także klucze API do modeli, integracje z usługami chmurowymi oraz logika procesów automatyzacji.

Równolegle ekosystem Ruby on Rails mierzy się z zagrożeniami wynikającymi z przetwarzania plików. KindaRails2Shell dotyczy interakcji między Active Storage a biblioteką libvips. To szczególnie groźna klasa błędów, ponieważ punkt wejścia może wyglądać jak zwykła funkcja przesyłania obrazów, obecna w portalach, panelach klienta i aplikacjach SaaS.

Analiza techniczna

CVE-2026-0768 w Langflow dotyczy mechanizmu walidacji kodu dostarczanego przez użytkownika w edytorze własnych komponentów. Jeżeli podatna instancja udostępnia ten mechanizm bez odpowiednich zabezpieczeń, atakujący może przesłać spreparowany kod i doprowadzić do jego wykonania po stronie serwera.

W praktyce oznacza to możliwość przejęcia procesu aplikacji, a w części wdrożeń także uruchamiania poleceń z wysokimi uprawnieniami. Szczególnie niebezpieczne są środowiska, w których Langflow przechowuje tokeny do usług LLM, poświadczenia chmurowe, klucze API oraz dane dostępowe do wewnętrznych systemów.

Zaobserwowane działania wskazują, że operatorzy ataków nie ograniczają się do prostego potwierdzenia podatności. Po uzyskaniu dostępu przeszukiwane są zmienne środowiskowe, lokalne sekrety aplikacji, katalogi SSH oraz historia poleceń powłoki. Taki wzorzec sugeruje przygotowanie do utrzymania dostępu, ruchu bocznego i dalszej eksfiltracji danych.

CVE-2026-66066 w Rails opiera się na możliwości odczytu arbitralnych plików z serwera podczas generowania wariantów obrazów. Źródłem problemu jest rozbieżność w interpretacji danych wejściowych pomiędzy Active Storage a libvips. Jeżeli aplikacja przyjmuje obrazy od niezaufanych użytkowników i przetwarza je po stronie serwera, atakujący może doprowadzić do ujawnienia plików lokalnych lub środowiska procesu.

Najgroźniejszą konsekwencją nie jest sam odczyt plików, ale dane, które można w ten sposób pozyskać. Wyciek secret_key_base, klucza master, danych dostępowych do bazy lub tokenów integracyjnych może umożliwić przejęcie sesji, odszyfrowanie wrażliwych danych, rozszerzenie dostępu do innych usług, a w zależności od architektury także przejście do zdalnego wykonania kodu.

Konsekwencje / ryzyko

Dla organizacji rozwijających aplikacje oparte na AI ryzyko ma charakter wielowarstwowy. Kompromitacja Langflow może oznaczać utratę kluczy do modeli, danych przesyłanych przez użytkowników, promptów, definicji workflow oraz integracji z systemami firmowymi.

W przypadku aplikacji Rails konsekwencje zależą od zakresu sekretów dostępnych dla procesu. Nawet jeżeli atak nie kończy się natychmiastowym wykonaniem kodu, sam wyciek kluczy i poświadczeń należy traktować jako incydent wysokiej wagi. Oznacza to, że samo wdrożenie poprawek po wykryciu naruszenia może być niewystarczające.

Organizacje muszą liczyć się z koniecznością pełnej rotacji sekretów, ponownego wydania tokenów, zmiany haseł, unieważnienia sesji i przeglądu logów pod kątem wtórnego wykorzystania wykradzionych danych. Dodatkowym problemem jest automatyzacja po stronie przeciwnika, która skraca czas dostępny na reakcję zespołów SOC i administratorów.

Rekomendacje

Priorytetem powinno być szybkie ustalenie ekspozycji. Należy zinwentaryzować wszystkie publicznie dostępne instancje Langflow oraz aplikacje Rails wykorzystujące Active Storage wraz z libvips. Każdy system osiągalny z internetu i obsługujący niezaufane dane wejściowe powinien zostać potraktowany jako potencjalnie zagrożony.

W przypadku Langflow konieczne jest niezwłoczne wdrożenie poprawek dostawcy, ograniczenie dostępu do interfejsów administracyjnych i edytorów komponentów oraz odseparowanie usługi od internetu przy użyciu VPN, reverse proxy z kontrolą dostępu lub segmentacji sieciowej.

Dla środowisk Rails niezbędna jest aktualizacja do wersji usuwających podatność oraz zapewnienie bezpiecznej, zgodnej wersji libvips. Równolegle warto przeanalizować, czy aplikacja przyjmuje obrazy od niezaufanych użytkowników i czy generuje ich warianty po stronie serwera.

ograniczyć uprawnienia procesów aplikacyjnych i kont serwisowych,
odseparować środowiska deweloperskie, testowe i produkcyjne,
włączyć pełne logowanie żądań do endpointów wysokiego ryzyka,
monitorować próby odczytu plików w nietypowych ścieżkach,
wdrożyć regularne skanowanie ekspozycji internetowej i szybki proces patch management,
przenieść sekrety do dedykowanych systemów zarządzania sekretami, jeśli to możliwe.

Jeżeli istnieje podejrzenie kompromitacji, wszystkie sekrety dostępne dla procesu należy uznać za ujawnione i przeprowadzić ich pełną rotację, w tym kluczy aplikacyjnych, poświadczeń bazodanowych, danych dostępowych do storage oraz tokenów do usług zewnętrznych.

Podsumowanie

Aktywne wykorzystanie CVE-2026-0768 i CVE-2026-66066 pokazuje, że środowiska AI i klasyczne aplikacje webowe coraz częściej funkcjonują w tym samym krajobrazie zagrożeń. W obu przypadkach stawką nie jest wyłącznie pojedyncza aplikacja, ale cały łańcuch zaufania obejmujący sekrety, integracje i zasoby chmurowe.

Dla zespołów bezpieczeństwa oznacza to konieczność szybkiego patchowania, ograniczania ekspozycji usług oraz traktowania potencjalnego wycieku sekretów jako pełnoprawnego incydentu bezpieczeństwa. Reakcja nie może kończyć się na aktualizacji komponentu — musi obejmować także analizę śladów ataku i odbudowę zaufania do środowiska.