En resumen: PHP2Shell afecta a todos los modos de ejecución habituales, pero en Apache con mod_php el equipo de PHP considera que el riesgo es el más alto. Allí se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Quien opera mod_php debería actualizar primero PHP y reiniciar Apache por completo.
¿Qué es mod_php?
En mod_php, PHP es un módulo dentro del servidor web Apache. Cada proceso de Apache contiene un intérprete de PHP completo y ejecuta el código PHP directamente. Este modo de ejecución fue durante mucho tiempo el estándar y sigue extendido hasta hoy en servidores antiguos, en muchos paquetes de distribuciones y en algunas imágenes de Docker.
La alternativa es PHP-FPM: allí PHP se ejecuta como servicio propio con procesos propios, y Apache o Nginx solo reenvían las peticiones. Ambas variantes están afectadas por PHP2Shell, igual que php-cgi, FrankenPHP y LiteSpeed.
Entornos típicos con mod_php son los servidores root antiguos que funcionan sin cambios desde hace años, las instalaciones estándar de Apache desde paquetes de distribuciones y las imágenes de Docker con Apache y PHP en un mismo contenedor. Quien no sepa con seguridad qué modo de ejecución usa su servidor debería comprobarlo en lugar de suponerlo.
¿Por qué se considera especialmente arriesgada la vulnerabilidad de mod_php?
El equipo de PHP ha hecho una valoración clara sobre PHP2Shell: con mod_php el riesgo es el más alto. Motivo: allí se demostró un exploit que actúa antes de que se ejecute siquiera el código de la aplicación.
Para los operadores esto tiene una consecuencia incómoda. Muchas medidas de protección residen en la aplicación: plugins de seguridad en WordPress, módulos de cortafuegos en tiendas, comprobaciones en el código propio. Todas ellas son código de la aplicación. Si la explotación ocurre antes, llegan tarde.
A esto se suma la estrecha integración: con mod_php, PHP comparte el proceso con Apache. Lo que compromete a PHP se ejecuta con los permisos del servidor web y en su memoria. En PHP-FPM, en cambio, los pools pueden separarse con usuarios propios para cada sitio web, lo que puede limitar las consecuencias de una intrusión.
Para la priorización significa: si opera varios servidores, los que usan mod_php van primero, y en ellos es especialmente importante una posterior revisión de rastros.
Lo que no sabemos: cuántas de las 22,6 millones de instancias expuestas y potencialmente vulnerables contabilizadas en todo el mundo usan mod_php. No se han publicado cifras fiables al respecto.
¿Usa mi servidor mod_php?
Los comandos siguientes son de solo lectura. Los nombres de servicios y comandos varían según la distribución: Debian y Ubuntu usan apache2, la familia RHEL httpd.
apachectl -M 2>/dev/null | grep -i php # p. ej. php_module o 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, versión del paquete del módulo
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # familia RHEL
Si no aparece ningún módulo de PHP, Apache probablemente usa PHP-FPM mediante proxy_fcgi. Entonces valen por analogía las indicaciones de Proteger Nginx con PHP-FPM.
Qué deberían hacer ahora los operadores de mod_php
- Actualizar el módulo de PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o a un backport confirmado de su distribución.
- Reiniciar Apache por completo, no solo recargarlo. Con mod_php, el código antiguo de PHP está en cada proceso de Apache.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # familia RHEL
ps -o pid,lstart,cmd -C apache2 # comprobar la hora de inicio, en RHEL: -C httpd
- Aplicar medidas provisionales si todavía no es posible actualizar. php.net menciona, entre otras, límites fijos que las aplicaciones no pueden sobrescribir:
# configuración del servidor o VirtualHost, no .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
Con memory_limit=-1 debe añadirse un límite de memoria mediante cgroup, no mediante RLIMIT_AS ni RLIMIT_DATA. Estas medidas no son una protección completa; los detalles figuran en Medidas inmediatas si todavía no puede parchear. Si no es posible ninguna de las dos de inmediato, el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente el servidor web de la red.
Si su Apache con mod_php estuvo desprotegido en Internet entre el 17 de octubre y el parche, asegure los registros a partir del 20 de octubre y haga revisar el servidor en busca de rastros. El parche por sí solo no demuestra que no haya ocurrido nada.
A medio plazo: alejarse de mod_php
Tras el parche merece la pena mirar la arquitectura. Pasar a PHP-FPM con Apache mpm_event y proxy_fcgi, o con Nginx, separa PHP del servidor web, permite pools y usuarios propios para cada sitio web y simplifica los reinicios y los cambios de versión. No cierra PHP2Shell, pero reduce la superficie de ataque de futuras vulnerabilidades.
El cambio requiere planificación. Los ajustes que hasta ahora se fijaban con php_value en .htaccess ya no surten efecto con PHP-FPM y deben pasar al pool. Los usuarios y los permisos cambian, y las carpetas de cargas y de caché pueden necesitar nuevos permisos. En un entorno de pruebas es bien controlable; en producción y bajo presión de tiempo, no. Encontrará indicaciones para el cambio en Proteger Apache con mod_php.
¿Cómo ayuda PHP SOS en concreto?
- Reconocer: comprobamos qué servidores usan mod_php y de qué origen de paquetes procede el módulo.
- Parchear y reiniciar: con el servicio de parcheo de PHP instalamos la actualización y controlamos que ya no se ejecute ningún proceso antiguo de Apache.
- Proteger la transición: donde la actualización esté bloqueada, aplicamos las medidas de php.net en la configuración del servidor.
- Cambiar: en el marco del refuerzo de servidores planificamos y probamos el cambio a PHP-FPM con pools separados.
Preguntas frecuentes
¿Cómo sé si mi Apache usa mod_php?
Con apachectl -M o httpd -M se ven los módulos cargados. Si aparece un módulo como php_module o php8_module, PHP se ejecuta directamente dentro de Apache. En Debian y Ubuntu, a2query -m también muestra si hay un módulo php activo.
¿Me protege un plugin de seguridad de WordPress con mod_php?
En esta vulnerabilidad, no. Según el equipo de PHP, con mod_php se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Un plugin es código de la aplicación y, por tanto, llega tarde. Solo protege la actualización de PHP con reinicio de Apache.
¿Debería pasar ahora de mod_php a PHP-FPM?
Primero parchear, después cambiar. Pasar a PHP-FPM es razonable a medio plazo para la mayoría de las configuraciones, porque entonces PHP se ejecuta separado del servidor web. Pero no cierra PHP2Shell, porque PHP-FPM también está afectado.