Krótko: Repozytorium PHP Remi dostarcza aktualne wersje PHP dla Fedory i rodziny RHEL, albo jako strumień modułu, który zastępuje systemowe PHP, albo jako Software Collection, która instaluje kilka wersji równolegle. Poprawki PHP2Shell 8.2.35, 8.3.36, 8.4.27 i 8.5.12 ogłoszono tam 22 października 2026. Proszę sprawdzić każdą zainstalowaną wersję osobno i zrestartować każdą należącą do niej usługę.
Dlaczego tak wiele serwerów RHEL pobiera PHP od Remi
Dystrybucje korporacyjne, takie jak RHEL, AlmaLinux i Rocky Linux, stawiają na długą stabilność. Dostarczają niewiele gałęzi PHP i utrzymują je przez lata. Wiele aplikacji wymaga jednak nowszych wersji, niż oferuje dystrybucja. Tu wkracza repozytorium Remi Colleta, wieloletniego opiekuna pakietów PHP w środowisku Fedory i RHEL.
Remi buduje wersje PHP w krótkim odstępie po oficjalnych wydaniach. W sprawie PHP2Shell na blogu repozytorium ukazał się 22 października 2026 wpis o wersjach 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Wymieniono w nim obie krytyczne luki CVE-2026-109618 i CVE-2026-109619 oraz pilnie zalecono aktualizację. Komunikaty bezpieczeństwa Red Hat nie dotyczą tych pakietów; to, co Red Hat podaje dla własnych pakietów, opisuje artykuł RHEL, AlmaLinux i Rocky Linux: sprawdzanie poprawki PHP.
Dwie drogi: strumień modułu lub Software Collection
Według bloga Remi kompilacje dla Enterprise Linux od wersji 8 są dostępne dwiema drogami. To, którą używa Państwa serwer, określa sposób sprawdzania i restartu.
| Droga | Repozytorium | Skutek | Typowa usługa |
|---|---|---|---|
Strumień modułu, na przykład php:remi-8.3 |
remi-modular | zastępuje systemowe PHP, jedna wersja standardowa | php-fpm |
Software Collection, na przykład php83 |
remi-safe | dodatkowa wersja równolegle we własnej ścieżce | własna usługa dla każdej wersji, na przykład php83-php-fpm |
| Pakiety testowe i kandydaci do wydania | remi-modular-test, remi-test | wersje wstępne | nie do produkcji |
Software Collections znajdują się typowo pod /opt/remi/phpXY, ich konfiguracja pod /etc/opt/remi/phpXY. Jest to praktyczne, aby prowadzić stare i nowe aplikacje na jednym serwerze. Jest to jednak także najczęstszy powód, dla którego jakaś wersja zostaje pominięta przy aktualizacji.
Wskazówka dotycząca wiersza poleceń: Software Collections nie są automatycznie dostępne pod poleceniem php. W zależności od konfiguracji zadania cron i skrypty wywołują je przez własne polecenie lub pełną ścieżkę. Proszę więc sprawdzić także crontaby i skrypty wdrożeniowe, jeśli chcą Państwo wiedzieć, która kolekcja jest do czego używana.
Sprawdzanie repozytorium PHP Remi po PHP2Shell
Poniższe polecenia są wyłącznie odczytowe i pokazują, jakie pakiety Remi są zainstalowane i jaki mają stan.
# Aktywne źródła pakietów: czy remi-modular lub remi-safe jest dołączone?
dnf repolist
# Aktywny strumień modułu dla PHP
dnf module list --enabled php
# Pakiety bazowe i równolegle zainstalowane Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Wersja każdej zainstalowanej kolekcji
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Przy wspieranych gałęziach sytuacja jest jednoznaczna: jeśli widnieje tam 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo nowsza, poprawka jest zawarta. U Remi numer wersji odpowiada z reguły wersji upstream, inaczej niż w pakietach dystrybucji, które często zachowują stary numer.
Dla starszych kolekcji, takich jak php81, php80 lub php74, nie ma oficjalnej wersji docelowej. Remi prowadzi PHP 8.1 jako End-of-Life. To, czy zainstalowany pakiet zawiera poprawkę przeciw PHP2Shell, wyjaśniają Państwo w changelogu, na przykład przez rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Bez trafienia pakiet traktują Państwo jako niewyjaśniony. Jak czysto udokumentować takie trafienia, opisuje artykuł Dowód numerów CVE w changelogu pakietu.
Proszę nie aktywować na stałe repozytoriów testowych, takich jak remi-test czy remi-modular-test, na serwerach produkcyjnych. Dostarczają kandydatów do wydania, przeznaczonych do testów.
Aktualizacja i restart każdej wersji
Sama aktualizacja jest u Remi zwykle niewidowiskowa: dnf upgrade pobiera nowe pakiety dla strumienia i kolekcji. Krytyczna część następuje potem. Każda kolekcja ma własną usługę FPM i każdą trzeba zrestartować.
# Wypisz wszystkie usługi PHP-FPM, także kolekcji
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Sprawdź czasy startu wszystkich procesów PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Czasy startu sprzed aktualizacji oznaczają: ta usługa nadal pracuje ze starym kodem. Dlaczego przeładowanie nie wystarcza, wyjaśnia strona Restart PHP-FPM i wszystkich workerów.
Remi i dystrybucja: kto jest odpowiedzialny?
Kto przez strumień modułu przechodzi na Remi, zmienia dla PHP dostawcę. Komunikaty bezpieczeństwa Red Hat, AlmaLinux lub Rocky Linux nie odnoszą się wtedy już do zainstalowanych pakietów PHP. Odwrotnie, Remi nie zgłasza problemów w innych pakietach systemu. Obie źródła muszą Państwo więc mieć na oku.
To, skąd pochodzi zainstalowany pakiet, pokazuje baza pakietów, na przykład przez rpm -qi php-fpm w polach dla producenta i pakietującego. Ponieważ dla pakietów Remi nie ma errata w rozumieniu Red Hat, jako drogę powiadamiania nadaje się blog repozytorium; można go subskrybować przez kanał RSS. W przypadku PHP2Shell wskazówka ukazała się tam dzień po oficjalnych wydaniach.
Dla firm taki podział nie jest przeszkodą, ale musi być udokumentowany. Proszę zapisać, które serwery pobierają PHP od Remi, kto czyta komunikaty i kto po aktualizacji restartuje usługi. W przeciwnym razie każdy polega na drugim.
Utrzymać porządek: mniej wersji, mniej ryzyka
Software Collections zachęcają do tego, by po prostu zostawiać stare wersje. Po PHP2Shell to dobry moment na porządki:
- Dla każdej kolekcji wyjaśnić, która strona lub które zadanie cron z niej korzysta.
- Nieużywane kolekcje wyłączyć i po okresie obserwacji usunąć.
- Aplikacje na starych kolekcjach podnieść do wspieranej gałęzi.
- Pozostałe wersje udokumentować z celem i osobą odpowiedzialną.
Jak zachować przegląd nad wieloma równoległymi wersjami, opisuje artykuł Kilka wersji PHP na jednym serwerze.
Jak konkretnie pomaga PHP SOS?
- Rejestrujemy wszystkie strumienie i kolekcje Remi na Państwa serwerach i przyporządkowujemy je stronom i zadaniom cron.
- Sprawdzamy stan PHP2Shell dla każdej wersji przez wersję pakietu i changelog.
- Instalujemy aktualizacje, restartujemy każdą usługę i dokumentujemy to czasami startu procesów w ramach usługi łatania PHP.
- Niepotrzebne już kolekcje usuwamy po uzgodnieniu w sposób kontrolowany.
Częste pytania
Czy Remi udostępnił wersje z poprawkami PHP2Shell?
Tak. Na blogu repozytorium ogłoszono 22 października 2026 wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12, ze wskazówką o dwóch krytycznych lukach, CVE-2026-109618 i CVE-2026-109619, oraz pilnym zaleceniem aktualizacji.
Jaka jest różnica między strumieniem modułu a SCL u Remi?
Przez strumień modułu zastępują Państwo systemowe PHP wersją Remi, jest wtedy jedna wersja PHP jako domyślna. Software Collections instalują dalsze wersje równolegle we własnych ścieżkach, każda z własną usługą.
Czy PHP 8.1 od Remi nadal otrzymuje aktualizacje?
Remi prowadzi PHP 8.1 jako End-of-Life, projekt PHP nie utrzymuje już tej gałęzi. Czy konkretny pakiet 8.1 zawiera poprawkę przeciw PHP2Shell, sprawdzają Państwo w changelogu zainstalowanego pakietu. Bez wpisu stan uchodzi za niewyjaśniony.
Czy po aktualizacji z Remi muszę zrestartować każdą wersję PHP?
Tak. Każda zainstalowana równolegle wersja ma własną usługę FPM. Jeśli zrestartowana zostanie tylko usługa wersji głównej, pozostałe działają dalej ze starym kodem.