Fallos críticos en PHP: guía rápida para sysadmins antes del parche

El equipo de seguridad de PHP publicará hoy, miércoles 21/10/2026, a las 14:00 UTC (16:00 en la España peninsular) una actualización que corrige dos vulnerabilidades críticas, ambas con un 9,2 sobre 10 en CVSS v4.0. PHP no ha dicho todavía qué versiones están afectadas ni en qué componente está el fallo, pero varios investigadores hablan de ejecución remota de código en el núcleo del intérprete. Para un administrador de sistemas, eso significa una tarde de inventario, actualización de paquetes y reinicio de servicios en cualquier servidor que ejecute PHP.

Las claves de las vulnerabilidades críticas de PHP para sysadmins en 30 segundos

• PHP corrige hoy a las 14:00 UTC dos fallos con CVSS 9,2; versiones y detalles llegarán con la publicación.
• Hay que actualizar el intérprete en cada servidor y contenedor; la aplicación no puede corregirlo.
• Upstream solo parchea las ramas 8.2 a 8.5; las distribuciones LTS pueden aplicar correcciones propias a sus paquetes.
• Hay mitigaciones temporales (progreso de subidas, multipart, WAF, privilegios), sin garantía de protección total.
• No hay ataques confirmados, pero se esperan tras el parche.

El aviso oficial llegó el 20/10/2026 después de que la existencia de los fallos se filtrara antes de tiempo. Los identificadores que circulan, CVE-2026-109618 y CVE-2026-109619, no los ha citado PHP. El resumen de lo confirmado y lo que dicen los investigadores está en este artículo de opensecurity.es sobre las dos vulnerabilidades críticas de PHP filtradas antes del parche. Aquí el foco está en lo operativo.

Inventario: dónde hay PHP y qué versión

El primer trabajo es saber qué hay que actualizar. PHP suele estar en más sitios de los que constan en el inventario: servidores web, paneles de hosting, contenedores, imágenes de CI, herramientas internas o máquinas de desarrollo expuestas. En Debian y Ubuntu, y en sistemas de la familia Red Hat, estos comandos dan una primera foto:

# Versión del intérprete de línea de comandos
php -v

# Paquetes instalados (Debian/Ubuntu)
dpkg -l 'php*' | grep ^ii

# Paquetes instalados (RHEL, Rocky, Alma, Fedora)
rpm -qa 'php*'

# Versiones de PHP-FPM activas
systemctl list-units --type=service | grep -i phpLenguaje del código: PHP (php)

Conviene no fiarse solo de php -v. En un mismo servidor pueden convivir varias versiones, por ejemplo con los repositorios de Ondřej Surý en Debian y Ubuntu o de Remi en RHEL, y la del CLI no tiene por qué coincidir con la que ejecuta PHP-FPM o mod_php. En contenedores hay que revisar cada imagen:

docker ps --format '{{.Names}} {{.Image}}'
docker exec NOMBRE_CONTENEDOR php -vLenguaje del código: JavaScript (javascript)

Actualizar en cuanto haya paquetes

Cuando PHP publique las nuevas versiones, el ritmo lo marcará el origen de los paquetes. Si se usan los binarios de upstream o repositorios como los de Surý o Remi, las nuevas versiones suelen llegar poco después de la publicación oficial. Si se usan los paquetes de la distribución, hay que seguir sus avisos de seguridad (Debian Security, Ubuntu Security Notices o Red Hat), porque las distribuciones con soporte a largo plazo suelen aplicar la corrección a la versión que empaquetan, aunque esa rama ya no tenga soporte upstream. Esto es relevante para servidores con PHP 8.1 o anteriores que vengan de una distribución LTS.

# Debian/Ubuntu
apt update
apt install --only-upgrade 'php8.3*'
systemctl restart php8.3-fpm

# RHEL y derivadas
dnf upgrade 'php*'
systemctl restart php-fpm

# Con mod_php, reiniciar Apache
systemctl restart apache2   # o httpdLenguaje del código: PHP (php)

Sin reinicio, los procesos de PHP-FPM o Apache siguen ejecutando el binario antiguo en memoria, así que la actualización no surte efecto. En contenedores, hay que reconstruir las imágenes sobre la imagen base corregida y volver a desplegar; actualizar dentro de un contenedor en marcha no sirve. Si la aplicación usa PHP compilado a medida, toca recompilar con el código corregido.

