# Proteger Apache con mod_php

> Apache mod_php tras PHP2Shell: identifique el modo de funcionamiento, parchee el módulo PHP, reinicie Apache por completo y prepare la migración a PHP-FPM.

Fuente: https://phpsos.de/es/server/apache-mod-php/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** con Apache y mod_php, PHP se ejecuta directamente dentro del servidor web. El equipo de PHP valora el riesgo de PHP2Shell como el más alto precisamente en este modo de funcionamiento, porque se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Parchee de inmediato, reinicie Apache por completo y planifique después el cambio a PHP-FPM.

## Qué es mod_php y por qué importa ahora

Con mod_php, Apache carga PHP como módulo en cada uno de sus procesos de trabajo. Cada solicitud a un archivo PHP se ejecuta directamente en ese proceso. Durante mucho tiempo fue lo habitual y es fácil de configurar. Pero también significa que todos los sitios web del servidor funcionan con el mismo usuario y que PHP comparte proceso con el servidor web.

PHP2Shell comprende las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 de 9,2. En la segunda, el estado interno de una solicitud puede persistir después de liberar la memoria y ser utilizado por una solicitud posterior en el mismo proceso. Para mod_php, el equipo de PHP ha determinado el riesgo más alto. El contexto y la valoración se explican en [Por qué mod_php tiene el riesgo más alto](https://phpsos.de/es/php2shell/mod-php-risiko/).

## Identificar Apache mod_php y comprobar la versión

Compruebe primero si su Apache usa mod_php. Los comandos siguientes solo leen. Los nombres de comandos y paquetes varían según la distribución y son ejemplos.

```bash
# Debian/Ubuntu: módulos cargados
apache2ctl -M 2>/dev/null | grep -i php

# Familia RHEL
httpd -M 2>/dev/null | grep -i php

# ¿Qué MPM está activo? mod_php exige prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Estado de los paquetes del módulo (ejemplos)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Si aparece un módulo como `php_module`, funciona mod_php. La versión de PHP mostrada, por sí sola, no prueba el parche, porque las distribuciones suelen instalar las correcciones como backport. Las versiones corregidas del proyecto PHP son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. En los paquetes de distribución cuenta el registro de cambios con los números CVE.

## Parchear y reiniciar Apache por completo

Instale la actualización con el gestor de paquetes. Como PHP está dentro del proceso de Apache, después hay que reiniciar todo el servicio. Recargar la configuración no es aquí el camino seguro.

```bash
# Debian/Ubuntu
systemctl restart apache2

# Familia RHEL
systemctl restart httpd

# Control: hora de inicio de todos los procesos de Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Todos los procesos de Apache deben mostrar una hora de inicio posterior a la actualización. Si en el mismo servidor funciona además PHP-FPM o php-cgi, reinicie también esos servicios.

> **Actuar de inmediato:**
> Si todavía no hay parche disponible para su versión de PHP, el BSI recomienda desconectar temporalmente el servidor web de la red. Con mod_php esto pesa especialmente, porque el ataque puede actuar antes del código de la aplicación.

## Medidas provisionales en la configuración de Apache

php.net menciona medidas provisionales que reducen el riesgo, pero no ofrecen una protección completa. Con mod_php se fijan los valores con `php_admin_value` o `php_admin_flag` en la configuración de Apache, de modo que `.htaccess` y las aplicaciones no puedan sobrescribirlos.

```apache
# Ejemplo: en la configuración del VirtualHost o de todo el servidor
<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>
```

Con función de carga de archivos, php.net indica `post_max_size = 32M`, con `upload_max_filesize` por debajo. En PHP 8.5 se añade `fatal_error_backtraces=0`. La indicación sobre `memory_limit=-1` solo debe aplicarse junto con un límite de memoria para el servicio mediante cgroups, por ejemplo con `MemoryMax` en un complemento de systemd, y no mediante `RLIMIT_AS` ni `RLIMIT_DATA`. Después, reinicie Apache por completo. Todas las medidas de un vistazo: [Medidas inmediatas sin parche](https://phpsos.de/es/php2shell/sofortmassnahmen-ohne-patch/).

## El camino para dejar mod_php

Tras el parche urgente, merece la pena pasar a PHP-FPM. Con él, PHP se ejecuta en procesos propios, separados del servidor web. Cada sitio web puede tener su propio pool con su propio usuario, se pueden fijar límites por pool y los reinicios solo afectan a PHP. Apache conecta PHP-FPM mediante `mod_proxy_fcgi` y entonces puede usar, en lugar de prefork, un MPM más moderno como event.

Planifique el cambio en un entorno de pruebas: crear pools por sitio web, adaptar los permisos de archivos a los nuevos usuarios, trasladar a la configuración del pool las entradas `php_value` de `.htaccess` y hacer pruebas de carga. Cómo es una configuración limpia se muestra en [Proteger Nginx con PHP-FPM](https://phpsos.de/es/server/nginx-php-fpm/); los principios valen igualmente para Apache con PHP-FPM.

Independientemente del modo de funcionamiento, un parche no elimina el software malicioso ya introducido. Conserve los registros desde el 20/10/2026 y busque rastros en el servidor.

En la búsqueda de rastros en servidores con mod_php conviene fijarse en el usuario común. Como todos los sitios web funcionan bajo el usuario de Apache, por ejemplo `www-data` o `apache`, un atacante que haya tomado el control de un sitio web suele poder leer y modificar también los archivos de los demás. Por eso no revise solo el sitio web que le parezca sospechoso, sino todos los Document Roots del servidor. Preste especial atención a archivos PHP con fecha de modificación reciente en los directorios de cargas y de caché, a código de programa que pertenezca al usuario de Apache y a entradas desconocidas en el crontab de ese usuario. Si encuentra algo, asegure primero el estado y no borre precipitadamente, para que la causa pueda reconstruirse más adelante.

## ¿Cómo ayuda PHP SOS en concreto?

- Comprobamos el modo de funcionamiento, el MPM y el estado de los paquetes y valoramos si su servidor está realmente parcheado.
- Mediante el [servicio de parcheo de PHP](https://phpsos.de/es/leistungen/php-patch-service/) instalamos la actualización, reiniciamos Apache por completo y documentamos la prueba.
- Hasta que haya parche, fijamos las medidas provisionales sin posibilidad de sobrescribirlas y limitamos la memoria a nivel de servicio.
- Dentro del [refuerzo de servidores](https://phpsos.de/es/leistungen/server-haertung/) planificamos y probamos el cambio a PHP-FPM con pools separados.


## Preguntas frecuentes

**¿Cómo sé si mi servidor usa mod_php?**  
Si Apache tiene cargado un módulo de PHP, aparece en la lista de módulos como php_module o con el número de versión en el nombre. Además, una salida de phpinfo muestra en Server API la entrada Apache 2.0 Handler. Elimine de inmediato ese archivo de prueba.

**¿Por qué mod_php es especialmente crítico con PHP2Shell?**  
Según el equipo de PHP, ahí el riesgo es el más alto; se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Por eso ni siquiera una aplicación bien mantenida protege. Una actualización rápida tiene la máxima prioridad.

**¿Basta con recargar Apache después de la actualización?**  
Lo seguro es un reinicio completo del servicio, porque PHP está dentro de los procesos de Apache como módulo. Después compruebe la hora de inicio de todos los procesos de Apache. No debe quedar ningún proceso más antiguo que la actualización.

**¿Es laborioso el cambio a PHP-FPM?**  
Casi siempre es bien planificable: instalar PHP-FPM, crear los pools, cambiar Apache a proxy_fcgi y pasar de prefork a otro MPM. Pruébelo antes en una copia del entorno.

## Fuentes

- [php.net: avisos de seguridad](https://www.php.net/)
- [Registro de cambios de PHP 8](https://www.php.net/ChangeLog-8.php)
- [BSI (Oficina Federal Alemana de Seguridad de la Información)](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)