Langflow i Rails na celowniku atakujących

Dwie krytyczne luki, jeden schemat działania

Atakujący aktywnie wykorzystują dwie poważne podatności: CVE-2026-0768 w Langflow oraz CVE-2026-66066 w Ruby on Rails. W obu przypadkach cel wydaje się podobny: najpierw rozpoznanie środowiska i zbieranie sekretów, a potem przygotowanie gruntu pod dalsze przejęcie kontroli nad systemem.

To szczególnie niebezpieczne, bo oba narzędzia i frameworki często stoją bardzo blisko danych wrażliwych — od kluczy API, przez hasła do baz danych, po poświadczenia do chmury.

Langflow: wejście do środowiska z uprawnieniami root

W przypadku Langflow problem dotyczy CVE-2026-0768, czyli błędu walidacji danych wejściowych, który może prowadzić do wykonania dowolnego kodu Python w kontekście użytkownika root.

Zaobserwowane próby ataku nie wyglądały przypadkowo. Przeciwnicy sprawdzali m.in.:

• zmienne środowiskowe, takie jak LANGFLOW_SUPERUSER,
• wzorce związane z **OPENAI_API***,
• dane w stylu AWS_ACCESS i AWS_SECRET,
• zawartość pliku /root/.cache/langflow/secret_key,
• dostęp do katalogu .ssh,
• rozmiar pliku .bash_history.

Taki zestaw wskazuje na typową kampanię ukierunkowaną na szybkie wyłuskanie dostępu do kont, tokenów i konfiguracji, które mogą otworzyć drogę do kolejnych systemów.

Ruby on Rails: od odczytu plików do RCE

Druga luka, CVE-2026-66066, została opisana jako KindaRails2Shell. Jej wykorzystanie opiera się na różnicy w sposobie, w jaki Active Storage i libvips interpretują przesyłane pliki. W praktyce atakujący może wysłać spreparowany obraz i doprowadzić do odczytu dowolnych plików z serwera.

Warunki powodzenia ataku są dwa:

• aplikacja musi używać libvips do przetwarzania wariantów obrazów,
• musi przyjmować uploady od niezaufanych użytkowników.

Skutek może być bardzo poważny, bo z serwera da się wyciągnąć sekrety Rails, w tym:

• secret_key_base,
• Rails master key,
• hasła do baz danych,
• dane dostępowe do chmury,
• tokeny API.

Właśnie te informacje mogą później posłużyć do przejścia od samego odczytu plików do remote code execution.

Ślady aktywnej kampanii

Telemetria pokazuje, że nie chodzi o teoretyczny problem. W krótkim czasie odnotowano dziesiątki wykryć, a ich liczba szybko rosła. Ataki przeciwko Langflow miały w dużej mierze źródła w Rosji i uderzały w systemy testowe w Wielkiej Brytanii.

W przypadku Rails aktywność zauważono m.in. wobec systemów testowych w Singapurze, Izraelu i Wielkiej Brytanii. W jednym z przypadków ruch wyglądał tak, jakby pojedynczy adres IP z Francji zestawiał kanał command-and-control z hostem w Izraelu.

To ważny sygnał: napastnicy nie tylko skanują Internet, ale też próbują budować infrastrukturę do dalszych działań — od kradzieży danych po utrzymanie dostępu i rozwijanie własnych operacji.

Dlaczego to grozi czymś więcej niż awarią aplikacji

Langflow i Ruby on Rails często działają jako element większego środowiska. Jeśli w takich aplikacjach pojawią się klucze do chmury, tokeny do zewnętrznych usług albo dostęp do baz danych, pojedyncza luka może urosnąć do incydentu obejmującego wiele systemów.

W przeszłości podobne podatności bywały wykorzystywane nie tylko do kradzieży sekretów, ale też do:

• wdrażania narzędzi zdalnego dostępu,
• instalowania koparek kryptowalut,
• skanowania kolejnych hostów,
• ukrywania śladów poprzez wyłączanie mechanizmów audytu.

Co powinni zrobić administratorzy

Najważniejsze jest szybkie sprawdzenie ekspozycji i aktualizacja systemów.

W przypadku Ruby on Rails

Należy przejść na poprawione wersje:

• 7.2.3.2,
• 8.0.5.1,
• 8.1.3.1.

Warto też zweryfikować łańcuch ruby-vips i libvips, a jeśli aktualizacja nie jest możliwa od razu, tymczasowo ograniczyć lub wyłączyć przetwarzanie obrazów przez Vips oraz rozważyć blokadę uploadów od niezaufanych użytkowników.

W przypadku Langflow

Trzeba ustalić, czy instancja jest wystawiona do Internetu, i sprawdzić, czy nie doszło do odczytu sekretów lub nienaturalnych prób dostępu do plików konfiguracyjnych i katalogów użytkownika root.

Dodatkowe działania obronne

• rotacja secret_key_base i Rails master key,
• wymiana wszystkich podejrzanych tokenów API i kluczy chmurowych,
• przegląd logów pod kątem dostępu do /proc/self/environ, config/master.key i podobnych ścieżek,
• monitorowanie ruchu pod kątem połączeń C2,
• blokowanie znanych wskaźników infrastruktury, jeśli są dostępne.

Wniosek

To kolejny przykład, że aplikacje pomocnicze i frameworki webowe stały się dla atakujących cennym celem. Nie chodzi już tylko o samą aplikację, ale o wszystko, co ma ona w pamięci i konfiguracji: sekrety, klucze, dostęp do chmury i dalszych usług. W praktyce jeden błąd może dać przeciwnikowi znacznie więcej niż dostęp do pojedynczego serwera.