# Как да обезопасите Apache с mod_php

> Apache mod_php след PHP2Shell: разпознаване на режима на работа, пач на PHP модула, пълен рестарт на Apache и подготовка на прехода към PHP-FPM.

Източник: https://phpsos.de/bg/server/apache-mod-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

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

## Какво е mod_php и защо има значение сега

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

PHP2Shell обхваща уязвимостите CVE-2026-109618 и CVE-2026-109619, и двете с CVSS v4.0 9,2. При втората вътрешно състояние на дадена заявка може да остане след освобождаване на паметта и да бъде използвано от по-късна заявка в същия процес. За mod_php екипът на PHP е установил най-високия риск. Контекстът и оценката са в [Защо mod_php носи най-високия риск](https://phpsos.de/bg/php2shell/mod-php-risiko/).

## Разпознаване на Apache mod_php и проверка на версията

Първо проверете дали Вашият Apache изобщо ползва mod_php. Следващите команди само четат. Имената на командите и пакетите се различават според дистрибуцията и са примери.

```bash
# Debian/Ubuntu: заредени модули
apache2ctl -M 2>/dev/null | grep -i php

# Семейство RHEL
httpd -M 2>/dev/null | grep -i php

# Кой MPM е активен? mod_php изисква prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Състояние на пакета на модула (примери)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Ако се появи модул като `php_module`, работи mod_php. Показаната версия на PHP сама по себе си не е доказателство за пача, защото дистрибуциите често внасят корекциите като бекпорт. Коригираните версии на проекта PHP са 8.5.12, 8.4.27, 8.3.36 и 8.2.35. При пакети на дистрибуции значение има дневникът на промените с номерата на CVE.

## Пач и пълен рестарт на Apache

Внесете актуализацията чрез управлението на пакетите. Тъй като PHP е в процеса на Apache, след това цялата услуга трябва да се рестартира. Презареждането на конфигурацията тук не е сигурният път.

```bash
# Debian/Ubuntu
systemctl restart apache2

# Семейство RHEL
systemctl restart httpd

# Проверка: време на стартиране на всички процеси на Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Всички процеси на Apache трябва да показват време на стартиране след актуализацията. Ако на същия сървър работят и PHP-FPM или php-cgi, рестартирайте и тези услуги.

> **Действайте веднага:**
> Ако за Вашата версия на PHP още няма наличен пач, BSI (Федерална служба за информационна сигурност на Германия) препоръчва уеб сървърът да се изключи временно от мрежата. При mod_php това тежи особено, защото атаката може да сработи преди кода на приложението.

## Временни мерки в конфигурацията на Apache

php.net посочва временни мерки, които намаляват риска, но не осигуряват пълна защита. При mod_php задавате стойностите с `php_admin_value`, респективно `php_admin_flag`, в конфигурацията на Apache, за да не могат `.htaccess` и приложенията да ги презапишат.

```apache
# Пример: в конфигурацията на VirtualHost или на целия сървър
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>
```

При функция за качване php.net посочва `post_max_size = 32M`, като `upload_max_filesize` е под тази стойност. При PHP 8.5 се добавя `fatal_error_backtraces=0`. Указанието за `memory_limit=-1` прилагате само заедно с ограничение на паметта за услугата чрез cgroups, например с `MemoryMax` в допълнение към systemd, а не чрез `RLIMIT_AS` или `RLIMIT_DATA`. След това рестартирайте Apache изцяло. Всички мерки накратко: [Незабавни мерки без пач](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/).

## Пътят встрани от mod_php

След острия пач преминаването към PHP-FPM си струва. При него PHP работи в собствени процеси, отделени от уеб сървъра. Всеки уебсайт може да получи собствен пул със собствен потребител, за всеки пул могат да се зададат ограничения, а рестартите засягат само PHP. Apache свързва PHP-FPM чрез `mod_proxy_fcgi` и тогава вместо prefork може да ползва по-модерен MPM като event.

Планирайте преминаването в тестова среда: създайте пулове за всеки уебсайт, приведете правата върху файловете към новите потребители, прехвърлете записите в `.htaccess` с `php_value` в настройките на пула, направете тестове на натоварването. Как изглежда чистото изграждане, показва [Как да обезопасите Nginx с PHP-FPM](https://phpsos.de/bg/server/nginx-php-fpm/); принципите важат и за Apache с PHP-FPM.

Независимо от режима на работа важи: пачът не премахва вече внесен зловреден софтуер. Запазете логовете от 20.10.2026 г. нататък и проверете сървъра за следи.

При търсенето на следи на сървъри с mod_php си струва да погледнете общия потребител. Тъй като всички уебсайтове работят под потребителя на Apache, например `www-data` или `apache`, нападател, овладял един уебсайт, по правило може да чете и променя и файловете на останалите. Затова проверявайте не само уебсайта, който Ви се струва подозрителен, а всички Document Root директории на сървъра. Обърнете особено внимание на PHP файлове с скорошна дата на промяна в директориите за качване и за кеш, на програмен код, собственост на потребителя на Apache, и на непознати записи в crontab на този потребител. Ако намерите нещо, първо запазете състоянието и не изтривайте прибързано, за да остане причината проследима по-късно.

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

- Проверяваме режима на работа, MPM и състоянието на пакетите и оценяваме дали Вашият сървър наистина е пачнат.
- Чрез [услугата за PHP пач](https://phpsos.de/bg/leistungen/php-patch-service/) внасяме актуализацията, рестартираме Apache изцяло и документираме доказателството.
- До пача задаваме временните мерки така, че да не могат да бъдат презаписани, и ограничаваме паметта на ниво услуга.
- В рамките на [укрепването на сървъри](https://phpsos.de/bg/leistungen/server-haertung/) планираме и тестваме преминаването към PHP-FPM с отделни пулове.


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

**Как да разбера дали моят сървър ползва mod_php?**  
Ако Apache е заредил PHP модул, той се появява в списъка с модули като php_module или с номер на версия в името. Освен това изходът на phpinfo показва под Server API записа Apache 2.0 Handler. Изтрийте такъв тестови файл веднага след това.

**Защо mod_php е особено критичен при PHP2Shell?**  
Според екипа на PHP там рискът е най-висок; показан е експлойт още преди да се изпълни какъвто и да е код на приложението. Така дори добре поддържано приложение не защитава. Затова бързата актуализация е с най-висок приоритет.

**Достатъчно ли е презареждане на Apache след актуализацията?**  
Сигурен е пълният рестарт на услугата, защото PHP е модул в процесите на Apache. След това проверете времето на стартиране на всички процеси на Apache. Не бива да остават процеси, по-стари от актуализацията.

**Сложно ли е преминаването към PHP-FPM?**  
Най-често е добре планируемо: инсталиране на PHP-FPM, създаване на пулове, преминаване на Apache към proxy_fcgi и смяна от prefork на друг MPM. Тествайте го предварително в копие на средата.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)