Luki w PHP i Node.js: czy musisz coś zrobić?

21 października zespoły PHP i Node.js wydały poprawki bezpieczeństwa. Pilniejsza jest aktualizacja PHP: wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 zamykają dwie luki z oceną 9,2 na 10 w skali CVSS 4.0, przez które atakujący może bez logowania uruchomić własny kod na serwerze. Amazon informuje, że luki są już szeroko wykorzystywane w atakach. Node.js wydał wersje 22.23.4, 24.22.1 i 26.12.1, a wśród poprawek jest błąd mogący skończyć się wykonaniem cudzego kodu. Jeśli stronę albo aplikację z Cursora czy Claude Code wrzuciłeś na własny hosting, serwer VPS albo do Dockera i od wdrożenia nie zaglądałeś na serwer, sprawdź wersje jeszcze dziś. Vibe coding postawi stronę w weekend, ale za pół roku nie podbije za Ciebie wersji PHP ani Node.

Dwie krytyczne luki w PHP

Komunikat na php.net opisuje dwa błędy w miejscach, przez które przechodzi niemal każde zapytanie do strony. Pierwszy (CVE-2026-109618) ujawnia się, gdy podczas obsługi zapytania zabraknie pamięci, a drugi (CVE-2026-109619) zostawia w procesie PHP ślad po poprzednim zapytaniu. W obu przypadkach PHP traktuje niedokończone albo nieaktualne dane jak poprawne, co otwiera drogę do uruchomienia obcego kodu. Obie luki mają w opisach zespołu PHP (GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp) ocenę 9,2.

Zagrożona jest według php.net każda instalacja obsługująca ruch z sieci, niezależnie od sposobu uruchomienia PHP. Najwyższe ryzyko dotyczy mod_php, czyli PHP wbudowanego w serwer Apache. W tej konfiguracji pokazano atak, który działa jeszcze przed uruchomieniem kodu Twojej aplikacji. Firma Calif, jedna z tych, które zgłosiły luki, potwierdziła zdalne wykonanie kodu bez logowania między innymi w WordPressie, Laravelu i phpMyAdminie. Zespół PHP wymienia ustawienia, które blokują niektóre sposoby ataku, ale pisze wprost, że jedynym bezpiecznym wyjściem jest aktualizacja.

Ataki ruszyły przed łatką

Wydanie planowano na 22 października, ale według PHP Foundation dwa dni wcześniej numery obu luk trafiły na fora i do mediów społecznościowych, choć bez szczegółów technicznych. Zespół przyspieszył więc publikację o dzień. Wieczorem Calif omyłkowo opublikował nagranie działającego ataku, a kopie skasowanego filmu rozeszły się w sieci i według fundacji przyspieszyły powstawanie exploitów, czyli gotowych programów do ataku.

Amazon Threat Intelligence zarejestrował pierwszą próbę ataku na swoje serwery pułapki już 17 października, cztery dni przed ujawnieniem luk. Po publikacji poprawek nowe exploity pojawiały się w ciągu godzin, a Amazon pisze, że luka nazywana PHP2Shell jest już szeroko wykorzystywana. Dodaje też, że analiza wspierana przez AI pozwala szybciej zamienić opis poprawki w działający atak.

Strony korzystające z Cloudflare dostały reguły zapory blokujące znane warianty ataku, także w darmowym planie, co ogłosił szef technologii firmy Dane Knecht. Sam nazwał je jednak rozwiązaniem tymczasowym, które nie zastępuje aktualizacji.

PHP 8.1 i starsze: zostaje zmiana wersji

Wydania z 21 października obejmują PHP od 8.2 do 8.5. PHP 8.1 straciło wsparcie 31 grudnia 2025 roku (lista na php.net) i nowej wersji nie dostanie. Zespół PHP udostępnił minimalne poprawki w kodzie źródłowym dla 7.4, 8.0 i 8.1, są one jednak przeznaczone dla tych, którzy sami kompilują PHP. Część dystrybucji Linuksa łata starsze wersje na własną rękę: Ubuntu 22.04 dostało poprawiony pakiet PHP 8.1. Na zwykłym hostingu masz jednak jedno wyjście: przełączyć stronę na wspieraną wersję.

Którą wybrać? Według harmonogramu php.net PHP 8.2 dostaje poprawki bezpieczeństwa tylko do 31 grudnia 2026 roku, więc przejście na nie odsuwa problem o dwa miesiące. PHP 8.3 dostanie poprawki bezpieczeństwa do końca 2027 roku, 8.4 do końca 2028, a 8.5 do końca 2029. Rozsądny wybór to 8.4 albo 8.3. Przejście na nowszą wersję potrafi coś zepsuć, więc zrób kopię zapasową, przełącz wersję i przeklikaj najważniejsze podstrony.

