RHEL, AlmaLinux i Rocky Linux: sprawdzanie poprawki PHP

Krótko: Na RHEL, AlmaLinux i Rocky Linux poprawkę PHP przeciw PHP2Shell sprawdzają Państwo trzema drogami: komunikatami bezpieczeństwa dystrybucji (dnf updateinfo), changelogiem pakietu (rpm -q --changelog) i czasem startu procesów PHP. Red Hat wymienia RHEL 7 do 10 jako dotknięte i podał przy pobraniu, że niektóre aktualizacje są dostępne, a kolejne w przygotowaniu. Po aktualizacji obowiązuje: zrestartować w pełni, a nie tylko przeładować.

Co Red Hat opublikował o PHP2Shell

Red Hat wydał w sprawie PHP2Shell biuletyn bezpieczeństwa RHSB-2026-013. Pobraliśmy go 25 października 2026. Najważniejsze punkty dla adminów:

• Dotknięte są RHEL 10, 9, 8 i 7 oraz produkty na nich oparte i kontenery na bazie obrazów RHEL lub UBI.
• RHEL 7 jest według Red Hat dotknięty tylko przez CVE-2026-109619; kod dla CVE-2026-109618 miałby tam nie występować.
• Niedotknięte są systemy bez PHP lub z PHP, które nie przetwarza niezaufanych żądań HTTP.
• Aktualizacje: Niektóre były dostępne przy pobraniu, kolejne w przygotowaniu. Konkretnych numerów errata biuletyn nie podawał, lecz odsyłał do stron errata.

Red Hat ocenia CVE-2026-109618 własną metodą jako „Important” i wskazuje, że standardowe instalacje od RHEL 8 używają PHP-FPM zamiast mod_php. Jest to klasyfikacja, a nie odwołanie alarmu. Projekt PHP ocenia obie luki na 9,2 w CVSS v4.0, a BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca natychmiastową aktualizację.

AlmaLinux i Rocky Linux: to samo źródło, własny rytm

AlmaLinux i Rocky Linux budują swoje pakiety od nowa ze źródeł Red Hat. Poprawki docierają więc z reguły treściowo takie same, ale we własnym terminie i pod własnymi komunikatami bezpieczeństwa. Wskazówka o errata Red Hat nie oznacza, że pakiet u Państwa klonu jest dostępny tego samego dnia.

Decydujący jest więc stan na Państwa systemie. Proszę sprawdzić go narzędziami zarządzania pakietami, a nie na podstawie wiadomości czy for.

Proszę zwrócić też uwagę, czy na serwerze używane są serwery-lustra lub wewnętrzne źródła pakietów. W wielu firmach serwery pobierają aktualizacje nie bezpośrednio od producenta, lecz przez wewnętrzne lustro lub narzędzie do zarządzania. Jeśli to lustro nie jest aktualne, dnf nie znajduje nowych pakietów, choć dawno zostały opublikowane.

Sprawdzanie poprawki PHP na RHEL i klonach

Poniższe polecenia są wyłącznie odczytowe. Nazwy pakietów dotyczą pakietów PHP dystrybucji; pakiety ze źródeł zewnętrznych, takich jak Remi, nazywają się częściowo inaczej.

# Jakie strumienie PHP zna system, który jest aktywny? (RHEL 8 i 9)
dnf module list php

# Zainstalowane pakiety PHP z wersją i pochodzeniem
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE}  %{VENDOR}\n' | sort

# Czy są komunikaty bezpieczeństwa do tych CVE dla tego systemu?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619

# Czy poprawka widnieje w changelogu zainstalowanego pakietu?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"

dnf updateinfo pokazuje tylko komunikaty o aktualizacjach, które nie są jeszcze zainstalowane; przez --installed widać także już zainstalowane. Pusty wynik może więc oznaczać dwie rzeczy: aktualizacja jest już zainstalowana albo jeszcze nie została opublikowana. Porównanie z changelogiem to wyjaśnia. Jak zapisać wynik jako dowód, opisuje artykuł Dowód numerów CVE w changelogu pakietu.

