# Защо mod_php носи най-висок риск

> Защо екипът на PHP оценява риска от PHP2Shell при Apache с mod_php като най-висок, как да разпознаете mod_php и какво да пачнете и смените сега.

Източник: https://phpsos.de/bg/php2shell/mod-php-risiko/  
Актуалност: 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

**Накратко:** От PHP2Shell са засегнати всички обичайни режими на работа, но при Apache с mod_php екипът на PHP оценява риска като най-висок. Там е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Който ползва mod_php, трябва първо да актуализира PHP и да рестартира Apache изцяло.

## Какво е mod_php?

При mod_php PHP е модул в рамките на уеб сървъра Apache. Всеки процес на Apache съдържа пълен PHP интерпретатор и изпълнява PHP код директно. Този режим дълго беше стандартен и до днес е разпространен на по-стари сървъри, в много пакети на дистрибуции и в някои Docker образи.

Алтернативата е PHP-FPM: там PHP работи като самостоятелна услуга със собствени процеси, а Apache или Nginx само предава заявките нататък. И двата варианта са засегнати от PHP2Shell, както и php-cgi, FrankenPHP и LiteSpeed.

Типични среди с mod_php са по-стари root сървъри, които работят от години без промяна, стандартни инсталации на Apache от пакети на дистрибуции и Docker образи с Apache и PHP в един контейнер. Който не знае със сигурност какъв режим ползва неговият сървър, трябва да го провери, вместо да предполага.

## Защо уязвимостта в mod_php се смята за особено рискова?

Екипът на PHP даде за PHP2Shell ясна оценка: при mod_php рискът е най-висок. Обосновка: там е показан експлойт, който действа, преди да започне да се изпълнява какъвто и да е код на приложението.

За операторите това има неудобно следствие. Много защитни мерки са в приложението: добавки за сигурност във WordPress, модули за защитна стена в магазини, проверки в собствения код. Всички те са код на приложението. Ако експлоатацията става преди тях, те идват твърде късно.

Добавя се тясното преплитане: при mod_php PHP споделя процеса с Apache. Каквото PHP компрометира, работи с правата на уеб сървъра и в неговата памет. При PHP-FPM пуловете, напротив, могат да се разделят със собствени потребители за всеки уебсайт, което може да ограничи последиците от едно проникване.

За приоритизирането това означава: ако управлявате няколко сървъра, тези с mod_php са първи на ред и при тях последващата проверка за следи е особено важна.

Какво не знаем: колко от преброените в световен мащаб 22,6 милиона изложени на риск, потенциално уязвими инстанции ползват mod_php. Надеждни числа по темата не са публикувани.

## Ползва ли моят сървър mod_php?

Следните команди са само за четене. Имената на услугите и командите се различават според дистрибуцията: Debian и Ubuntu ползват `apache2`, семейството RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # напр. php_module или php8_module
httpd -M 2>/dev/null | grep -i php         # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php                   # Debian/Ubuntu
apt policy libapache2-mod-php8.3           # Debian/Ubuntu, състояние на пакета на модула
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # семейство RHEL
```

Ако не се появи PHP модул, Apache вероятно ползва PHP-FPM през `proxy_fcgi`. Тогава по смисъл важат бележките на страницата [Защита на Nginx с PHP-FPM](https://phpsos.de/bg/server/nginx-php-fpm/).

## Какво трябва да направят операторите на mod_php сега

1. **Актуализирайте PHP модула** до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или до потвърден backport на Вашата дистрибуция.
2. **Рестартирайте Apache изцяло,** не само презареждане. При mod_php старият PHP код е във всеки процес на Apache.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # семейство RHEL
ps -o pid,lstart,cmd -C apache2    # проверете времето на стартиране, при RHEL: -C httpd
```

3. **Задайте временни мерки, когато актуализацията още не е възможна.** php.net назовава, между другото, твърди ограничения, които приложенията не могат да презаписват:

```apache
# Конфигурация на сървъра или VirtualHost, не .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

При `memory_limit=-1` към това спада ограничение на паметта чрез cgroup, а не чрез `RLIMIT_AS` или `RLIMIT_DATA`. Тези мерки не са пълна защита; подробностите са на страницата [Незабавни мерки, когато още не можете да пачнете](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/). Ако нито едното не е възможно веднага, BSI препоръчва уеб сървърът да се изключи временно от мрежата.

> **Действайте веднага:**
> Ако Вашият Apache с mod_php е работил незащитен в интернет между 17 октомври и пача, запазете логовете от 20 октомври нататък и поискайте сървърът да бъде проверен за следи. Пачът сам не доказва, че нищо не е станало.

## Средносрочно: далеч от mod_php

След пача си струва погледът към архитектурата. Преминаването към PHP-FPM с Apache `mpm_event` и `proxy_fcgi` или с Nginx отделя PHP от уеб сървъра, позволява собствени пулове и потребители за всеки уебсайт и прави рестартиранията и смяната на версии по-лесни. То не затваря PHP2Shell, но намалява повърхността за атака на бъдещи уязвимости.

Преминаването изисква планиране. Настройки, които досега са се задавали с `php_value` в `.htaccess`, под PHP-FPM вече не действат и трябва да се преместят в пула. Потребителите и правата се променят, директориите за качвания и кеш може да се нуждаят от нови разрешения. В тестова среда това се овладява добре, в живата експлоатация под натиск от времето не. Бележки по преминаването ще намерите на страницата [Защита на Apache с mod_php](https://phpsos.de/bg/server/apache-mod-php/).

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

- **Разпознаване:** Проверяваме кои сървъри ползват mod_php и от кой източник на пакети идва модулът.
- **Пачване и рестартиране:** Чрез [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/) внасяме актуализацията и контролираме, че не работи повече стар процес на Apache.
- **Осигуряване на преходния период:** Където актуализацията е блокирана, задаваме мерките на php.net в конфигурацията на сървъра.
- **Преминаване:** В рамките на [заздравяването на сървъра](https://phpsos.de/bg/leistungen/server-haertung/) планираме и тестваме смяната към PHP-FPM с разделени пулове.


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

**По какво разбирам дали моят Apache използва mod_php?**  
С apachectl -M или httpd -M виждате заредените модули. Ако там има модул като php_module или php8_module, PHP работи директно в Apache. При Debian и Ubuntu a2query -m също показва дали е активен php модул.

**Защитава ли ме добавка за сигурност във WordPress при mod_php?**  
При тази уязвимост не. Според екипа на PHP при mod_php е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Добавката е код на приложението и така идва твърде късно. Защита дава само актуализацията на PHP с рестартиране на Apache.

**Трябва ли сега да премина от mod_php към PHP-FPM?**  
Първо пачнете, после сменете. Преминаването към PHP-FPM е средносрочно разумно за повечето конфигурации, защото PHP тогава работи отделно от уеб сървъра. То обаче не затваря PHP2Shell, защото и PHP-FPM е засегнат.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)