En resumen: mod_php es PHP como módulo del servidor web Apache. Cada proceso de Apache contiene entonces un intérprete de PHP completo y ejecuta él mismo el código PHP; la SAPI se llama apache2handler. Es fácil de configurar, pero ata PHP a Apache, suele exigir el MPM prefork y apenas permite separar unos sitios web de otros. El manual de PHP lo desaconseja para instalaciones nuevas y, en PHP2Shell, el equipo de PHP considera que el riesgo es mayor en mod_php.
¿Qué es mod_php?
En mod_php, Apache carga PHP como módulo propio en sus procesos. No hay un servicio PHP independiente: cuando Apache debe entregar un archivo .php, el mismo proceso que aceptó la petición ejecuta también el código PHP. Durante muchos años fue la forma habitual de ejecutar PHP y sigue extendida hoy en servidores antiguos y en algunas imágenes Docker.
Según el manual de PHP, como módulo de servidor, PHP lee su configuración solo una vez, al iniciar el servidor web. Por eso, los cambios en el php.ini y las actualizaciones del módulo solo surten efecto tras reiniciar Apache.
Importante para entenderlo: los procesos de Apache viven mucho tiempo. Un proceso atiende muchas conexiones seguidas antes de ser sustituido; cuántas, lo regula la directiva de Apache MaxConnectionsPerChild. El intérprete de PHP incorporado sigue siendo el mismo durante ese tiempo. Quien sustituye la biblioteca libphp en el disco no cambia nada en los procesos en ejecución.
Para la dirección y los responsables de proyectos puede resumirse así: en mod_php, el servidor web y PHP son una unidad. Tocar uno afecta al otro. Una actualización de PHP implica reiniciar el servidor web, un fallo en PHP se ejecuta con los permisos del servidor web y separar varios sitios web en el mismo servidor es casi imposible.
¿Cómo se integra mod_php?
El manual de PHP muestra la integración en dos pasos: cargar el módulo y definir qué archivos debe procesar PHP.
LoadModule php_module modules/libphp.so
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
El manual recomienda FilesMatch con SetHandler en lugar de solo AddType, para que los archivos subidos como bild.php.jpg no se ejecuten como PHP. En Debian y Ubuntu, paquetes como libapache2-mod-php8.3 y los comandos a2enmod y a2dismod se encargan de este trabajo.
Si mod_php está activo se puede comprobar en modo lectura:
apachectl -M 2>/dev/null | grep -i php # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php # familia RHEL
apachectl -V | grep -i mpm # MPM activo (prefork, worker, event)
Prefork, Thread Safety y recursos
Apache reparte las peticiones mediante un módulo de multiprocesamiento (MPM). Según el manual de PHP, mod_php necesita el MPM prefork, salvo que PHP se haya compilado con Zend Thread Safety (--enable-zts). La mayoría de los paquetes de las distribuciones se compilan sin Thread Safety.
Prefork significa: un proceso por conexión simultánea y cada proceso lleva un intérprete de PHP completo. Incluso las peticiones de imágenes o de archivos CSS ocupan así un proceso con PHP a cuestas. Esto cuesta memoria y limita la carga que un servidor puede soportar.
| Característica | mod_php | PHP-FPM |
|---|---|---|
| ¿Dónde se ejecuta PHP? | en cada proceso de Apache | en un servicio propio |
| MPM de Apache | normalmente prefork |
event posible |
| Usuario por sitio web | no, todo como usuario de Apache | sí, por pool |
| Reiniciar PHP | solo junto con Apache | independiente de Apache |
| Ajustes por directorio | php_value en .htaccess |
pool o .user.ini |
Por eso, el manual recomienda para todas las instalaciones modernas PHP-FPM con mod_proxy_fcgi: mejor gestión de recursos, separación de procesos, reinicio de PHP sin reiniciar Apache y compatibilidad con el MPM event, que es el predeterminado desde Apache 2.4. Los fundamentos están en PHP-FPM explicado.
Ajustes con .htaccess, php_value y php_admin_value
Con mod_php, los ajustes de PHP pueden fijarse directamente en la configuración de Apache. El manual distingue aquí modos de modificación: las entradas con INI_PERDIR pueden figurar en php.ini, .htaccess o httpd.conf; las entradas con INI_SYSTEM, solo en php.ini o httpd.conf.
# En la configuración del VirtualHost: bloqueado para la aplicación
php_admin_flag display_errors off
php_admin_value upload_max_filesize 24M
# Posible en .htaccess, pero la aplicación puede sobrescribirlo
php_value max_execution_time 60
php_admin_value y php_admin_flag solo están permitidos en la configuración del servidor, no en .htaccess. Justo esta distinción es importante en las medidas provisionales frente a PHP2Shell, porque valores como session.upload_progress.enabled no deben poder ser restablecidos por la aplicación.
mod_php y PHP2Shell: por qué el riesgo es el mayor
El equipo de PHP considera que el riesgo por PHP2Shell es mayor en mod_php: allí se demostró un exploit antes de que se ejecute siquiera código de la aplicación. Los plugins de seguridad o las comprobaciones en el CMS llegan, por tanto, demasiado tarde. A ello se suma que, en mod_php, PHP se ejecuta con los permisos y en la memoria del servidor web. La valoración detallada está en Por qué mod_php soporta el mayor riesgo.
Para los operadores rige, por tanto:
- Actualizar el módulo de PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o a un backport confirmado.
- Reiniciar Apache por completo, no solo recargarlo, y comprobar la hora de inicio de los procesos.
- Fijar los valores provisionales mediante
php_admin_valueen la configuración del servidor si la actualización todavía no es posible. - Después, planificar el cambio a PHP-FPM, como se describe en Proteger Apache con mod_php.
¿Cómo ayuda PHP SOS en concreto?
- Reconocer: comprobamos en qué servidores se ejecuta mod_php, con qué MPM y desde qué origen de paquetes.
- Parchear: actualizamos el módulo de PHP, reiniciamos Apache por completo y demostramos el estado.
- Asegurar la transición: donde la actualización está bloqueada, fijamos las medidas de php.net de forma bloqueada en la configuración del servidor.
- Migrar: en el marco del refuerzo del servidor migramos, con pruebas, a PHP-FPM con pools propios.
Preguntas frecuentes
¿Por qué se llama mod_php si el módulo se llama php_module?
mod_php es el nombre coloquial de PHP como módulo de Apache. En la configuración se carga con LoadModule; el manual de PHP da como ejemplo LoadModule php_module modules/libphp.so. Las versiones anteriores utilizaban nombres como php7_module o php5_module.
¿Por qué necesita mod_php el MPM prefork?
Según el manual de PHP, mod_php necesita el MPM prefork, salvo que PHP se haya compilado con Zend Thread Safety. La mayoría de los paquetes de las distribuciones se compilan sin Thread Safety. Prefork inicia un proceso propio por cada conexión simultánea, lo que requiere más memoria.
¿Funcionan las líneas php_value de .htaccess también con PHP-FPM?
No. php_value y php_flag en .htaccess son directivas de Apache del módulo de PHP y solo funcionan con mod_php. Con PHP-FPM, esos ajustes van en el pool o, para los valores permitidos, en un .user.ini.
¿Debo eliminar mod_php de inmediato?
Lo primero es la actualización de PHP con reinicio completo de Apache. El cambio a PHP-FPM es después recomendable, pero debe planificarse y probarse. No cierra PHP2Shell, porque PHP-FPM también está afectado.