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

Накратко: При 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 носи най-високия риск.

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

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

# 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, след това цялата услуга трябва да се рестартира. Презареждането на конфигурацията тук не е сигурният път.

# 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, рестартирайте и тези услуги.

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

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

# Пример: в конфигурацията на 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 изцяло. Всички мерки накратко: Незабавни мерки без пач.

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

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

Планирайте преминаването в тестова среда: създайте пулове за всеки уебсайт, приведете правата върху файловете към новите потребители, прехвърлете записите в .htaccess с php_value в настройките на пула, направете тестове на натоварването. Как изглежда чистото изграждане, показва Как да обезопасите Nginx с PHP-FPM; принципите важат и за Apache с PHP-FPM.

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

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

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

• Проверяваме режима на работа, MPM и състоянието на пакетите и оценяваме дали Вашият сървър наистина е пачнат.
• Чрез услугата за PHP пач внасяме актуализацията, рестартираме Apache изцяло и документираме доказателството.
• До пача задаваме временните мерки така, че да не могат да бъдат презаписани, и ограничаваме паметта на ниво услуга.
• В рамките на укрепването на сървъри планираме и тестваме преминаването към PHP-FPM с отделни пулове.

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

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets