PHP corrige dos vulnerabilidades críticas que pueden permitir ejecutar código de forma remota sin autenticación

Qué ha pasado

El proyecto PHP ha publicado el 21 de octubre de 2026 dos vulnerabilidades críticas en el intérprete, CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS 9.2 (versión 4.0) y pueden desembocar en ejecución remota de código (RCE). En la última semana las han citado 16 medios especializados distintos.

Según el aviso de PHP (GHSA-w8hw-w9fx-j79w), CVE-2026-109618 está en la forma en que PHP gestiona los errores por falta de memoria. Para abortar la petición, el intérprete sale con un salto brusco (longjmp()). En algunos momentos ese salto deja la memoria de la petición en un estado no válido, y el procedimiento de cierre la lee después. Los atacantes pueden provocar ese agotamiento de memoria con peticiones multipart manipuladas. Por ejemplo, peticiones sin una longitud declarada utilizable, partes con un número ilimitado de cabeceras o muchos campos de fichero vacíos con nombres anidados.

CVE-2026-109619 tiene otro origen, según su descripción en NVD. Cierto estado global de PHP apunta temporalmente a la memoria de la petición y, en algunos escenarios, no se reinicia correctamente. Las peticiones posteriores pueden entonces leer referencias a memoria ya liberada, lo que también permite ejecutar código. El aviso principal remite, para este segundo fallo, al informe relacionado GHSA-6wmf-4rv5-p3rp.

A quién afecta

El aviso del fabricante considera afectadas las versiones anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12, cada una en su rama. El riesgo depende de cómo se ejecute PHP en el servidor web:

• Apache con mod_php: es el escenario más grave. PHP ha validado por HTTP la ejecución remota de código sin autenticar con los límites de entrada y memoria predeterminados. El ataque se produce antes de que llegue a ejecutarse el código de la aplicación.
• FrankenPHP: el análisis del código indica que, igual que mod_php, probablemente es vulnerable a ataques que no dependen de la aplicación.
• PHP-FPM: el análisis del código lo señala como susceptible, aunque no se ha demostrado un exploit completo para este modo.
• LSAPI: funciona de forma similar a FPM. Se consideran probables los ataques que dependen de cada aplicación, pero no se han validado.

Estado de la explotación

Ninguna de las dos CVE figura en el catálogo KEV de CISA, así que no hay explotación activa confirmada. Aun así, PHP ha comprobado que la ejecución remota de código es viable contra mod_php. El código se ejecutaría con la cuenta del proceso del servidor web. Según el fabricante, la fiabilidad del ataque depende de la compilación de PHP, las extensiones instaladas, el comportamiento del frontend y la disposición de la memoria.

Qué hacer

Según el fabricante, la única mitigación completa es actualizar a una versión de PHP que incluya el parche. Recomendamos los siguientes pasos:

• Actualizar cuanto antes a PHP 8.2.35, 8.3.36, 8.4.27 o 8.5.12, según la rama. Conviene empezar por los servidores expuestos a internet que usan Apache mod_php o FrankenPHP.
• Consultar el aviso GHSA-6wmf-4rv5-p3rp, al que remite PHP para CVE-2026-109619, y aplicar también sus indicaciones.
• Si no es posible actualizar de inmediato, fijar de forma administrativa memory_limit=-1 y reiniciar todos los procesos de PHP. Después, comprobar que ningún pool, directorio o aplicación vuelve a imponer un límite finito. No es una mitigación completa.
• Mantener un post_max_size conservador y limitar en el frontend el tamaño real de las peticiones. Reducir max_input_nesting_level y acotar el número de variables de entrada, partes multipart, cabeceras por parte y subidas de ficheros.
• Bloquear en el frontend las peticiones multipart si la aplicación no las utiliza.
• No usar RLIMIT_AS ni RLIMIT_DATA, porque provocan fallos de asignación que activan precisamente la ruta vulnerable. Un límite de memoria por contenedor o cgroup (memory.max) puede servir de alternativa parcial, con limitaciones.

Fuentes

• PHP security advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption

Tecnologías afectadas

Vulnerabilidades (2)