Krytyczna luka w Ruby on Rails: spreparowane obrazy mogą ujawnić pliki serwera - Security Bez Tabu

Krytyczna luka w Ruby on Rails: spreparowane obrazy mogą ujawnić pliki serwera

Cybersecurity news

Wprowadzenie do problemu / definicja

W ekosystemie Ruby on Rails ujawniono krytyczną podatność oznaczoną jako CVE-2026-66066, związaną z komponentem Active Storage oraz biblioteką libvips używaną do przetwarzania obrazów. Błąd może umożliwić nieautoryzowanemu atakującemu odczyt plików dostępnych dla procesu aplikacji poprzez przesłanie odpowiednio spreparowanego obrazu.

Problem dotyczy granicy zaufania pomiędzy aplikacją webową a silnikiem przetwarzania grafiki. Szczególnie zagrożone są systemy, które pozwalają niezaufanym użytkownikom przesyłać pliki i automatycznie analizują lub transformują obrazy po stronie serwera.

W skrócie

Podatność obejmuje aplikacje Rails korzystające z Active Storage oraz backendu obrazów opartego na libvips. W określonych konfiguracjach atakujący może uzyskać prymityw arbitralnego odczytu plików, co otwiera drogę do pozyskania sekretów aplikacyjnych i dalszej kompromitacji środowiska.

  • Dotyczy głównie wdrożeń używających Active Storage z libvips.
  • Może prowadzić do odczytu lokalnych plików dostępnych dla procesu Rails.
  • Narażone są m.in. sekrety aplikacji, dane dostępowe do baz danych i tokeny API.
  • Samo załatanie frameworka może nie wystarczyć bez aktualizacji zależności systemowych.

Kontekst / historia

Problem został zgłoszony przez badaczy bezpieczeństwa i zaadresowany w poprawkach bezpieczeństwa opublikowanych 29 lipca 2026 roku. Według dostępnych informacji podatność obejmuje przede wszystkim linie Rails 7.x, 8.0.x i 8.1.x, a w przypadku Rails 6.x dotyczy środowisk, w których Active Storage zostało jawnie skonfigurowane do użycia Vips.

Znaczenie incydentu zwiększa fakt, że w nowszych konfiguracjach Rails backend Vips był często wybierany jako domyślne lub preferowane rozwiązanie do przetwarzania obrazów. To oznacza, że powierzchnia ataku może być szeroka, zwłaszcza w aplikacjach publicznych przyjmujących uploady od użytkowników.

Istotne jest również rozróżnienie pomiędzy wersjami wspieranymi i niewspieranymi. Starsze gałęzie, które osiągnęły koniec cyklu życia, nie otrzymują pełnych poprawek bezpieczeństwa, dlatego w wielu przypadkach konieczna może być aktualizacja do wspieranego wydania frameworka.

Analiza techniczna

Źródłem problemu jest sposób, w jaki Active Storage przekazywał niezweryfikowane dane wejściowe do operacji libvips uznawanych za niezaufane. Sama biblioteka libvips obsługuje liczne loadery, savery i mechanizmy pośrednie, a część z nich może prowadzić do nieoczekiwanego dostępu do zasobów lokalnych, jeśli przetwarzają dane pochodzące od atakującego.

W podatnym scenariuszu użytkownik przesyła spreparowany obraz, który następnie trafia do analizy lub transformacji po stronie aplikacji. Jeżeli ścieżka wykonania obejmuje operację oznaczoną jako niebezpieczna dla danych niezaufanych, możliwy staje się odczyt lokalnych plików z perspektywy procesu Rails.

Praktycznie oznacza to, że atak nie musi ograniczać się wyłącznie do klasycznego generowania miniaturek. Wystarczające może być samo uruchomienie pipeline’u analizy lub przetwarzania załącznika, jeśli korzysta on z podatnej kombinacji Active Storage i libvips.

Opublikowane poprawki koncentrują się na blokowaniu operacji oznaczonych po stronie libvips jako untrusted. Warto jednak podkreślić, że skuteczność ochrony zależy nie tylko od wersji Rails, lecz także od odpowiednio aktualnej wersji samej biblioteki libvips oraz powiązanych bindingów w środowisku.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość ujawnienia materiału uwierzytelniającego i danych konfiguracyjnych przechowywanych lokalnie lub dostępnych dla procesu aplikacji. W praktyce może to obejmować sekret podpisujący sesje, klucz główny Rails, poświadczenia do bazy danych, klucze storage, tokeny API i dane dostępowe do usług chmurowych.

Ryzyko nie kończy się na jednorazowym odczycie pliku. Przejęte sekrety mogą umożliwić atakującemu dalsze działania, takie jak przejęcie kontekstu aplikacji, dostęp do danych klientów, ruch boczny do innych systemów lub pośrednie przygotowanie gruntu pod kolejne etapy ataku.

Dodatkowym problemem jest wykrywalność. Złośliwy upload obrazu może wyglądać jak zwykła aktywność użytkownika, przez co incydent nie musi zostać szybko zauważony, szczególnie jeśli organizacja nie monitoruje szczegółowo procesu przetwarzania plików i anomalii związanych z uploadami.

Rekomendacje

Podstawowym krokiem powinno być niezwłoczne wdrożenie poprawek dla wspieranych wersji Rails oraz weryfikacja, czy środowisko wykorzystuje odpowiednio nową wersję libvips. Organizacje powinny też potwierdzić, że aktywne jest blokowanie operacji niezaufanych, jeśli dana wersja biblioteki to obsługuje.

Równolegle należy potraktować incydent jako potencjalny wyciek sekretów i przeprowadzić ich rotację. Dotyczy to szczególnie elementów, do których proces aplikacji miał dostęp w czasie ekspozycji.

  • secret_key_base
  • klucz główny i poświadczenia Rails
  • dane dostępowe do baz danych
  • klucze usług przechowywania plików
  • tokeny API oraz poświadczenia usług zewnętrznych

Od strony operacyjnej warto wdrożyć dodatkowe środki ochronne:

  • ograniczyć możliwość przesyłania plików do zaufanych ról lub zweryfikowanych kont,
  • stosować zasadę najmniejszych uprawnień dla procesu aplikacyjnego,
  • zminimalizować dostęp aplikacji do lokalnych sekretów i plików systemowych,
  • monitorować nietypowe uploady oraz błędy przetwarzania obrazów,
  • przeanalizować logi historyczne pod kątem podejrzanych obrazów przesłanych przed instalacją poprawek,
  • rozważyć alternatywny backend przetwarzania obrazów tam, gdzie ma to uzasadnienie architektoniczne.

Podsumowanie

CVE-2026-66066 pokazuje, że nawet rutynowa funkcja aplikacyjna, taka jak obsługa obrazów, może stać się wektorem poważnego naruszenia bezpieczeństwa. W tym przypadku problem wynika z dopuszczenia niezaufanych operacji biblioteki libvips w ścieżce przetwarzania Active Storage.

Dla organizacji korzystających z Ruby on Rails oznacza to konieczność szybkiej aktualizacji frameworka, przeglądu zależności systemowych oraz oceny, czy nie doszło już do ekspozycji sekretów. Priorytet powinny otrzymać aplikacje publicznie dostępne i przyjmujące pliki od użytkowników.

Źródła

  1. https://thehackernews.com/2026/07/critical-rails-flaw-could-let.html
  2. https://github.com/rails/rails/security/advisories
  3. https://github.com/rails/rails
  4. https://www.libvips.org/API/8.17/func.block_untrusted_set.html
  5. https://www.libvips.org/API/8.17/flags.OperationFlags.html