Krytyczne luki w PHP – zaktualizuj teraz (CVE-2026-109618 i CVE-2026-109619)

20 października projekt PHP zapowiedział wydanie bezpieczeństwa dotyczące dwóch krytycznych luk. 21 października o 13.30 UTC opublikowano poprawki. Obie luki umożliwiają nieuwierzytelnione zdalne wykonanie kodu przy CVSS 9,2, a publiczny kod proof-of-concept już krąży.

To nie jest luka, którą planujecie na następne okno serwisowe. To luka, którą naprawiacie dziś.

W skrócie

• Zaktualizujcie do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35.
• Zagrożone jest każde PHP obsługujące żądania HTTP – PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed.
• Może wystarczyć jedno nieuwierzytelnione żądanie, a atak może nastąpić, zanim uruchomi się kod Waszej aplikacji.
• Kod PoC jest publiczny. Liczcie się z masowym skanowaniem w ciągu godzin, nie tygodni.
• Jeśli nie możecie załatać od razu: odizolujcie usługi wystawione do internetu, dopóki poprawka nie zostanie wdrożona i zweryfikowana.

Co się stało

20 października projekt PHP poinformował, że szykuje wydanie bezpieczeństwa. Następnego dnia, 21 października o 13.30 UTC, poprawki opublikowano jednocześnie w czterech wersjach: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. CERT-EU wydał tego samego dnia ostrzeżenie i wezwał organizacje do natychmiastowej aktualizacji.

Szybka poprawka to dobrze. To, że opis techniczny stał się jednocześnie publiczny, oznacza, że czas od „poprawka istnieje" do „napastnicy próbują" mierzy się w godzinach.

Co te luki faktycznie robią

CVE-2026-109618 – uszkodzenie pamięci na granicy limitu

PHP zatrzymuje żądanie przekraczające memory_limit, przerywając je wywołaniem longjmp(). Przerwanie może więc nastąpić w środku wewnętrznej operacji, gdy dane żądania są tylko częściowo zainicjalizowane – na przykład podczas parsowania wysyłania pliku w formularzu.

Sprzątanie żądania może następnie potraktować nieprawidłowe dane jako poprawne i zwolnić pamięć, która nigdy nie została zainicjalizowana. W tej pamięci mogą wciąż znajdować się dane z wcześniejszych przydziałów, kontrolowane przez napastnika. Efektem jest uszkodzenie pamięci, które może prowadzić do wykonania kodu.

CVE-2026-109619 – pozostały stan globalny

Stan wewnętrzny należący do jednego żądania może przetrwać po zwolnieniu jego pamięci – na przykład po błędzie krytycznym. Późniejsze żądanie obsługiwane przez ten sam proces roboczy może użyć pozostałego stanu, zanim normalna inicjalizacja zdąży go wyzerować.

Żadna z luk nie wymaga więc błędu w Waszej aplikacji. Siedzą w samym mechanizmie obsługi żądań PHP.

Zademonstrowany exploit pokazuje, że jedno nieuwierzytelnione żądanie może wywołać atak, zanim wykona się jakikolwiek kod aplikacji.

Kogo dotyczy

Wszystkie instalacje PHP obsługujące ruch HTTP. Zespół PHP uważa mod_php za najbardziej narażoną konfigurację.

• PHP 8.5 przed 8.5.12
• PHP 8.4 przed 8.4.27
• PHP 8.3 przed 8.3.36
• PHP 8.2 przed 8.2.35
• Gałęzie wycofane z wsparcia (PHP 8.1 i starsze), które nie otrzymują już regularnych aktualizacji

Dodatkowo: wiele produktów komercyjnych i open source używa PHP pod spodem. Mogą być zagrożone, nawet jeśli nie prowadzicie własnej instalacji PHP. NCSC-NL opublikował listę oprogramowania firm trzecich, w które wbudowano PHP.

Najczęstszy błąd, jaki widzimy: liczenie tylko serwerów, które sami postawiliście. Nie zapominajcie o kontenerach, obrazach CI, urządzeniach, narzędziach wewnętrznych i usługach prowadzonych przez dostawców.

Sprawdźcie sytuację – pięć minut na środowisko

1. Uruchomcie php -v na każdym hoście i w każdym kontenerze. Nie tylko na jednym.
2. Zinwentaryzujcie środowiska uruchomieniowe: pule PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Przebudujcie obrazy kontenerów – liczy się obraz bazowy, nie działająca instancja.
4. Zapytajcie dostawców, którzy prowadzą dla Was produkty zależne od PHP: jaką wersję uruchamiacie i kiedy będziecie po aktualizacji?
5. Znajdźcie gałęzie wycofane z wsparcia. PHP 8.1 i starsze nie dostają regularnych poprawek.

Naprawcie

