1 Znajdź każdą wersję PHP na serwerze

Wiele serwerów uruchamia więcej niż jedno PHP: pakiet systemowy, wersje zainstalowane przez panel administracyjny (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), kontenery oraz kompilacje wiersza poleceń używane przez cron. Każde PHP obsługujące żądania WWW musi zostać zaktualizowane.

Uruchom php -v, wyświetl procesy php-fpm poleceniem ps aux | grep php-fpm i sprawdź selektor PHP w panelu.

2 Zaktualizuj do poprawionej wersji

Poprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Pakiety dystrybucji mogą zawierać poprawkę pod starszym numerem wersji — sprawdź w changelogu CVE-2026-109618 i CVE-2026-109619.

PHP 8.1 i starsze nie otrzymują wydania od projektu PHP. Dla osób kompilujących ze źródeł opublikowano minimalne backporty dla 7.4, 8.0 i 8.1, ale trwałym rozwiązaniem jest przejście na wspieraną gałąź.

Debian / Ubuntu (pakiety dystrybucji)

Zainstaluj aktualizację bezpieczeństwa z dystrybucji i zrestartuj PHP. Numer wersji może pozostać bez zmian; changelog pakietu wymienia CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Zastosuj erratę dostawcy dla swojego strumienia modułu PHP, a następnie zrestartuj.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / oficjalne obrazy php

Pobierz lub zbuduj obraz z poprawionym tagiem i odtwórz kontenery.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Użyj narzędzia aktualizacji w panelu dla każdej zainstalowanej wersji PHP (EA-PHP, handlery PHP w Plesku, alt-php, CustomBuild), a następnie zrestartuj PHP-FPM. Panele często zachowują stare wersje dla poszczególnych stron — je również zaktualizuj lub usuń.

Hosting współdzielony lub zarządzany

Zazwyczaj nie można samodzielnie zaktualizować PHP. Użyj wiadomości z karty wyniku, aby zapytać dostawcę o dokładną wersję, datę poprawki i potwierdzenie restartu procesów roboczych.

Windows / IIS

Pobierz poprawioną kompilację z windows.php.net, podmień katalog PHP i odśwież (recycle) pule aplikacji IIS.

3 Zrestartuj każdy proces PHP

Instalacja pakietu nie zmienia kodu, który już działa. Zrestartuj PHP-FPM, Apache (dla mod_php), LiteSpeed, FrankenPHP, procesy kolejek i supervisory. W przypadku kontenerów zbuduj lub pobierz nowy obraz — restart tego samego obrazu nie instaluje poprawki.

4 Zweryfikuj

Uruchom php -v dla każdego pliku binarnego i potwierdź, że działające procesy używają nowej kompilacji (na przykład ls -l /proc/$(pgrep -o php-fpm)/exe nie powinno pokazywać „deleted”). Następnie ponownie uruchom to narzędzie.

5 Jeśli nie możesz zaktualizować dzisiaj

Zastosuj poniższe częściowe środki zaradcze i ogranicz dostęp do strony, dopóki aktualizacja nie będzie możliwa. Zmniejszają one ryzyko, ale go nie eliminują.

6 Sprawdź oznaki włamania — i zmień sekrety

Jeśli podatna strona była dostępna z internetu, przejrzyj aktywność od 20 października 2026 r.: awarie procesów PHP (SIGSEGV) w logu błędów PHP-FPM lub Apache, nowe lub zmienione pliki PHP w katalogu głównym strony, nowe zadania cron, nowe konta administratorów oraz nieoczekiwane połączenia wychodzące.

Ponieważ CVE-2026-109619 może ujawnić pamięć procesu PHP bez uruchamiania jakiegokolwiek kodu, czysty system plików nie dowodzi, że nic nie wyciekło. Zmień hasła do baz danych, klucze API, dane dostępowe do płatności i poczty oraz unieważnij sesje użytkowników na narażonych stronach.

7 Po aktualizacji

Poprawka wprowadza nowy twardy limit pamięci: proces, który go osiągnie, jest natychmiast kończony, a procedury zamykania (shutdown handlers) nie są wykonywane. Sprawdź, jak aplikacja zachowuje się przy dużym obciążeniu pamięci, przejrzyj memory_limit razem z post_max_size i max_input_nesting_level oraz cofnij tymczasowe ustawienie memory_limit = -1, jeśli wprowadzono je przed łataniem. Ukrycie wersji za pomocą expose_php = Off to opcjonalne utwardzenie, a nie poprawka.

Częściowe środki zaradcze (wg php.net i komunikatów bezpieczeństwa)

Ograniczają one jedynie znane ścieżki ataku. php.net stwierdza, że aktualizacja to jedyny bezpieczny wybór.

; php.ini / FPM pool (php_admin_value) — następnie zrestartuj wszystkie procesy robocze
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M jeśli przesyłanie plików jest potrzebne
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Ustaw je w php.ini, w puli PHP-FPM (php_admin_value) lub w konfiguracji serwera — nie za pomocą ini_set() ani .user.ini — i zrestartuj procesy robocze. Dodatkowe środki z komunikatów i od zespołu badawczego:

memory_limit = -1 blokuje niektóre ścieżki opierające się na własnym limicie pamięci PHP, ale przekazuje wyczerpanie pamięci systemowi operacyjnemu — używaj go tylko razem z limitem cgroup v2 memory.max. Nie używaj RLIMIT_AS ani RLIMIT_DATA; mogą one uruchomić te same podatne ścieżki.
Obniż max_input_nesting_level na tyle, na ile pozwalają formularze.
Obniż pm.max_requests w PHP-FPM, aby procesy robocze były częściej odnawiane (kosztem wydajności).
Limity rozmiaru żądania, liczby pól i zagnieżdżenia na serwerze WWW lub proxy; usuń nieprawidłowe lub przestarzałe ustawienia INI dla poszczególnych żądań.
Polityki SELinux lub AppArmor mogą ograniczyć to, co może uruchomić przejęty proces roboczy — zmniejszają skutki, ale nie zapobiegają wyciekowi pamięci.

Źródła

Źródło: komunikat bezpieczeństwa php.net, 21 października 2026 r. Ostatnia weryfikacja: 2026-10-23.