Cómo mitigar las fallas críticas de PHP paso a paso

El 20 de octubre de 2026 el proyecto PHP corrigió dos vulnerabilidades críticas (CVSS 9.2): CVE-2026-109618 y CVE-2026-109619. Las dos permiten ejecutar código en tu servidor con una sola petición, sin autenticarse y antes de que corra el código de tu aplicación. Ya hay pruebas de concepto públicas y CERT-EU considera probable la explotación activa (boletín 2026-018).

Esta guía te lleva de principio a fin: encontrar todo lo que corre PHP, confirmar la versión real, actualizar, aplicar mitigaciones si no puedes actualizar hoy y verificar que quedó bien.

Qué está pasando

Afecta a todo PHP que atienda peticiones web: PHP-FPM, mod_php de Apache (el de mayor riesgo), php-cgi, FrankenPHP y LiteSpeed. No importa qué aplicación tengas encima: WordPress, Laravel, Magento, Moodle o un desarrollo propio quedan expuestos por igual.

1Inventario de todo lo que corre PHP

El error más común es parchar el servidor principal y olvidar los demás. Haz una lista con:

• Servidores web propios (físicos, virtuales o en la nube) con Apache, nginx, LiteSpeed o Caddy y PHP.
• Servidores con varias versiones de PHP, típicos de los paneles de hosting (cPanel, Plesk, DirectAdmin, ISPConfig y similares): cada versión instalada cuenta por separado.
• Contenedores e imágenes Docker basadas en php: u otras que incluyan PHP.
• Productos de terceros con PHP incorporado: paneles de administración, appliances, sistemas de ticketing, monitoreo o gestión. Para detectarlos, el NCSC de Países Bajos publicó la herramienta php2shell; además, consulta al fabricante de cada producto.
• Hosting compartido: si tu sitio está en un hosting de terceros, pregúntale al proveedor si ya actualizó.

Prioriza lo que está expuesto a Internet: ahí basta una petición para explotar la falla.

2Confirma la versión real

En cada servidor, revisa qué versiones están instaladas:

# Versión de la línea de comandos
php -v

# Todas las versiones de PHP-FPM instaladas
ls /usr/sbin/php-fpm* 2>/dev/null
php-fpm8.3 -v        # repite con cada versión (8.1, 8.2, 8.4...)

# Debian / Ubuntu
dpkg -l 'php*' | grep -E '^ii' | awk '{print $2, $3}'

# RHEL / AlmaLinux / Rocky
rpm -qa 'php*'

¿Tu distribución ya trae el parche?

Debian, Ubuntu, RHEL y sus derivadas aplican el parche sin cambiar el número de versión principal. Un Ubuntu puede mostrar 8.3.6 y estar corregido. Por eso, revisa el registro de cambios del paquete y busca los CVE:

# Debian / Ubuntu (ajusta 8.3 a tu versión)
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Si ambos CVE aparecen, ese paquete ya está corregido. Si no aparece nada, sigue con el paso 3.

3Actualiza

Debian y Ubuntu

apt update
apt install --only-upgrade 'php*'

RHEL, AlmaLinux y Rocky

dnf upgrade 'php*'

Si usas repositorios externos

• Remi (rpms.remirepo.net): no tendrá la actualización el día de la publicación. Pásate a los paquetes de la distribución o compila desde el código fuente.
• Otros repositorios (por ejemplo, PPA de terceros en Ubuntu): confirma que el paquete instalado ya sea la versión corregida de la tabla, o que su registro de cambios mencione los dos CVE.

Docker

Actualizar el servidor no corrige los contenedores: hay que reconstruir la imagen con una versión corregida y volver a desplegar.

# En tu Dockerfile, fija la versión corregida, por ejemplo:
FROM php:8.4.27-fpm

docker build --pull -t mi-app .
docker compose up -d --force-recreate

Paneles de hosting y productos de terceros

Actualiza cada versión de PHP desde el panel (o con el gestor de paquetes del panel) y aplica las actualizaciones que publique cada fabricante. Si un producto no tiene parche, aíslalo de Internet hasta que lo tenga.

4Reinicia y verifica

Los procesos que ya estaban corriendo siguen usando el código viejo hasta que se reinician:

# PHP-FPM (todas las versiones instaladas)
systemctl restart 'php*-fpm'

# Apache con mod_php
systemctl restart apache2     # o httpd en RHEL

# LiteSpeed
systemctl restart lsws

Después, vuelve a ejecutar los comandos del paso 2 y confirma la versión que reporta el servidor web, no solo la del CLI.

5Mitigaciones si no puedes actualizar hoy

Contra CVE-2026-109618 (agotamiento de memoria)