Para los sistemas que estén en ramas sin soporte de upstream y sin parches de su distribución, como PHP 7.x instalado a mano o imágenes antiguas, no habrá corrección oficial. La única salida real es migrar a PHP 8.2 o superior, con las pruebas de compatibilidad que eso implique.

Cómo mitigar el riesgo hasta aplicar el parche

Ninguna de estas medidas sustituye a la actualización, y como no hay detalles técnicos oficiales, ninguna está validada contra estos fallos concretos. Su objetivo es reducir la superficie de ataque y limitar el daño durante las horas en las que un servidor no pueda actualizarse. Conviene probarlas primero en un entorno de pruebas.

1. Desactivar el progreso de subidas de sesión

GMO Flatt Security sostiene que el fallo estaría en la función de progreso de subidas de las sesiones de PHP, activada por defecto, y propone desactivarla. La empresa advierte de que no puede asegurar que eso detenga el ataque, y otros investigadores creen que uno de los dos fallos está en el procesamiento de formularios multipart, que esta opción no cubriría. Se puede aplicar de forma global o por pool de PHP-FPM:

; php.ini (CLI, FPM o Apache, según el SAPI)
session.upload_progress.enabled = 0

; Pool de PHP-FPM, por ejemplo /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

Después de recargar el servicio hay que comprobar el valor efectivo en el SAPI que sirve las peticiones, no solo en el CLI, por ejemplo con una página temporal de phpinfo() protegida o con php-fpm8.3 -i. Pocas aplicaciones dependen de esa función, aunque alguna barra de progreso de subidas podría dejar de funcionar.

2. Limitar las peticiones multipart a donde hacen falta

Si los fallos están en el tratamiento de subidas y formularios multipart, como apuntan los investigadores, reducir dónde se aceptan esas peticiones reduce la exposición. En muchas aplicaciones solo unas pocas rutas necesitan recibir archivos. Si una aplicación no sube archivos en absoluto, se puede valorar además file_uploads = Off en su pool, sabiendo que no está confirmado que eso evite el fallo. En nginx, una forma sencilla de rechazar el multipart fuera de una ruta concreta es comprobarlo a nivel de server, para que afecte también a las peticiones dirigidas a archivos .php:

# Dentro del bloque server: rechazar multipart salvo en /subidas/
set $bloquear_multipart 0;
if ($http_content_type ~* "multipart/form-data") {
    set $bloquear_multipart 1;
}
if ($uri ~ "^/subidas/") {
    set $bloquear_multipart 0;
}
if ($bloquear_multipart) {
    return 403;
}Lenguaje del código: PHP (php)

Es una medida agresiva que puede romper formularios, paneles de administración o plugins, así que hay que adaptarla a cada aplicación. En sitios WordPress, por ejemplo, la subida de medios pasa por /wp-admin/async-upload.php y otras rutas del área de administración, que habría que dejar abiertas, idealmente solo para IP de confianza.

3. Filtrar el campo de progreso de subidas en el WAF

La función de progreso de subidas se activa cuando una petición multipart incluye un campo con el nombre definido en session.upload_progress.name, que por defecto es PHP_SESSION_UPLOAD_PROGRESS. Quien use ModSecurity u otro WAF propio puede bloquear las peticiones que lo contengan, una regla que no es oficial y que no cubriría el posible segundo fallo:

SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" "id:1026101,phase:2,deny,status:403,log,msg:'Campo de progreso de subidas de PHP bloqueado'"Lenguaje del código: CSS (css)

4. Reducir lo que puede hacer un atacante

Si alguien llega a ejecutar código, el daño depende de los privilegios del proceso. Conviene revisar que cada sitio tiene su propio pool de PHP-FPM con un usuario sin privilegios, que open_basedir limita el acceso al sistema de archivos y que el usuario de PHP no puede escribir fuera de los directorios necesarios. Deshabilitar funciones como exec, shell_exec, system, passthru, proc_open o popen con disable_functions dificulta el uso habitual de una web shell, aunque una corrupción de memoria podría saltarse esa restricción. Bloquear las conexiones salientes del usuario de PHP-FPM en el cortafuegos, salvo las que necesite la aplicación, también complica que un atacante descargue herramientas o exfiltre datos.

5. Aislar, vigilar y tener plan de vuelta atrás