Pakiety dystrybucji. Dystrybucje Linuksa i dostawcy LTS mieli poprawki wcześniej. Zaktualizujcie przez menedżer pakietów i zrestartujcie procesy robocze.

Kontenery. Zaktualizujcie obraz bazowy i przebudujcie. Restart starego obrazu niczego nie rozwiązuje.

Kompilacja własna. Zaktualizujcie do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35.

Wersje wycofane z wsparcia. Zespół PHP opublikował minimalne backporty dla 7.4, 8.0 i 8.1 dla tych, którzy kompilują ze źródeł lub nie mają dostawcy LTS. Jeśli macie dostawcę LTS: najpierw skontaktujcie się z nim.

rpms.remirepo.net: to utrzymywane społecznie repozytorium nie otrzymuje aktualizacji w dniu wydania. Zespół PHP zachęca do przejścia na pakiety dystrybucji lub kompilacji ze źródeł.

Po aktualizacji zrestartujcie PHP-FPM i pozostałe procesy robocze. Nowy plik binarny bez restartu to nadal stary proces.

Jeśli nie możecie załatać dziś

Poniższe działania ograniczają narażenie na konkretne ścieżki ataku. Nie czynią instalacji bezpieczną. Tylko aktualizacja zamyka lukę.

Przeciw CVE-2026-109618:

• Ustawcie memory_limit=-1 w sposób, którego aplikacja nie może nadpisać, na przykład php_admin_value w puli FPM lub w konfiguracji Apache. Sprawdźcie, czy żadna pula, katalog ani ustawienie aplikacji nie przywraca limitu.
• Ustawcie niski post_max_size: 8M dla aplikacji bez wysyłania plików, 32M tam, gdzie wysyłanie jest konieczne. Trzymajcie upload_max_filesize poniżej post_max_size.
• Ustawcie w serwerze WWW lub proxy limity zdekodowanego rozmiaru żądania, liczby pól, liczby części multipart, liczby nagłówków i głębokości zagnieżdżenia. Limity muszą obejmować także żądania bez użytecznego Content-Length.
• Użyjcie limitu pamięci kontenera lub cgroup jako limitu dostępności, najlepiej z polityką zabijającą tylko dotknięty proces roboczy. Nie używajcie RLIMIT_AS ani RLIMIT_DATA – mogą wywołać podatną ścieżkę alokacji.

Przeciw CVE-2026-109619:

• Ustawcie session.upload_progress.enabled=0 i zrestartujcie każdy proces roboczy. Ustawcie to w php.ini, w puli FPM lub w konfiguracji serwera, aby działało przed parsowaniem żądania. Nie liczcie na ini_set() ani .user.ini FPM.
• W PHP 8.5: ustawcie fatal_error_backtraces=0 i zrestartujcie każdy proces roboczy.
• Usuńcie nieprawidłowe lub przestarzałe ustawienia na poziomie żądania, które emitują diagnostykę przed inicjalizacją. Ukrywanie diagnostyki przez error_reporting, display_errors lub @ nie pomaga.
• Naprawcie błędy krytyczne i limity czasu wykonania, do których napastnik może dotrzeć – w callbackach, wysyłaniu, imporcie i sprzątaniu.

Dlaczego nie warto czekać

Trzy rzeczy odróżniają to zdarzenie od zwykłej poprawki:

1. Uwierzytelnienie nie jest wymagane. Nie ma logowania, za którym można się schować.
2. Atak następuje przed Waszym kodem. Logika aplikacji, reguły WAF i model uprawnień nie są tu barierą.
3. PoC jest już publiczny. To, co zwykle zajmuje tygodnie, ktoś już zrobił.

Koszt poprawki i restartu dziś jest znikomy wobec kosztu włamania. Dotyczy to zwłaszcza tych, których obejmuje NIS2 – o istotnym incydencie trzeba zgłosić w ciągu 24 godzin.

Po poprawce – trzy rzeczy

1. Zweryfikujcie na każdym węźle. Wersję – nie tylko to, że menedżer pakietów powiedział OK.
2. Przeczytajcie logi wstecz. Żądania multipart POST, nieoczekiwane odpowiedzi 500, zawieszone procesy robocze i ruch z nieznanych źródeł z ostatnich dni.
3. Przy najmniejszym podejrzeniu: uruchomcie procedurę incydentu. Odizolujcie, zabezpieczcie logi, oceńcie obowiązek zgłoszenia.

Źródła

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, lista produktów z wbudowanym PHP: https://github.com/NCSC-NL/php2shell

---

Takie luki są same w sobie argumentem za ciągłą ochroną: aktualizacje, weryfikacja i monitoring, które trwają cały czas – a nie coroczny przegląd. Przeczytaj więcej o tym, co ciągła ochrona oznacza w praktyce.