Next.js łata krytyczne luki RCE i DoS w App Routerze oraz przetwarzaniu SVG

Wprowadzenie do problemu / definicja

Zespół Next.js opublikował pozaplanową aktualizację bezpieczeństwa, która eliminuje dwie krytyczne podatności umożliwiające zdalne wykonanie kodu bez uwierzytelnienia oraz jedną lukę typu denial-of-service. Problem dotyczy aplikacji korzystających z App Routera, mechanizmów use cache, Server Actions oraz wybranych ścieżek przetwarzania plików SVG przez bibliotekę sharp.

Dla organizacji rozwijających aplikacje webowe w oparciu o ten framework oznacza to konieczność pilnej weryfikacji wersji środowiska, zależności binarnych oraz rzeczywistej ekspozycji usług na nieufne dane wejściowe.

W skrócie

Wydano poprawki bezpieczeństwa dla gałęzi 16.x i 15.x.
Wersje naprawcze to 16.4.1 oraz 15.5.28.
Dwie luki mają charakter krytyczny i umożliwiają zdalne wykonanie kodu.
Trzecia podatność pozwala na przeciążenie procesu aplikacji przez specjalnie przygotowane żądania.
W części przypadków nie ma skutecznego obejścia poza aktualizacją.

Kontekst / historia

Incydent wpisuje się w rosnący trend zagrożeń dotyczących nowoczesnych frameworków full-stack, w których logika frontendowa i backendowa jest silnie zintegrowana. Next.js korzysta z rozbudowanego stosu komponentów serwerowych, mechanizmów cache, optymalizacji obrazów oraz akcji wykonywanych po stronie serwera, co zwiększa funkcjonalność, ale jednocześnie poszerza powierzchnię ataku.

W tym przypadku źródłem problemów są zarówno mechanizmy samego ekosystemu Next.js, jak i zależności upstream. Luka związana z use cache dotyczy ścieżki opartej o React Server Components, natomiast problem z SVG wynika z błędu pamięci w librsvg, do którego framework dochodzi pośrednio przez sharp. To pokazuje, że bezpieczeństwo aplikacji nie zależy wyłącznie od samego frameworka, ale również od stanu zabezpieczeń bibliotek natywnych i ich integracji.

Analiza techniczna

Pierwsza z krytycznych podatności dotyczy aplikacji używających App Routera z Cache Components. Warunkiem ekspozycji jest obecność funkcji use cache, która zwraca więcej niż jedną tablicę typowaną. W takiej konfiguracji możliwe jest doprowadzenie do zdalnego wykonania kodu bez uwierzytelnienia. W praktyce wskazuje to na błąd w obsłudze danych transportowanych między warstwami renderowania po stronie serwera.

Druga luka RCE obejmuje API optymalizacji obrazów w scenariuszu, gdy do przetwarzania trafiają pliki SVG kontrolowane przez atakującego. Kluczową rolę odgrywa tu zależność sharp, wykorzystująca librsvg. Jeżeli aplikacja działa na systemie Linux opartym o glibc, podatność może zostać wykorzystana do wykonania kodu. Ryzyko rośnie szczególnie tam, gdzie aplikacja przetwarza nieufne pliki SVG, na przykład w uploadach, generatorach miniaturek, dynamicznych podglądach lub funkcjach renderowania grafik po stronie serwera.

Istotnym aspektem operacyjnym jest to, że sama aktualizacja Next.js nie zawsze gwarantuje automatyczne podniesienie wszystkich zależności do bezpiecznych wersji, zwłaszcza w starszej linii utrzymaniowej. W środowiskach 15.x należy dodatkowo potwierdzić, że sharp zostało zaktualizowane co najmniej do wersji 0.35.5. W przeciwnym razie podatna biblioteka może nadal pozostawać w lockfile lub drzewie zależności mimo aktualizacji frameworka.

