Dwie nowo ujawnione podatności CVE — CVE-2025-55182 w React Server Components oraz CVE-2025-29927 w middleware Next.js — otwierają drogę do zdalnego wykonania kodu (RCE) i obejścia uwierzytelniania w nowoczesnych stosach JavaScript. Pojedyncze żądanie może wywołać te błędy; sama konfiguracja nie jest w stanie ich powstrzymać. Zespoły polegające na React Server Components lub middleware Next.js muszą potraktować te błędy jako pilne i natychmiast wdrożyć poprawki.

Dlaczego szum w logach jest mylący

Przeanalizowaliśmy logi brzegowe (edge logs) z miesięcznej pracy produkcyjnej witryny Next.js. Zbiór zawierał 8 900 żądań oznaczonych jako złośliwe. Prawie każde z nich zakończyło się niepowodzeniem już przy pierwszym przeskoku (hop). Najczęstszym adresem URL było /wp-admin/install.php, które pojawiło się 518 razy, mimo że witryna nie korzysta z WordPressa, nie używa PHP i nie posiada żadnych plików WordPressa.

Automatyczne skanery generują taki ruch. Rozsyłają one po internecie zgadywanki, szukając:

  • Tajne dane i pliki konfiguracyjne – 64% prób
  • Panele i powłoki PHP – 22%
  • Ścieżki WordPress – 11%
  • Narzędzia bazodanowe – 1%

Wysoka liczba zablokowanych żądań mówi Ci jedynie, że nie uruchamiasz oprogramowania, którego spodziewają się boty. Nie gwarantuje to, że aplikacja, którą faktycznie uruchamiasz, jest bezpieczna.

Ciche ataki na poziomie frameworka

Gdy atakujący celuje w aplikację Next.js, ruch wygląda jak zwykłe żądania użytkowników, wykorzystując mechanizmy samego frameworka przeciwko niemu.

React2Shell (CVE-2025-55182)

Luka w React Server Components pozwala atakującemu na wstrzyknięcie specjalnie przygotowanego ładunku (payload), który serwer interpretuje jako kod. Rezultatem jest pełne zdalne wykonanie kodu bez konieczności omijania zapory sieciowej (firewall) czy filtra aplikacji webowych (WAF). Podatność znajduje się wewnątrz frameworka; jedynym rozwiązaniem jest aktualizacja do wersji zawierającej poprawkę.

Obejście autoryzacji w middleware (CVE-2025-29927)

Middleware w Next.js może wymuszać kontrole bezpieczeństwa na podstawie nagłówków żądań. Ta podatność CVE pokazuje, że atakujący może dostarczyć konkretny wewnętrzny nagłówek, powodując całkowite pominięcie tych kontroli przez middleware. Z zewnątrz żądanie wygląda na zwyczajne, co utrudnia wykrycie.

Oba błędy pokazują, że najbardziej niebezpieczny ruch może wtapiać się w codzienny ruch, omijając alarmy wyłapujące głośne próby ataku na WordPressa.

Co jest stawką

  • Programiści, którzy traktują aktualizacje frameworków jako opcjonalne, ryzykują całkowite przejęcie swoich serwerów.
  • Zespoły operacyjne, które polegają na statycznej konfiguracji w celu utwardzenia (hardening) stosu, nie są w stanie chronić się przed kodem uruchamianym wewnątrz samego frameworka.

Praktyczna lista kontrolna obrony

  1. Higiena wdrożeń – Nie przesyłaj sekretów w plikach takich jak .env. Przechowuj je w zmiennych środowiskowych dostarczanych w czasie wykonywania (runtime) lub w dedykowanym systemie zarządzania sekretami.
  2. Minimalna powierzchnia ataku – Wyłącz funkcje frameworka, których nie używasz. Wdróż rygorystyczną politykę Content-Security-Policy, która blokuje ładowanie nieautoryzowanych skryptów.
  3. Szybkie łatanie – Zautomatyzuj potok budowania (build pipeline), aby nowa wersja frameworka mogła zostać przetestowana i wdrożona w ciągu kilku godzin od wydania. Traktuj aktualizacje bezpieczeństwa jako regularny element cyklu wydawniczego, a nie jako dodatek.

Na co zwrócić uwagę w przyszłości

  • Subskrybuj oficjalne kanały powiadomień o bezpieczeństwie dla React, Next.js oraz wszelkich innych bibliotek runtime, od których zależy Twój projekt.
  • Integruj skanery podatności, które rozumieją metadane pakietów JavaScript, dzięki czemu nowo opublikowana podatność CVE wywoła automatyczny alert.
  • Zbuduj potok wdrożeniowy umożliwiający szybkie wycofanie zmian (rollback); jeśli poprawka wprowadzi regresje, będziesz mógł szybko wrócić do poprzedniej wersji, nie pozostawiając systemu bez ochrony.

Lekcja jest jasna: najgłośniejsze ataki w Twoich logach to często dezinformacja. Prawdziwe niebezpieczeństwo kryje się w frameworku, któremu ufa Twój kod. Dbaj o to, aby stos był lekki, przechowuj sekrety bezpiecznie i traktuj poprawki jako rutynę, a zmienisz ciche zagrożenia na poziomie frameworka w zarządzalne ryzyka.