El CERT-EU recomienda, si no se puede parchear de inmediato, valorar aislar de Internet las aplicaciones PHP expuestas hasta poder hacerlo, por ejemplo restringiendo el acceso por VPN o por IP. Para detectar un posible compromiso, es útil vigilar la aparición de archivos PHP nuevos en directorios de subidas y de caché, procesos hijos inesperados de PHP-FPM y conexiones salientes anómalas:

# Archivos PHP creados o modificados en la última hora
find /var/www -name '*.php' -mmin -60 -ls

# Procesos lanzados por el usuario de PHP-FPM
ps -u www-data -fLenguaje del código: PHP (php)

Los registros de acceso y de PHP-FPM deben conservarse y, a ser posible, enviarse fuera del servidor, por si después hay que investigar. Y antes de actualizar, una copia de seguridad o una instantánea de la máquina permite volver atrás si la nueva versión rompe algo. Es otro recordatorio de que, como ya contamos en este medio, ningún ecosistema está a salvo.

6. Si las webs están detrás de Cloudflare

Cloudflare publicó el 21/10/2026 una actualización de emergencia de su Cloudflare Managed Ruleset, el conjunto de reglas gestionadas de su cortafuegos de aplicaciones web (WAF), con cuatro reglas nuevas llamadas «Generic Rules – Anomalous Execution» (de la 1 a la 4) para detectar patrones de peticiones anómalos. La 1 y la 3 bloquean por defecto; la 2 y la 4 solo registran. La compañía no vincula estas reglas a las vulnerabilidades de PHP ni explica qué detectan, así que no hay confirmación de que cubran este caso, pero añaden una capa más mientras se parchea:

• Comprobar que el Cloudflare Managed Ruleset está activado en cada zona: en Security > Settings, filtrar por «Web application exploits» y activar «Cloudflare managed ruleset». Solo está disponible en los planes Pro, Business y Enterprise; el plan gratuito incluye el Free Managed Ruleset, que la nota de Cloudflare no menciona.
• Revisar las cuatro reglas desde Security rules, en la regla del conjunto gestionado, con la opción «Browse rules», y valorar pasar a bloqueo las dos que solo registran tras comprobar en los eventos de seguridad que no generan falsos positivos.
• Vigilar los eventos de seguridad para ver si estas reglas saltan sobre las aplicaciones PHP.
• Cerrar el origen: que el cortafuegos del servidor solo acepte HTTP y HTTPS desde los rangos de IP que publica Cloudflare, porque el WAF no ve las peticiones que llegan directamente a la IP del servidor.

Si además se usa la regla propia de ModSecurity del punto 3, las dos capas son compatibles. Ninguna sustituye a la actualización de PHP.

A primera hora de hoy ni PHP ni las empresas que han analizado el caso habían informado de ataques reales. Los investigadores esperan intentos de explotación poco después de la publicación, cuando sea posible comparar el código corregido con el anterior, así que las primeras horas tras las 14:00 UTC son las que más importan.

Preguntas frecuentes

¿Cuándo sale la actualización de seguridad de PHP?

Hoy, 21/10/2026, a las 14:00 UTC (16:00 en la España peninsular). PHP puede adelantarla si se publican detalles o se detecta explotación activa.

¿Basta con actualizar los paquetes de PHP?

Hay que actualizar y reiniciar PHP-FPM o Apache, porque los procesos en marcha siguen usando el binario antiguo. En contenedores hay que reconstruir y redesplegar las imágenes.

¿Qué pasa con PHP 8.1 o 7.4 en una distribución LTS?

PHP solo parchea las ramas 8.2 a 8.5, pero las distribuciones con soporte a largo plazo suelen aplicar correcciones propias a sus paquetes. Hay que seguir los avisos de seguridad de cada distribución.

¿Cómo mitigar las vulnerabilidades de PHP si no se puede parchear todavía?

Desactivando session.upload_progress, limitando las peticiones multipart a las rutas que las necesitan, filtrando el campo PHP_SESSION_UPLOAD_PROGRESS en el WAF o con las reglas de emergencia de Cloudflare, reduciendo privilegios de PHP-FPM y aislando las aplicaciones expuestas. Ninguna medida sustituye a la actualización.

Fuentes:

• OpenSecurity: PHP corrige hoy dos fallos críticos que se filtraron antes del parche
• PHP: Upcoming Critical PHP Security Release
• CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
• GMO Flatt Security: análisis de php2shell
• Cloudflare: WAF Release 2026-10-21, Emergency, Cloudflare Managed Ruleset
• PHP: versiones con soporte