# RHEL, AlmaLinux и Rocky Linux: проверка на PHP пача

> Проверка на PHP пача на RHEL, AlmaLinux и Rocky: какво съобщава Red Hat за PHP2Shell, как да проверите errata и changelog и как да рестартирате правилно.

Източник: https://phpsos.de/bg/blog/rhel-almalinux-rocky-php/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** На 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 понякога се казват другояче.

```bash
# Кои 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-а на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/).

Както при други корпоративни дистрибуции, пакетът обикновено запазва първоначалната си PHP версия; променя се само обозначението на release-а. По-стар номер при `php -v` затова не е указание за липсваща поправка. Общи указания за проверка на версията има в [Проверка на PHP версията и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Разпознаване на правилния режим на работа

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, и контролирайте резултата:

```bash
# Показване на услуги със стари библиотеки (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-и](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

## Временни мерки: указанията на 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](https://phpsos.de/bg/blog/remi-repository-php/).

## Как помага PHP SOS конкретно?

- Проверяваме на RHEL, AlmaLinux и Rocky Linux всички PHP пакети, stream-ове и външни източници и ги съпоставяме със съобщенията за сигурност.
- Инсталираме актуализации, рестартираме напълно всички worker-и и контролираме времената на стартиране на процесите.
- За контейнерни среди изграждаме образите наново и заменяме контролирано работещите инстанции.
- Състоянието за всеки сървър записваме в доказателството на [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/).


## Често задавани въпроси

**Засегнат ли е 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.

## Източници

- [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: Съобщения за сигурност](https://www.php.net/)