php2shell (CVE-2026-109618 / 109619) nie da się ocenić przez php -v: gdzie numery wersji rozjeżdżają się w FPM, Dockerze i dystrybucjach

Jeśli PHP obsługujące żądania WWW (PHP-FPM, mod_php w Apache, php-cgi, FrankenPHP, LiteSpeed) jest starsze niż 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, dotyczą go luki CVE-2026-109618 i CVE-2026-109619, znane jako php2shell. Rozwiązaniem jest aktualizacja do jednej z tych wersji (a w przypadku pakietów dystrybucji — do poprawionego pakietu) i restart procesów. Sprawdzać należy nie lokalne php -v, lecz „PHP faktycznie obsługujące WWW” oraz „wersję zainstalowanego pakietu”.

Artykuł skupia się na czterech miejscach, w których ocena wyłącznie po numerze wersji prowadzi do błędnych wniosków. Wszystkie liczby i informacje o stanie są podane według stanu na 2026-10-22, a źródła poszczególnych elementów wymieniono na końcu.

Co wiadomo (stan na 2026-10-22)

W komunikacie PHP stwierdzono, że „jedyną kompletną poprawką jest aktualizacja”. Środki łagodzące na czas do aktualizacji opisano w dalszej części artykułu.

Pułapka 1: php -v i PHP obsługujące WWW mogą być różne

php -v wpisane przez SSH pokazuje wersję PHP w CLI. Żądania WWW obsługują procesy PHP-FPM albo mod_php załadowany do Apache, czyli osobne pliki binarne i osobne pakiety. Jeśli nowsze PHP zainstalowano tylko dla CLI, równolegle działa kilka wersji albo pula FPM wskazuje inną wersję, strona WWW może pozostać stara, nawet gdy php -v pokazuje wersję poprawioną.

Jest kilka sposobów, by zobaczyć rzeczywistą wersję po stronie WWW.

# FPM w Debianie / Ubuntu (nazwa zależy od wersji)
php-fpm8.3 -v

# FPM w systemach z rodziny RHEL
php-fpm -v

# Sprawdzenie, czy mod_php jest załadowany w Apache
apachectl -M | grep -i php

Najpewniejsza metoda to polecenie, by PHP faktycznie uruchamiane przez WWW samo podało swoją wersję. Umieść tymczasowo plik o trudnej do odgadnięcia nazwie i usuń go zaraz po sprawdzeniu.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Jeśli PHP_SAPI to fpm-fcgi, PHP działa pod FPM; apache2handler oznacza mod_php; cgi-fcgi oznacza CGI. Nie zostawiaj wystawionego phpinfo(), ponieważ samo w sobie ujawnia ono informacje.

Restart to kolejny krok, który łatwo pominąć. Nawet po wymianie pakietu już działające procesy php-fpm lub Apache mogą nadal wykonywać stary kod. Niektóre konfiguracje restartują się automatycznie po aktualizacji pakietów, inne nie. Po aktualizacji zrestartuj FPM / Apache i ponownie sprawdź wersję po stronie WWW powyższymi metodami.

Pułapka 2: w Dockerze nie oceniaj po nazwie tagu

Oficjalny obraz php ma „ruchome tagi”, takie jak 8.3 i 8.3-fpm, których zawartość jest podmieniana, oraz tagi przypięte, takie jak 8.3.30, które utrzymują stałą wersję.

• Nawet gdy ruchomy tag na Docker Hub wskazuje już wersję poprawioną, Twoja lokalna kopia pozostaje starym obrazem, dopóki nie wykonasz ponownie pull. Działające kontenery również używają starego obrazu, dopóki nie zostaną odtworzone. Dockerfile z FROM php:8.3-fpm nadal zbuduje się na starej bazie, jeśli ta pozostaje w pamięci podręcznej budowania.
• Tag przypięty pozostaje stary na zawsze, dopóki sam nie zmienisz numeru.

Czy opublikowano tagi z wersjami poprawionymi, możesz sprawdzić przez API Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Oto wyniki zapytań dla czterech linii wydań z 2026-10-22 (czasy w UTC).

Podczas sprawdzania wyszły trzy miejsca, w których ocena po samych numerach może wprowadzić w błąd.

