CVE-2026-109618: ejecución remota de código en PHP por corrupción al agotarse la memoria

Qué falla, al nivel de la información del fabricante

En oss-security, Jakub Zelenka escribió que PHP aborta el procesamiento de peticiones mediante longjmp() ante errores de falta de memoria; una asignación fallida puede interrumpir la inicialización cuando ya hay un estado de petición incompleto accesible, y el cierre de la petición puede entonces acceder a ese estado inválido, lo que podría permitir la ejecución remota de código. La explicación de la PHP Foundation coincide: si una petición alcanzaba memory_limit en el momento equivocado, podían quedar datos parcialmente inicializados que después se consideraban válidos.

No publicamos nada más allá de este mecanismo. No describimos cómo provocar el error de memoria.

Qué se ha demostrado

• oss-security: se demostró ejecución remota de código sin autenticación vía HTTP contra Apache mod_php, antes de que se ejecute el código de la aplicación. El análisis del código fuente apunta también a la exposición de FPM, pero no se demostró un exploit completo para FPM.
• PHP Foundation: se demostró ejecución remota de código completa en Apache mod_php con la configuración por defecto, antes de que se ejecute el código de la aplicación. En PHP-FPM se confirmó RCE mediante rutas de código a nivel de aplicación.
• Expel, citando a PHP: la demostración en mod_php para esta CVE funcionó con los límites por defecto de PHP para entrada y memoria.
• El aviso de la Universidad de Toronto indica que los atacantes podrían provocar ese estado con peticiones multipart manipuladas que aparentemente respetan los límites de PHP. No desarrollamos esa frase como instrucciones.

Impacto

Una explotación exitosa significa ejecución remota de código sin autenticación con los permisos de la cuenta del sistema del worker de PHP. Wiz y Cloudflare citan además caídas y la divulgación de memoria del proceso. El alcance depende del build, las extensiones y la arquitectura del servidor; según la Universidad de Toronto, la fiabilidad varía, y PHP validó una RCE completa. Las fuentes revisadas no contienen ninguna afirmación fiable de que «funciona en todas partes», ni ningún motivo para esperar antes de parchear.

Corrección

Actualice a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 o posterior y reinicie los workers que atienden tráfico. Según oss-security, la actualización es la única corrección completa. Los ajustes provisionales de PHP, como memory_limit=-1 y un post_max_size bajo, son incompletos: incluso sin un límite de memoria controlable, un error de asignación subyacente puede alcanzar la vía vulnerable. Según Tanium, la entrada de la NVD se publicó el 21 de octubre de 2026 con el estado «Undergoing Analysis». Use el aviso de PHP como fuente operativa mientras la NVD se pone al día.

Exposición según el tipo de servidor, según el aviso completo de PHP

El aviso de GitHub explica por qué el riesgo cambia según el SAPI. La clave es si PHP sigue ejecutando la limpieza de fin de petición cuando el inicio de la petición ha fallado.

Por qué los límites de subida no acotan la memoria

Según el aviso, una petición de formulario multipart puede agotar la memoria de PHP aunque parezca estar muy por debajo de los límites configurados. En resumen: un cuerpo sin longitud utilizable puede pasar el control de post_max_size; el número de cabeceras dentro de una parte no tiene límite y ocupan más en memoria que en la red; los campos de archivo vacíos no cuentan para max_file_uploads, pero PHP crea igualmente sus arrays de subida. El código de la aplicación también puede llegar a ese estado si la entrada del usuario controla una reserva grande de memoria. Nos quedamos en el nivel publicado por PHP y no describimos cómo construir una petición así.

Qué cambia la corrección dentro de PHP

Ante falta de memoria, PHP ya no salta fuera del camino de código actual. Lanza un error «suave» de memoria en el siguiente punto seguro del motor y, si el consumo llega a un segundo umbral más alto, el proceso termina de inmediato. memory_limit sigue funcionando y la limpieza ya no ve estado a medio construir.

Endurecimiento que sigue siendo útil tras parchear

Según PHP, estas medidas reducen el riesgo de cierres bruscos y de denegación de servicio incluso en versiones corregidas. No sustituyen a la actualización.

• Limitar el tamaño decodificado de las peticiones en el servidor web o el proxy, al margen de post_max_size.
• Bajar max_input_nesting_level y acotar max_input_vars, el número de partes multipart, cabeceras por parte y subidas.
• Si una aplicación o ruta nunca acepta subidas ni formularios multipart, rechazar las peticiones multipart en el borde, antes de PHP. Muchas API de frameworks que solo reciben JSON pueden hacerlo sin riesgo.
• Los límites de memoria de contenedor o cgroup (memory.max) solo sustituyen en parte a memory_limit. Matar un contenedor entero mata también al maestro de FPM y a todos los workers, salvo que cada worker tenga su propio grupo.
• No usar RLIMIT_AS ni RLIMIT_DATA como tope de memoria: según PHP, hacen que la reserva falle justo de la forma que llega al fallo.