Trzecia podatność ma charakter DoS. Specjalnie spreparowane żądania kierowane do aplikacji wykorzystujących App Routera i przynajmniej jedną Server Action mogą prowadzić do pełnego zużycia CPU przez pojedynczy proces. Efektem jest zablokowanie obsługi kolejnych żądań w tym samym procesie, co może przełożyć się na degradację wydajności i częściową niedostępność usługi.

Konsekwencje / ryzyko

Ryzyko biznesowe jest wysokie przede wszystkim dlatego, że dwie najpoważniejsze luki nie wymagają uwierzytelnienia i dotyczą warstwy serwerowej aplikacji. Skuteczne wykorzystanie podatności RCE może umożliwić wykonanie poleceń w kontekście procesu aplikacyjnego, a następnie doprowadzić do kradzieży danych, modyfikacji odpowiedzi HTTP, ruchu bocznego w infrastrukturze lub instalacji trwałych mechanizmów dostępu.

Podatność związana z przetwarzaniem SVG jest szczególnie groźna dla platform akceptujących treści od użytkowników albo dynamicznie generujących grafiki. Nawet jeśli organizacja nie traktuje SVG jako głównego wektora wejścia, format ten może pojawiać się w wielu miejscach, takich jak uploady, pipeline assetów czy integracje z zewnętrznymi narzędziami marketingowymi.

Luka DoS nie prowadzi bezpośrednio do wykonania kodu, ale może zostać wykorzystana do skutecznego zakłócenia działania usługi. W środowiskach o ograniczonej liczbie workerów lub architekturach serverless skutki mogą być odczuwalne niemal natychmiast.

Rekomendacje

Najważniejszym działaniem jest niezwłoczne przejście na Next.js 16.4.1 lub 15.5.28, a następnie pełny rebuild i redeploy aplikacji. Samo podniesienie wersji w plikach konfiguracyjnych bez odtworzenia artefaktów wdrożeniowych może nie wystarczyć.

Zweryfikować, czy aplikacja używa App Routera, Cache Components, use cache oraz Server Actions.
Sprawdzić rzeczywistą wersję sharp w drzewie zależności i upewnić się, że wynosi co najmniej 0.35.5.
Przeanalizować, czy aplikacja przetwarza nieufne pliki SVG lub ma aktywną ich optymalizację.
Ograniczyć albo wyłączyć ścieżki przetwarzania SVG tam, gdzie nie są niezbędne.
Przeprowadzić testy regresyjne obejmujące generowanie obrazów, cache i akcje serwerowe.
Monitorować zużycie CPU, błędy procesu Node.js oraz anomalie w ścieżkach renderowania obrazów.
Dodać do pipeline CI/CD kontrolę wersji zależności natywnych, a nie tylko samego frameworka.

Jeżeli natychmiastowa aktualizacja nie jest możliwa, minimalnym działaniem ograniczającym ryzyko dla luki SVG jest wymuszenie bezpiecznej wersji sharp lub zablokowanie ładowania plików SVG po stronie biblioteki obrazowania. Dla podatności związanej z use cache oraz dla luki DoS nie wskazano jednak pełnowartościowego obejścia, dlatego zwłoka z aktualizacją zwiększa poziom ekspozycji.

Podsumowanie

Pozaplanowa aktualizacja Next.js eliminuje dwie krytyczne luki RCE i jedną istotną podatność DoS, które dotyczą zarówno nowoczesnych mechanizmów frameworka, jak i jego zależności upstream. Szczególnie narażone są aplikacje korzystające z App Routera, use cache, Server Actions oraz przetwarzania SVG.

Z perspektywy operacyjnej kluczowe znaczenie mają szybka aktualizacja, kontrola rzeczywistej wersji sharp oraz przegląd wszystkich miejsc, w których aplikacja przetwarza dane dostarczane przez użytkownika. To kolejny przykład, że bezpieczeństwo współczesnego stosu webowego zależy nie tylko od frameworka, ale również od jakości zarządzania zależnościami i procesu wdrożeniowego.