1. „Ostatnio zaktualizowany” nie znaczy „naprawiony”. Przypięty tag 8.3.35 został przebudowany 2026-10-21, ale PHP_VERSION w środku nadal wynosiło 8.3.35. Patrz na wersję wewnątrz obrazu, a nie na datę aktualizacji.
2. Różne digesty mogą oznaczać tę samą zawartość. Tagi 8.3 i 8.3.36 miały różne digesty (wartość indeksu obejmującego wiele architektur), ale obraz amd64 był identyczny i w obu PHP_VERSION=8.3.36. Tak samo w przypadku 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm i 8.2-fpm: PHP_VERSION obrazu amd64 była wersją poprawioną.
3. Dla wersji 8.1 i starszych nie ma poprawionych oficjalnych obrazów. 8.1-fpm był ostatnio aktualizowany 2025-12-31.

Aby sprawdzić lokalne obrazy i działające kontenery:

# Wersja PHP w obrazie pobranym lokalnie
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Pobierz ponownie i odtwórz kontenery
docker compose pull
docker compose up -d

# Jeśli budujesz własny obraz, pobierz ponownie obraz bazowy i dopiero zbuduj
docker compose build --pull

# Wersja wewnątrz działającego kontenera
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

W ostatnim poleceniu zamień app na nazwę własnej usługi. Każdy oficjalny obraz jest budowany z jedną wartością PHP_VERSION, więc wersja CLI w kontenerze odpowiada wersji FPM / Apache w tym kontenerze (Pułapka 1 dotyczy PHP zainstalowanego bezpośrednio na hoście).

FrankenPHP osadza PHP, więc wersja FrankenPHP i wersja wbudowanego PHP to różne numery. W informacjach o wydaniu FrankenPHP 1.13.2, opublikowanego 2026-10-21, podano, że obrazy Docker zbudowano z PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, a statyczne pliki binarne z PHP 8.5.12.

Pułapka 3: pakiety dystrybucji są „naprawione pod starym numerem”

Ubuntu i RHEL przenoszą do starszych wersji tylko poprawki (backporting). Numer wyświetlany przez php -v pozostaje stary, więc ocena liczbowa w stylu „niższa niż 8.3.36, więc podatna” oznaczy jako podatny system, który jest już naprawiony. I odwrotnie, na numerze nie można też opierać poczucia bezpieczeństwa. Decyduj na podstawie wersji pakietu i trackera bezpieczeństwa danej dystrybucji.

Poprawione pakiety wymienione w poszczególnych trackerach (stan na 2026-10-22; takie same dla obu CVE):

Ta tabela pokazuje wprost, dlaczego same numery nie wystarczają. Poprawiony PHP w Ubuntu 24.04 to wersja zaczynająca się od 8.3.6, dużo niższa niż 8.3.36 z upstreamu. Domyślny PHP w RHEL 9 jest naprawiony, choć pozostaje na 8.0.30, mimo że upstream nie wydaje już poprawek dla 8.0. Debian przeszedł na te same numery co upstream (8.2.35 / 8.4.27).

Niektóre pakiety nie są jeszcze naprawione (stan na 2026-10-22).

• Moduł php 8.4 w RHEL 9 jest oznaczony jako „affected, no fix” (podatny, bez poprawki).
• Debian forky (testing) ma php8.4 8.4.26-1, oznaczony jako „vulnerable”. Pakiet php8.4 w sid (unstable) ma wersję 8.4.27-1 i jest naprawiony.

Przykładowe polecenia do sprawdzenia własnego serwera:

# Debian / Ubuntu: zainstalowana i dostępna wersja
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: czy to CVE jest naprawione na tym serwerze
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Rodzina RHEL: czy istnieje aktualizacja naprawiająca to CVE oraz zainstalowana wersja
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Dostosuj nazwę pakietu (php8.3-fpm itd.) do swojego środowiska. Porównaj wyświetloną wersję z „wersją poprawioną” w tabeli powyżej lub w trackerze; jeśli jest taka sama lub wyższa, poprawka jest wdrożona. Następnie wykonaj restart i sprawdzenie po stronie web opisane w Pułapce 1.

Jeśli instalujesz PHP z zewnętrznego repozytorium, a nie z pakietów dystrybucji, musisz śledzić aktualizacje tego repozytorium. Komunikat PHP zauważa, że prowadzone przez wolontariuszy rpms.remirepo.net nie będzie miało aktualizacji w dniu ujawnienia, i zaleca przejście na pakiety dystrybucji lub własne kompilacje.

