Vulnerabilidades críticas de PHP CVE-2026-109618 y CVE-2026-109619: lo que necesita saber

El 21 de octubre de 2026, el equipo de seguridad de PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS v4.0 de 9.2 y pueden derivar en ejecución remota de código sin autenticación en cualquier instalación de PHP que atienda peticiones web. El equipo de PHP considera mod_php el despliegue de mayor riesgo, con un exploit demostrado que se activa antes de que se ejecute cualquier código de la aplicación. Actualizar es la única solución completa. Red Sift ha analizado la base de clientes de Hardenize en busca de hosts con PHP y ha notificado directamente a los clientes afectados.

• Todas las versiones de PHP desde PHP 5 en adelante pueden estar afectadas, en PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.
• PHP 8.1 y versiones anteriores no recibirán una versión oficial. Utilice un backport del proveedor, los parches solo en código fuente del equipo de PHP para 7.4, 8.0 y 8.1, o actualice.
• Los cambios de configuración reducen la exposición a las vías de ataque conocidas, pero no hacen que una instalación sea segura.
• PHP suele venir integrado en appliances y productos de terceros, por lo que comprobar la versión en sus propios servidores no ofrece una visión completa.

PHP impulsa una gran parte de la web del lado del servidor, desde sistemas de gestión de contenidos hasta paneles de administración de appliances de red. Un fallo que permite que una petición anónima ejecute código en el propio runtime de PHP, con independencia de la aplicación que se ejecute sobre él, es de lo más amplio que puede llegar a ser una vulnerabilidad web.

El equipo de PHP avisó con antelación el 20 de octubre y publicó las correcciones al día siguiente. Los CERT nacionales reaccionaron con rapidez. CERT-EU pidió a las organizaciones que se prepararan para aplicar los parches de inmediato y que valoraran aislar las aplicaciones PHP expuestas a internet hasta que llegaran las correcciones. El NCSC del Reino Unido pidió a las organizaciones que actuaran de inmediato, empezando por localizar todos los sistemas que ejecutan PHP.

Ambos fallos residen en la forma en que PHP gestiona el estado de cada petición dentro de un worker, no en el código de ninguna aplicación.

• CVE-2026-109618, RCE por corrupción tras falta de memoria (GHSA-w8hw-w9fx-j79w). Una condición de falta de memoria puede interrumpir PHP mientras los datos internos de la petición solo están parcialmente inicializados. La limpieza de la petición trata entonces esos datos a medio construir como válidos, lo que corrompe la memoria. En las condiciones adecuadas, un atacante capaz de llevar una petición a la ruta de OOM puede aprovechar esa corrupción para ejecutar código.
• CVE-2026-109619, RCE por estado global obsoleto (GHSA-6wmf-4rv5-p3rp). El estado interno asociado a una petición puede sobrevivir a la memoria que lo respalda. Una petición posterior gestionada por el mismo worker puede usar ese estado obsoleto antes de que la inicialización normal lo restablezca, lo que provoca un use-after-free entre peticiones.

El segundo fallo es especialmente relevante para los workers de larga duración, que es como funcionan PHP-FPM, mod_php y FrankenPHP. El equipo de PHP califica mod_php como la configuración de mayor riesgo porque su exploit demostrado se activa durante el análisis de la petición, antes de que la aplicación la reciba. Una regla de firewall de aplicaciones web vinculada a las rutas de la aplicación no lo detectará.

Cualquier instalación de PHP que atienda peticiones web está dentro del alcance. Esto incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. CERT-EU señala que todas las versiones desde PHP 5 en adelante podrían estar afectadas, así que un número de versión antiguo no es motivo para restar prioridad a un host. Al contrario, es motivo para subirlo en la lista, porque PHP 8.1 y versiones anteriores no recibirán un paquete oficial.

La parte más difícil es el PHP que usted no ha instalado. Los appliances, los servicios alojados y las aplicaciones de terceros suelen incluir PHP como componente interno. Esos productos solo se corrigen cuando su proveedor publica una actualización. NCSC-NL mantiene un inventario de software con dependencia de PHP que podría estar afectado, un buen punto de partida para esa parte de la búsqueda.

Antes de la publicación de PHP, analizamos los hosts que supervisamos en toda la base de clientes de Hardenize para identificar cuáles ejecutan PHP. Después asociamos esos hosts a cada cliente y contactamos directamente con todos los afectados, con una lista de los nombres de host que podrían estar expuestos, la hora de publicación y enlaces a los avisos oficiales. Así, los equipos conocieron su exposición antes de que se publicaran las versiones corregidas y pudieron programar ventanas de mantenimiento en lugar de empezar el inventario después de la publicación.

