# RHEL, AlmaLinux i Rocky Linux: sprawdzanie poprawki PHP

> Poprawka PHP na RHEL, AlmaLinux i Rocky: co Red Hat podaje o PHP2Shell, jak odpytać errata, changelog i moduły oraz jak prawidłowo zrestartować usługi.

Źródło: https://phpsos.de/pl/blog/rhel-almalinux-rocky-php/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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.

```bash
# 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](https://phpsos.de/pl/blog/cve-im-changelog-nachweisen/).

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](https://phpsos.de/pl/php2shell/php-version-pruefen/).

## 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.

| System | Standard według Red Hat | Restart po aktualizacji |
|---|---|---|
| RHEL 8, 9, 10 i klony | PHP-FPM | `systemctl restart php-fpm` |
| RHEL 7 | mod_php w httpd | `systemctl restart httpd` |
| Kontenery na bazie RHEL lub UBI | zależnie od obrazu | Przebudować obraz, wymienić kontener |

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:

```bash
# 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](https://phpsos.de/pl/php2shell/php-fpm-neustart/).

## Ś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.

> **Wskazówka:**
> Jeśli na tym samym serwerze działa dodatkowo PHP z repozytorium Remi, obowiązują dla niego własne pakiety i usługi. Proszę przeczytać artykuł [Repozytorium Remi](https://phpsos.de/pl/blog/remi-repository-php/).

## 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](https://phpsos.de/pl/leistungen/php-patch-service/).


## Częste pytania

**Czy RHEL 7 jest dotknięty przez PHP2Shell?**  
Według Red Hat RHEL 7 jest dotknięty tylko przez CVE-2026-109619, podatny kod dla CVE-2026-109618 nie jest tam obecny. Na RHEL 7 mod_php jest standardowym trybem pracy, który zespół PHP ocenia jako szczególnie ryzykowny.

**Dlaczego Red Hat ocenia lukę niżej niż php.net?**  
Red Hat stosuje własną ocenę według CVSS v3.1 i klasyfikuje CVE-2026-109618 jako Important, ponieważ wykorzystanie wymaga dokładnego timingu. php.net ocenia w CVSS v4.0 na 9,2. Obie strony uznają wykonanie kodu bez logowania za możliwe, aktualizacja jest w każdym przypadku konieczna.

**Czy AlmaLinux i Rocky Linux otrzymują poprawki automatycznie?**  
Oba budują swoje pakiety od nowa ze źródeł Red Hat i publikują własne komunikaty bezpieczeństwa. Termin może odbiegać od Red Hat. Dlatego proszę sprawdzić stan na własnym systemie i w komunikatach Państwa dystrybucji.

**Czy po aktualizacji wystarczy systemctl reload php-fpm?**  
Nie. Red Hat wyraźnie wskazuje, że przeładowanie nie wystarcza, ponieważ istniejące workery mogą zachować dotknięty stan. Proszę zrestartować wszystkie workery, a przy mod_php usługę Apache httpd.

## Źródła

- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)