Pułapka 4: na hostingu współdzielonym i w środowiskach zarządzanych nie możesz sam zaktualizować PHP

W hostingu współdzielonym i zarządzanych środowiskach PHP środowisko uruchomieniowe PHP wymienia dostawca. Tutaj też sam numer wersji nie wystarcza: jeśli dostawca buduje PHP samodzielnie lub przenosi poprawki (backport), numer wersji może pozostać stary.

Są trzy rzeczy, które możesz zrobić samodzielnie.

1. Sprawdź wersję po stronie WWW. Użyj tymczasowego pliku z pułapki 1, aby wypisać PHP_VERSION i PHP_SAPI, a następnie od razu go usuń. Jeśli panel zarządzania ma wybór wersji PHP, zanotuj też, którą wersję wybrano.
2. Przeczytaj komunikat dostawcy, a jeśli go nie ma, zapytaj. Zapytaj: „Dla jakich wersji PHP w moim planie zostaną wdrożone (lub zostały wdrożone) poprawki CVE-2026-109618 i CVE-2026-109619 i kiedy?”. Pytanie o numer CVE, a nie o numer wersji, daje odpowiedź obejmującą także backporty.
3. Jeśli wybrano wersję bez wsparcia, zaktualizuj ją. Projekt PHP nie wydaje poprawek dla wersji 8.1 i starszych, a wsparcie dla 8.2 kończy się 2026-12-31. Jeśli dostawca nie przeniósł poprawek, pewną drogą jest zmiana wersji.

Stan u dostawców hostingu (stan na 2026-10-22)

W hostingu współdzielonym środowisko PHP zwykle aktualizuje dostawca, a w wielu komunikatach można przeczytać, że „użytkownik nie musi nic robić”. Użytkownik ma dwie rzeczy do zrobienia: sprawdzić oficjalny komunikat swojego dostawcy oraz, jeśli w panelu wybrał starą wersję PHP, zdecydować, czy przełączyć się na wersję zalecaną w komunikacie (taką, która ma wydaną poprawkę).

Poniższa tabela zawiera wyłącznie to, co jest napisane na oficjalnych stronach dostawców (ogłoszenia i informacje o pracach serwisowych), w parafrazie treści komunikatów. Komunikaty są aktualizowane w miarę postępu prac, dlatego rzeczywisty stan zawsze potwierdzaj na wskazanej stronie oficjalnej.

Tam, gdzie nie udało mi się znaleźć lub otworzyć oficjalnego komunikatu, w tabeli jest napisane „nie udało się potwierdzić” lub „nie znalazłem”. Brak informacji nie oznacza, że dostawca nie zareagował. Sprawdź to bezpośrednio w ogłoszeniach dostawcy i u jego pomocy technicznej.

Środki łagodzące, gdy nie można od razu zaktualizować

Komunikat PHP wymienia ustawienia zmniejszające powierzchnię ataku do czasu aktualizacji. Sam komunikat wyraźnie jednak stwierdza, że „nie zapewniają one bezpieczeństwa”. Najważniejsze z nich:

• Dla CVE-2026-109619: ustaw session.upload_progress.enabled=0 w php.ini, w puli FPM lub w konfiguracji serwera i zrestartuj wszystkie procesy robocze (ini_set() i .user.ini w FPM tu nie działają). W PHP 8.5 ustaw też fatal_error_backtraces=0.
• Dla CVE-2026-109618: ustaw memory_limit=-1 w sposób, którego aplikacja nie może nadpisać, i zmniejsz post_max_size (8M, jeśli nie ma przesyłania plików, 32M, jeśli jest). Nie używaj RLIMIT_AS / RLIMIT_DATA jako zamiennika.

Brytyjskie NCSC zaleca rozważenie wyłączenia z sieci każdego systemu, którego nie da się od razu zaktualizować ani zabezpieczyć, oraz sprawdzenie śladów włamania przed aktualizacją lub zastosowaniem środków łagodzących.

Źródła (sprawdzone 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: komunikaty o wydaniu PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: oficjalny obraz php
• Informacje o wydaniu FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (wersje poprawionych pakietów pochodzą z danych VEX Red Hata)
• NCSC: Critical security issue affecting PHP