Накратко: От 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.
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.
Какво трябва да направят операторите на mod_php сега
- Актуализирайте PHP модула до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или до потвърден backport на Вашата дистрибуция.
- Рестартирайте Apache изцяло, не само презареждане. При mod_php старият PHP код е във всеки процес на Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # семейство RHEL
ps -o pid,lstart,cmd -C apache2 # проверете времето на стартиране, при RHEL: -C httpd
- Задайте временни мерки, когато актуализацията още не е възможна. php.net назовава, между другото, твърди ограничения, които приложенията не могат да презаписват:
# Конфигурация на сървъра или 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. Тези мерки не са пълна защита; подробностите са на страницата Незабавни мерки, когато още не можете да пачнете. Ако нито едното не е възможно веднага, 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.
Как помага PHP SOS конкретно?
- Разпознаване: Проверяваме кои сървъри ползват mod_php и от кой източник на пакети идва модулът.
- Пачване и рестартиране: Чрез услугата за пач на PHP внасяме актуализацията и контролираме, че не работи повече стар процес на Apache.
- Осигуряване на преходния период: Където актуализацията е блокирана, задаваме мерките на php.net в конфигурацията на сървъра.
- Преминаване: В рамките на заздравяването на сървъра планираме и тестваме смяната към 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 е засегнат.