a) Quita el límite de memoria de PHP sin que las aplicaciones puedan cambiarlo. Así la petición no llega al punto donde se produce la falla:

; Pool de PHP-FPM (por ejemplo /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_value[memory_limit] = -1

# Apache con mod_php
php_admin_value memory_limit -1

Luego busca configuraciones que vuelvan a poner un límite finito (otro pool, un .htaccess, la configuración de la aplicación):

grep -rn memory_limit /etc/php* /etc/apache2 /etc/httpd /var/www 2>/dev/null

b) Pon un límite de memoria externo, porque sin memory_limit un proceso podría consumir toda la RAM. Con systemd, por ejemplo con systemctl edit php8.3-fpm:

[Service]
MemoryMax=2G
# Que el kernel termine solo el proceso que se excede, sin detener todo el servicio
OOMPolicy=continue

Ajusta MemoryMax a la RAM de tu servidor. No uses LimitAS ni LimitDATA (RLIMIT_AS y RLIMIT_DATA): provocan justamente el fallo vulnerable.

c) Reduce el tamaño de las peticiones en PHP (8M si el sitio no recibe archivos, 32M si los recibe; upload_max_filesize siempre menor):

post_max_size = 8M
upload_max_filesize = 6M

d) Limita las peticiones en el servidor web o proxy, incluidas las que llegan sin Content-Length (chunked):

# nginx (bloque http o server)
client_max_body_size 8m;
large_client_header_buffers 4 8k;

# Apache
LimitRequestBody 8388608
LimitRequestFields 50
LimitRequestFieldSize 8190

Si tienes un WAF o proxy delante, limita también la cantidad de campos, de partes multipart, de cabeceras y la profundidad de anidamiento.

Contra CVE-2026-109619 (estado reutilizado)

e) Desactiva el progreso de subida de sesiones. Debe ir en php.ini, en el pool de FPM o en la configuración del servidor (ini_set() y .user.ini no sirven, porque se aplican tarde):

; php.ini
session.upload_progress.enabled = 0

; o en el pool de PHP-FPM
php_admin_flag[session.upload_progress.enabled] = off

f) Solo en PHP 8.5: desactiva fatal_error_backtraces:

fatal_error_backtraces = 0

g) Corrige la configuración que genera avisos al iniciar cada petición (directivas inválidas u obsoletas). Ocultarlos con error_reporting, display_errors o @ no ayuda: hay que corregirlos. Revisa el log de PHP-FPM:

grep -iE 'PHP (Warning|Deprecated|Notice)' /var/log/php*-fpm.log | sort | uniq -c | sort -rn | head

h) Corrige los errores fatales y los timeouts que un atacante pueda provocar: callbacks, subidas e importaciones de archivos, y tareas de limpieza.

Aplica y comprueba

systemctl restart 'php*-fpm'     # o apache2 / httpd / lsws
php-fpm8.3 -i | grep -E 'memory_limit|post_max_size|upload_progress'

Las mitigaciones solo bloquean las vías de ataque confirmadas, no otras variantes. Programa la actualización igual.

6Revisa señales de compromiso

Si el servidor estuvo expuesto sin parche, conviene revisar con buenas prácticas generales (no son indicadores oficiales de esta falla):

• Ráfagas de errores Allowed memory size exhausted o de errores fatales en los logs de PHP desde el 20 de octubre, sobre todo en peticiones con subida de archivos.
• Archivos .php nuevos o modificados en las carpetas públicas: find /var/www -name '*.php' -newermt '2026-10-20' -ls
• Procesos o conexiones de salida inusuales del usuario del servidor web (www-data, apache, nginx).
• Tareas programadas (crontab -l -u www-data) o usuarios que no reconoces.

Si encuentras algo, no borres nada todavía: aísla el servidor, conserva los logs y pide apoyo para analizarlo. Tener respaldos inmutables te deja un punto de restauración limpio.

Lista de verificación final

• Inventario completo: servidores, versiones múltiples, contenedores y productos de terceros.
• Cada versión de PHP actualizada a 8.5.12, 8.4.27, 8.3.36, 8.2.35 o al paquete parchado de la distribución.
• PHP-FPM, Apache o LiteSpeed reiniciados.
• Versión confirmada en el servidor web (php-fpm -i o phpinfo()), no solo en el CLI.
• Imágenes Docker reconstruidas y contenedores recreados.
• Lo que no se pudo actualizar quedó aislado de Internet o con todas las mitigaciones del paso 5.
• Logs y carpetas públicas revisados en busca de señales de compromiso.
• Ramas sin soporte (7.4, 8.0, 8.1) con plan de migración.

Preguntas frecuentes

Referencias

• Anuncio oficial de PHP (20 de octubre de 2026)
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Boletín CERT-EU 2026-018
• php2shell (NCSC-NL)