Jak w innych dystrybucjach korporacyjnych pakiet zachowuje zwykle pierwotną wersję PHP; zmienia się tylko oznaczenie wydania. Starszy numer w php -v nie jest więc wskazówką na brak poprawki. Ogólne wskazówki dotyczące sprawdzania wersji podano pod hasłem Prawidłowe sprawdzanie wersji PHP i stanu poprawek.

Rozpoznanie właściwego trybu pracy

Red Hat wymienia standardowe tryby pracy: od RHEL 8 PHP działa przez PHP-FPM, na RHEL 7 jako mod_php w usłudze Apache httpd. Wiele serwerów odbiega od tego, na przykład przez panele, źródła zewnętrzne lub stare konfiguracje.

Dla kontenerów Red Hat zaleca po zaktualizowanych obrazach bazowych przebudować własne obrazy i wymienić działające kontenery lub pody. Aktualizacja w działającym kontenerze nie jest wiarygodną drogą.

Po aktualizacji: restart i kontrola

Red Hat podkreśla, że przeładowanie nie wystarcza. Istniejące workery mogą zachować dotknięty stan. Proszę więc zrestartować każdą usługę, która ładuje PHP, i skontrolować wynik:

# Pokaż usługi ze starymi bibliotekami (dnf-utils lub dnf-plugins-core)
needs-restarting -s

# Porównaj czas startu procesów PHP z czasem aktualizacji
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"

Do konfiguracji Red Hat ma praktyczną wskazówkę: php -i pokazuje ustawienia wiersza poleceń, a nie serwera WWW. Kto chce sprawdzić, czy wartości przejściowe, takie jak session.upload_progress.enabled=0, działają w kontekście webowym, korzysta krótko z zabezpieczonej strony phpinfo i potem ją usuwa. O czym jeszcze trzeba pamiętać przy restarcie, opisuje strona Restart PHP-FPM i wszystkich workerów.

Środki przejściowe: wskazówki Red Hat

Tam, gdzie aktualizacji jeszcze brakuje, Red Hat odsyła do tych samych środków przejściowych co php.net i dodaje kilka praktycznych wskazówek dla systemów RHEL. Nie zastępują aktualizacji.

• Wiersz naprawdę dodać: Według Red Hat wiersz dla session.upload_progress.enabled jest w dostarczonej konfiguracji zakomentowany, funkcja jest więc domyślnie aktywna. Wartość 0 trzeba ustawić wyraźnie.
• Ustawiać w sposób niemożliwy do nadpisania: przez php_admin_value w puli PHP-FPM, przy mod_php w konfiguracji Apache. Nie przez ini_set() ani .user.ini.
• Szukać przeciwników: Red Hat zaleca sprawdzić pliki .htaccess, VirtualHosty i pliki .user.ini pod kątem tego, czy ponownie nie włączają dotkniętych ustawień.
• Limity ustawiać także wcześniej: Obok post_max_size w PHP Red Hat radzi rozważyć limity wielkości żądania także w serwerze WWW lub proxy.

Na systemach z PHP-FPM pule znajdują się zwykle pod /etc/php-fpm.d/. Po każdej zmianie obowiązuje to samo co po aktualizacji: zrestartować w pełni wszystkie workery.

Jak konkretnie pomaga PHP SOS?

• Sprawdzamy na RHEL, AlmaLinux i Rocky Linux wszystkie pakiety PHP, strumienie i źródła zewnętrzne oraz porównujemy je z komunikatami bezpieczeństwa.
• Instalujemy aktualizacje, restartujemy w pełni wszystkie workery i kontrolujemy czasy startu procesów.
• Dla środowisk kontenerowych przebudowujemy obrazy i kontrolowanie wymieniamy działające instancje.
• Stan każdego serwera zapisujemy w dowodzie usługi łatania PHP.

Częste pytania

Źródła

• Red Hat Security Bulletin RHSB-2026-013
• Red Hat: CVE-2026-109618
• php.net: komunikaty o bezpieczeństwie