Echa React2Shell: Puszka Pandory została otwarta

Ledwo zdążyliśmy ochłonąć po krytycznym błędzie React2Shell (tym z "dziesiątką" na skali CVSS, o którym pisałem wcześniej), a Vercel znów wysyła powiadomienia, które psują weekendową kawę.

W świecie bezpieczeństwa istnieje zjawisko, które nazywam "Efektem Latarki". Gdy w dużym, popularnym kodzie (jak Next.js czy React) pojawia się wielka dziura, tysiące badaczy bezpieczeństwa nagle kieruje tam swój wzrok. Wszyscy chcą znaleźć "tę drugą" lukę. I wiecie co? Właśnie ją znaleźli. A właściwie – znaleźli dwie.

Oto co musisz wiedzieć o nowych CVE, które wypłynęły 12 grudnia, i dlaczego Twoja poprzednia aktualizacja to za mało.

Co znaleziono w zgliszczach?

Wspólny wysiłek społeczności Bug Bounty (współpraca Vercel i Meta) ujawnił, że problem z React Server Components (RSC) jest głębszy, niż sądziliśmy. Mamy do czynienia z dwoma nowymi aktorami na scenie:

1. CVE-2025-55184: Pętla Śmierci (Denial of Service)

Zagrożenie: Wysokie

To klasyczny atak typu DoS, ale w nowoczesnym wydaniu. Złośliwe żądanie HTTP wysłane do endpointu App Routera może spowodować, że proces serwera zawiesi się, konsumując 100% CPU. Dzieje się to podczas deserializacji danych. Co ciekawe, biuletyn wspomina, że pierwsza poprawka dla tego błędu była niekompletna (co zaowocowało kolejnym numerkiem CVE-2025-67779). To pokazuje, jak skomplikowana jest to materia – nawet twórcy frameworka potrzebują kilku podejść, by zamknąć drzwi.

2. CVE-2025-55183: Ekshibicjonizm Kodu (Source Code Exposure)

Zagrożenie: Średnie

Tutaj sprawa jest mniej niszczycielska, ale bardziej wstydliwa. Specjalnie spreparowane żądanie może zmusić serwer do zwrócenia skompilowanego kodu źródłowego Server Actions. Dobra wiadomość? Jeśli postępujesz zgodnie ze sztuką i trzymasz sekrety (klucze API, hasła) w zmiennych środowiskowych (.env), a nie hardcodujesz ich w plikach .ts/.js, jesteś relatywnie bezpieczny. Zła wiadomość? Atakujący poznaje Twoją logikę biznesową. Widzi, jak walidujesz dane, jakie masz warunki brzegowe – a to doskonała mapa do planowania kolejnych ataków.

Dlaczego to jest ważne?

Po pierwsze: Zasięg. Problem dotyczy Reacta 19 (wersje 19.0.0 do 19.2.1) oraz Next.js (od wersji 13.x aż do najnowszych 16.x). Jeśli używasz App Routera, jesteś na celowniku.

Po drugie: Fałszywe poczucie bezpieczeństwa. Wielu adminów odetchnęło z ulgą po załataniu React2Shell. Komunikat Vercela jest jednak brutalnie jasny:

"Nawet klienci, którzy załatali React2Shell, muszą zaktualizować system do najnowszej wersji."

To nie jest opcjonalna łatka optymalizacyjna. To konieczność.

Refleksja na weekend

To, co obserwujemy, to dojrzewanie technologii React Server Components w bólach. Przeniesienie logiki renderowania na serwer zatarło granicę między frontendem a backendem, tworząc nowe wektory ataku, których dopiero się uczymy.

Pamiętajcie o zasadzie ograniczonego zaufania. Frameworki robią za nas wiele magicznych rzeczy, ale kiedy magia zawodzi, zostajemy z ręką w... logach serwera.

Co robić?

1. Nie czekaj do poniedziałku. Zaktualizuj next i react do najnowszych wersji (patchowanych od 12 grudnia).
2. Zrób audyt swojego kodu pod kątem hardcodowanych sekretów – CVE-2025-55183 nie wybacza lenistwa.
3. Jeśli hostujesz na Vercel – sprawdź dashboard, ale dla świętego spokoju przebuduj projekt (redeploy).

Bezpiecznego (i mam nadzieję, już spokojnego) weekendu.

Aleksander

Źródła:

• Security Bulletin: CVE-2025-55184 and CVE-2025-55183 - Vercel Knowledge Base

FAQ

Czy aktualizacja po React2Shell (CVE-2025-56546) wystarczy, by być bezpiecznym?

Nie. Te nowe podatności (CVE-2025-55184 i CVE-2025-55183) są odrębne i wymagają dodatkowej aktualizacji do wersji Next.js i React załatanych 12 grudnia 2024. Nawet jeśli zastosowałeś poprzednią łatkę, musisz zaktualizować ponownie.

Które wersje Next.js są zagrożone?

Problem dotyczy Next.js w wersjach od 13.x do najnowszych 16.x, które korzystają z App Router i React Server Components. Pages Router nie jest podatny na te konkretne CVE.

Czy moje sekrety API są bezpieczne po CVE-2025-55183?

Jeśli przechowujesz klucze API, hasła i inne sekrety w zmiennych środowiskowych (.env) zamiast hardcodować je w kodzie, są one bezpieczne. Atakujący może jednak zobaczyć logikę biznesową Twoich Server Actions, co może pomóc w planowaniu dalszych ataków.