Node.js: poprawki dla 22, 24 i 26, Node 20 bez wsparcia

Wydanie Node.js z 21 października łata cztery luki o wysokim poziomie zagrożenia, trzy o średnim i trzy o niskim. Jedna z luk o wysokim poziomie zagrożenia (CVE-2026-111497) to błąd przy rozpakowywaniu danych skompresowanych w popularnym formacie Brotli: zapis poza przydzielonym obszarem pamięci, który według projektu pozwala atakującemu uruchomić własny kod. Dwie inne pozwalają w pewnych warunkach obejść sprawdzanie, czy certyfikat szyfrowanego połączenia pasuje do adresu serwera. Poprawki zawierają wersje 22.23.4, 24.22.1 i 26.12.1.

Node.js 20 stracił wsparcie 30 kwietnia 2026 roku (harmonogram wydań), a projekt zaznacza, że luki łatane w wydaniach bezpieczeństwa zawsze dotyczą też wersji bez wsparcia, które poprawek już nie dostają. Najprościej przejść na Node 24, obecną wersję z długoterminowym wsparciem (LTS) i poprawkami do 30 kwietnia 2028 roku. Node 22 dostaje je do 30 kwietnia 2027. Na Vercelu do wyboru są tylko wersje 22.x i 24.x, a dokumentacja mówi, że platforma sama podmienia wersje poprawkowe, gdy trzeba załatać lukę.

Czy to Cię dotyczy

• Publikacja przyciskiem w Lovable, Bolcie czy v0: jeśli nigdy nie dostałeś dostępu do serwera, środowiskiem zarządza platforma i wersji PHP ani Node nie wybierasz.
• Zwykły hosting z panelem: wersję PHP, na przykład 8.3 czy 8.4, wybierasz Ty, a poprawki w jej obrębie instaluje firma hostingowa.
• VPS lub własny serwer: wszystko jest na Twojej głowie, łącznie z restartem usług.
• Docker: wersje PHP i Node są zapisane w obrazie, więc trzeba go przebudować.

Co sprawdzić w 5 minut

Hosting z panelem. W cPanelu wersję PHP pokazuje MultiPHP Manager, w innych panelach szukaj ustawienia „Wersja PHP”. Jeśli widzisz 8.1 albo starszą, przełącz na 8.4 lub 8.3. Przy 8.2 i nowszych zapytaj obsługę klienta, czy serwer ma już poprawki z 21 października.

VPS. Polecenia php -v i node -v w terminalu pokażą wersje. Node zainstalowany z nodejs.org lub przez nvm powinien mieć co najmniej 22.23.4, 24.22.1 albo 26.12.1. PHP z pakietów dystrybucji ma inny numer, bo dystrybucje przenoszą poprawki do własnych wersji. Na Ubuntu 24.04 łatka dla PHP 8.3 to pakiet 8.3.6-0ubuntu0.24.04.13, a na Debianie 13 pakiet 8.4.27-1~deb13u1. Zaktualizuj więc system (sudo apt update && sudo apt upgrade) i upewnij się, że PHP-FPM albo Apache zostały uruchomione ponownie.

Docker. Obraz to migawka z chwili budowania (dokumentacja Dockera), więc sam restart kontenera niczego nie zmieni. Ustaw w pliku Dockerfile wspieraną wersję obrazu bazowego, na przykład php:8.4-apache albo node:24, zbuduj obraz z flagą --pull, żeby Docker pobrał świeżą bazę, i uruchom kontener od nowa. Oficjalne obrazy z poprawionymi wersjami są już na Docker Hubie. Jeśli obraz jest przypięty do konkretnego skrótu (zapis @sha256:…), Docker nie pobierze nowej wersji sam: musisz wpisać nowy skrót.

Co napisać agentowi

Jeśli projekt i dostęp do serwera ma Twój agent AI, wklej mu polecenie w rodzaju:

Sprawdź, na czym działa ten projekt i jego serwer: wersję PHP (php -v),
Node.js (node -v) oraz obrazy bazowe w Dockerfile i docker-compose.yml.
Porównaj je z wydaniami z poprawkami z 21 października 2026:
PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 oraz Node.js 22.23.4, 24.22.1, 26.12.1.
Jeśli PHP pochodzi z pakietów dystrybucji, sprawdź jej komunikat bezpieczeństwa.
Jeśli to PHP 8.1 lub starsze albo Node 20 lub starszy, zaproponuj przejście
na PHP 8.4 i Node 24 z listą rzeczy, które mogą się zepsuć.
Niczego nie zmieniaj na serwerze i niczego nie wdrażaj bez mojej zgody.

Jeśli aplikacja działa na Next.js, sprawdź też wrześniowe łatki tego frameworka.