Si es cliente de Hardenize y no ha recibido ninguna notificación, no hemos encontrado PHP en los hosts que supervisamos para usted, pero le recomendamos que realice igualmente comprobaciones básicas por su parte. El análisis externo solo ve lo que un host revela y solo abarca los activos de su cuenta. Los sistemas internos, los hosts fuera del ámbito supervisado y los productos que ocultan su runtime de PHP deben seguir comprobándose por su cuenta.

Si se ha visto afectado, aplique los parches que pueda lo antes posible. Todo lo que figura en esta lista es para los hosts que no pueda parchear hoy.

• Localice todas las instalaciones de PHP, empezando por los hosts expuestos a internet. No filtre por versión, ya que todas pueden estar afectadas. Incluya contenedores, imágenes base y todo lo compilado desde el código fuente.
• Actualice a una versión corregida. Pase a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o instale el paquete parcheado de su distribución. Las distribuciones de Linux y los proveedores de LTS recibieron los parches por adelantado. Si utiliza rpms.remirepo.net, el equipo de PHP recomienda cambiar a los paquetes de la distribución o compilar desde el código fuente, porque ese repositorio no tuvo actualizaciones el mismo día.
• Gestione las ramas sin soporte. En 8.1 y versiones anteriores, utilice un backport del proveedor, compile a partir de los backports en código fuente del equipo de PHP para 7.4, 8.0 u 8.1, o actualice.
• Reinicie todos los workers. Un binario parcheado no sirve de nada para los pools de FPM o los procesos hijo de Apache que siguen ejecutando el código antiguo.
• Rastree el PHP integrado. Revise los avisos de los proveedores de appliances y productos que incorporan PHP, y aplique sus actualizaciones a medida que se publiquen.
• Mitigue o aísle lo que no pueda parchear. Aplique las medidas provisionales que se indican a continuación. Si no es posible, tanto CERT-EU como el NCSC recomiendan desconectar de internet la aplicación expuesta hasta que esté corregida.
• Busque indicios de compromiso en los hosts que hayan permanecido expuestos. El NCSC recomienda buscar puertas traseras antes o durante la remediación en cualquier sistema que no haya podido actualizar con rapidez.

• Establezca memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache. Asegúrese de que ninguna configuración de pool, directorio o aplicación vuelva a imponer un límite finito. Un fallo de asignación subyacente aún puede alcanzar la ruta vulnerable.
• Reduzca post_max_size a 8M donde no se necesiten subidas de archivos, o a 32M donde sí se necesiten, y mantenga upload_max_filesize por debajo de ese valor. Aplique en el servidor web o el proxy límites al tamaño de la petición, al número de campos, al número de partes multipart, al número de cabeceras y a la profundidad de anidamiento, también para las peticiones sin un Content-Length utilizable.
• Utilice un límite de memoria de contenedor o de cgroup que finalice solo el worker afectado. No utilice RLIMIT_AS ni RLIMIT_DATA, ya que pueden provocar el fallo de asignación vulnerable.

• Establezca session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor, y después reinicie todos los workers. ini_set() y .user.ini se aplican demasiado tarde para servir de ayuda.
• En PHP 8.5, establezca fatal_error_backtraces=0 y reinicie todos los workers.
• Elimine las configuraciones por petición no válidas u obsoletas que emiten diagnósticos antes de la inicialización. Suprimir la salida con error_reporting, display_errors o @ no sirve de nada.
• Corrija los errores fatales y los tiempos de ejecución agotados que un atacante pueda provocar, incluidos los de callbacks, el procesamiento de subidas o importaciones y la limpieza.

Estas medidas bloquean las vías de ataque confirmadas, no todas sus variantes. Considérelas un puente hasta aplicar los parches.

La primera instrucción de los avisos de CERT-EU y del NCSC es la misma: localizar dónde se ejecuta PHP. Para la mayoría de los equipos, ese es el paso más lento, porque la respuesta está repartida entre cuentas en la nube, dominios adquiridos, sitios de marketing y appliances de proveedores que nadie tiene inventariados.

Red Sift Hardenize descubre y supervisa de forma continua sus activos externos y en la nube, de modo que cuando se descubre una vulnerabilidad a nivel de runtime como esta, la lista de hosts expuestos ya existe. Eso es lo que nos permite notificar a los clientes con nombres de host concretos antes de que se publiquen las versiones corregidas.

• Aviso de seguridad y anuncios de versiones de PHP, 20 y 21 de octubre de 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• Aviso de seguridad 2026-018 de CERT-EU
• NCSC, Problema de seguridad crítico que afecta a PHP
• Inventario php2shell de NCSC-NL con el software afectado