Накратко: На RHEL, AlmaLinux и Rocky Linux проверявате PHP пача срещу PHP2Shell по три пътя: съобщенията за сигурност на дистрибуцията (dnf updateinfo), changelog-а на пакета (rpm -q --changelog) и времето на стартиране на PHP процесите. Red Hat води RHEL 7 до 10 като засегнати и при извличането съобщи, че някои актуализации са налични, а други са в работа. След актуализацията важи: рестартирайте напълно, не само презареждайте.
Какво публикува Red Hat за PHP2Shell
Red Hat издаде за PHP2Shell бюлетина за сигурност RHSB-2026-013. Извлякохме го на 25 октомври 2026 г. Най-важните точки за админите:
- Засегнати са RHEL 10, 9, 8 и 7, както и продукти и контейнери върху тях на базата на образи RHEL или UBI.
- RHEL 7 според Red Hat е засегнат само от CVE-2026-109619; кодът за CVE-2026-109618 там не бил съдържан.
- Не са засегнати системи без PHP или без PHP, който обработва ненадеждни HTTP заявки.
- Актуализации: Някои бяха налични при извличането, други в работа. Конкретни номера на errata бюлетинът не посочи, а препрати към страниците с errata.
Red Hat оценява CVE-2026-109618 със собствен метод като „Important“ и сочи, че стандартните инсталации от RHEL 8 нагоре ползват PHP-FPM вместо mod_php. Това е оценка, не успокоение. PHP проектът оценява и двете уязвимости с CVSS v4.0 9,2, а BSI (Федералната служба за информационна сигурност на Германия) препоръчва незабавна актуализация.
AlmaLinux и Rocky Linux: един източник, собствен ритъм
AlmaLinux и Rocky Linux изграждат пакетите си наново от изходния код на Red Hat. Поправките затова по правило пристигат със същото съдържание, но със собствен момент и под собствени съобщения за сигурност. Указание за errata на Red Hat не означава, че пакетът при Вашия клон е наличен същия ден.
Решаващо е затова състоянието на Вашата система. Проверете го с инструментите на управлението на пакетите, а не по новини или форуми.
Внимавайте още дали на сървъра се ползват огледални сървъри или вътрешни източници на пакети. В много фирми сървърите вземат актуализациите си не директно от производителя, а през вътрешно огледало или инструмент за управление. Ако това огледало не е актуално, dnf не намира нови пакети, въпреки че отдавна са публикувани.
Проверка на PHP пача на RHEL и клоновете му
Следните команди са само за четене. Имената на пакетите важат за PHP пакетите на дистрибуцията; пакети от външни източници като Remi понякога се казват другояче.
# Кои PHP stream-ове познава системата, кой е активен? (RHEL 8 и 9)
dnf module list php
# Инсталирани PHP пакети с версия и произход
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Има ли съобщения за сигурност за CVE за тази система?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Поправката в changelog-а на инсталирания пакет ли е?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo показва само съобщения за актуализации, които още не са инсталирани; с --installed виждате и вече инсталираните. Празен резултат може следователно да значи две неща: актуализацията вече е вътре или още не е публикувана. Сравнението с changelog-а изяснява това. Как да запишете резултата като доказателство, описва статията Доказване на номера CVE в changelog-а на пакета.
Както при други корпоративни дистрибуции, пакетът обикновено запазва първоначалната си PHP версия; променя се само обозначението на release-а. По-стар номер при php -v затова не е указание за липсваща поправка. Общи указания за проверка на версията има в Проверка на PHP версията и състоянието на пача.
Разпознаване на правилния режим на работа
Red Hat назовава стандартните режими на работа: от RHEL 8 нагоре PHP работи през PHP-FPM, на RHEL 7 като mod_php в услугата на Apache httpd. Много сървъри се отклоняват от това, например заради панели, външни източници или стари конфигурации.
| Система | Стандарт според Red Hat | Рестарт след актуализацията |
|---|---|---|
| RHEL 8, 9, 10 и клонове | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php в httpd | systemctl restart httpd |
| Контейнери на базата на RHEL или UBI | според образа | изградете образа наново, заменете контейнера |
За контейнери Red Hat препоръчва след актуализирани базови образи да се изградят наново собствените образи и работещите контейнери или pod-ове да се заменят. Актуализация в работещ контейнер не е надежден път.
След актуализацията: рестарт и контрол
Red Hat подчертава, че презареждането не стига. Съществуващите worker-и могат да запазят засегнатото състояние. Затова рестартирайте всяка услуга, която зарежда PHP, и контролирайте резултата:
# Показване на услуги със стари библиотеки (dnf-utils съответно dnf-plugins-core)
needs-restarting -s
# Сравнение на времето на стартиране на PHP процесите с момента на актуализацията
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
За конфигурацията Red Hat има практично указание: php -i показва настройките на командния ред, не тези на уеб сървъра. Който иска да провери дали временни стойности като session.upload_progress.enabled=0 действат в уеб контекста, ползва за кратко защитена страница с phpinfo и я изтрива след това. Какво още да се има предвид при рестарта, пише в Рестартиране на PHP-FPM и на всички worker-и.
Временни мерки: указанията на Red Hat
Където актуализацията още липсва, Red Hat препраща към същите временни мерки като php.net и добавя няколко практични указания за RHEL системи. Те не заместват актуализацията.
- Редът наистина да се допълни: Според Red Hat редът за
session.upload_progress.enabledв доставената конфигурация е в коментар, тоест функцията е активна по подразбиране. Стойността0трябва да се зададе изрично. - Задаване без възможност за презаписване: чрез
php_admin_valueв пула на PHP-FPM, при mod_php в конфигурацията на Apache. Не чрезini_set()или.user.ini. - Търсене на противодействащите: Red Hat препоръчва файловете
.htaccess, VirtualHost-овете и файловете.user.iniда се проверят дали отново не включват засегнатите настройки. - Ограничения и преди това: Освен
post_max_sizeв PHP Red Hat съветва да се обмислят ограничения за размера на заявката и в уеб сървъра или прокситото.
На системи с PHP-FPM пуловете по правило са под /etc/php-fpm.d/. След всяка промяна важи същото като след актуализацията: рестартирайте напълно всички worker-и.
Ако на същия сървър допълнително работи PHP от хранилището Remi, за него важат собствени пакети и услуги. Прочетете за това статията Хранилището Remi.
Как помага PHP SOS конкретно?
- Проверяваме на RHEL, AlmaLinux и Rocky Linux всички PHP пакети, stream-ове и външни източници и ги съпоставяме със съобщенията за сигурност.
- Инсталираме актуализации, рестартираме напълно всички worker-и и контролираме времената на стартиране на процесите.
- За контейнерни среди изграждаме образите наново и заменяме контролирано работещите инстанции.
- Състоянието за всеки сървър записваме в доказателството на услугата за пач на PHP.
Често задавани въпроси
Засегнат ли е RHEL 7 от PHP2Shell?
Според Red Hat RHEL 7 е засегнат само от CVE-2026-109619, уязвимият код за CVE-2026-109618 там не бил наличен. На RHEL 7 mod_php е режимът на работа по подразбиране, който PHP екипът оценява като особено рисков.
Защо Red Hat оценява уязвимостта по-ниско от php.net?
Red Hat ползва собствена оценка по CVSS v3.1 и определя CVE-2026-109618 като Important, защото експлоатацията изисквала точна синхронизация във времето. php.net оценява по CVSS v4.0 с 9,2. И двете приемат, че изпълнение на код без вход е възможно, актуализацията във всеки случай е необходима.
Получават ли AlmaLinux и Rocky Linux поправките автоматично?
И двете изграждат пакетите си наново от изходния код на Red Hat и публикуват собствени съобщения за сигурност. Моментът може да се различава от този на Red Hat. Затова проверете състоянието на собствената си система и в съобщенията на Вашата дистрибуция.
Стига ли systemctl reload php-fpm след актуализацията?
Не. Red Hat изрично посочва, че презареждането не стига, защото съществуващите worker-и могат да запазят засегнатото състояние. Рестартирайте всички worker-и, при mod_php - услугата на Apache httpd.