Zmienne środowiskowe to miejsce, w którym aplikacja webowa trzyma swoje najpilniej strzeżone dane. Klucz podpisujący sesje użytkowników, hasła do bazy, tokeny do usług zewnętrznych. 29 lipca 2026 zespół Ruby on Rails opublikował ostrzeżenie, z którego wynika, że w domyślnej konfiguracji dało się je odczytać z zewnątrz. Bez logowania, bez konta, bez żadnego uprawnienia. Wystarczyło, że aplikacja przyjmuje obrazy od użytkowników i pokazuje ich przeskalowane wersje. Ocena krytyczna, 9,5 punktu w dziesięciostopniowej skali. Poprawki są już dostępne, a doniesień o wykorzystaniu w atakach na razie nie ma.
Które wersje trzeba podbić
To jedyna część tego tekstu, którą trzeba przeczytać od razu. Reszta może poczekać.
Podatne wersje biblioteki activestorage:
- wszystkie starsze niż 7.2.3.2
- od 8.0 włącznie do wersji starszych niż 8.0.5.1
- od 8.1 włącznie do wersji starszych niż 8.1.3.1
Wersje z poprawką to 7.2.3.2, 8.0.5.1 oraz 8.1.3.1. Sama podmiana numeru w pliku zależności jednak nie wystarczy, i to jest miejsce, w którym łatwo się potknąć. Ostrzeżenie stawia drugi warunek: minimalna wersja samego silnika libvips musi zostać podniesiona do 8.13 lub nowszej.
Jeżeli podniesienie samego gemu nie jest możliwe od razu, autorzy podają obejście. Można ustawić zmienną środowiskową VIPS_BLOCK_UNTRUSTED, którą libvips czyta przy starcie, albo wywołać Vips.block_untrusted(true) z poziomu inicjalizatora, przy bibliotece ruby-vips w wersji 2.2.1 lub nowszej. Obejście nie zwalnia jednak z wymogu libvips w wersji 8.13 lub nowszej, bo to właśnie ta wersja wprowadza blokadę, którą się tu włącza. Dla starszego libvips ostrzeżenie żadnej alternatywy nie przewiduje.
Na czym polega błąd
Active Storage to część Railsów odpowiedzialna za obsługę plików wgrywanych przez użytkowników. Kiedy trzeba pokazać miniaturę albo przeskalowaną wersję zdjęcia, biblioteka przekazuje robotę silnikowi graficznemu libvips.
Libvips ma w sobie zestaw operacji, które jego właśni autorzy oznaczyli jako niebezpieczne dla treści pochodzącej z nieznanego źródła. Nie chodzi o błąd w kodzie. Chodzi o funkcje, które z założenia robią więcej, niż potrzeba do przycięcia zdjęcia, i dlatego nie powinny być dostępne, gdy plik przyszedł od przypadkowej osoby z internetu. Active Storage tych operacji nie wyłączał. Nie w jakiejś nietypowej konfiguracji, tylko w tej, którą projekt dostaje po instalacji.
To zresztą najciekawszy element całej sprawy. Ostrzeżenie nie mówi o luce w rzadko używanym dodatku, w który trzeba było celowo wejść. Mówi o ustawieniu, którego nikt nie ruszał, bo nie było powodu.
Kiedy aplikacja jest podatna
Zbieg okoliczności musi być pełny, ale jest to zbieg wyjątkowo pospolity. Warunki są trzy:
- aplikacja stoi na Railsach i korzysta z Active Storage,
- przetwarzanie obrazów działa na libvips, czyli tak, jak jest ustawione domyślnie od wersji 7.0,
- użytkownicy mogą wgrywać własne pliki graficzne.
Trzeci punkt wygląda na zawężenie, dopóki nie pomyśli się, jak często ten warunek bywa spełniony. Awatar w profilu, zdjęcie produktu w panelu sprzedawcy, załącznik w zgłoszeniu do obsługi klienta, skan dokumentu w formularzu. Żadna z tych funkcji nie jest egzotyczna. Ilu aplikacji dotyczy to realnie, nie wiadomo, bo takich danych nikt nie publikuje.
Frontend Master 2026 · Kodożercy
Pisz kod, nie tylko prompty
Frontend Master 2026 to pakiet sześciu kursów Kodożerców (HTML, CSS, JavaScript, Git) w polskim wideo z 12-miesięcznym dostępem. Fundamenty frontu od pierwszej linijki kodu do deploy.
Wchodzę w to →
Dlaczego odczyt pliku jest gorszy, niż brzmi
Sformułowanie “odczyt dowolnych plików z serwera” sugeruje problem umiarkowany. Ktoś zobaczy jakiś plik konfiguracyjny, trudno. Ocena 9,5 punktu bierze się z tego, co da się zrobić dalej.
W ostrzeżeniu wprost wymieniono zmienne środowiskowe procesu, a wśród nich secret_key_base. To wartość, którą Rails podpisuje ciasteczka sesyjne. Autorzy opisują też dalszą drogę: od wykradzionych sekretów do zdalnego wykonania kodu i do wejścia w systemy zewnętrzne, do których aplikacja ma dostęp. Trzeba się tu trzymać ostrożnego języka, bo to opisana możliwość eskalacji, a nie zaobserwowany przebieg ataku.
Praktyczny wniosek jest mimo to niewygodny i sami autorzy stawiają go wprost. Aktualizacja domyka dziurę, natomiast nie cofa tego, co mogło wyciec wcześniej. Ostrzeżenie ma osobną sekcję o wymianie sekretów i zaleca potraktować każdy sekret czytelny dla procesu aplikacji jako potencjalnie ujawniony. Wymienia przy tym konkretnie: secret_key_base, klucz główny wraz z całą zawartością config/credentials.yml.enc, dane dostępowe do usługi przechowywania plików, dane do bazy oraz tokeny i klucze do usług zewnętrznych.
Czego w ostrzeżeniu nie ma
Nie ma niczego o wykorzystaniu w atakach. W amerykańskiej rządowej liście podatności aktywnie wykorzystywanych, sprawdzonej 29 lipca 2026, tego wpisu nie znajdziemy, a najnowsze pozycje pochodzą z 27 lipca i dotyczą innych produktów. Brak wpisu na tej liście nie dowodzi oczywiście, że nikt nigdzie nie próbował. Znaczy tyle, że w sprawdzonych przez nas źródłach nie ma na to żadnego śladu. Nie ma też danych o skali, czyli o tym, ile aplikacji faktycznie spełniało wszystkie trzy warunki. Na tle luki w WordPressie z tego miesiąca, gdzie liczbę instalacji da się oszacować, tutaj poruszamy się po omacku. Wyraźnie lepiej wygląda za to sama reakcja producenta, zwłaszcza w zestawieniu z przypadkiem Quick.CMS, gdzie poprawki po prostu nie będzie. Rails wydał trzy wersje naprawcze równolegle z publikacją ostrzeżenia.
Podsumowanie
Trzy numery wersji domykają tę sprawę po stronie kodu: 7.2.3.2, 8.0.5.1 i 8.1.3.1. Do tego dochodzi warunek, o którym łatwo zapomnieć, bo nie widać go w pliku zależności — silnik libvips musi być w wersji 8.13 lub nowszej. Podatność dotyczy Active Storage w wersjach starszych niż wymienione i została oceniona na 9,5 punktu, ponieważ w domyślnej konfiguracji pozwalała nieuwierzytelnionej osobie odczytać dowolne pliki z serwera razem ze zmiennymi środowiskowymi procesu. Przyczyną było to, że Active Storage nie wyłączał operacji libvips oznaczonych przez samych autorów jako niebezpieczne dla plików z nieznanego źródła. Wystarczyło, że aplikacja przyjmuje obrazy od użytkowników. Śladu wykorzystania w atakach w sprawdzonych źródłach nie ma. Aktualizacja zamyka dziurę, ale nie cofa wcześniejszego wycieku, dlatego autorzy zalecają wymienić każdy sekret dostępny procesowi aplikacji.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
