CVE-2026-109619: ejecución remota de código en PHP por estado global obsoleto

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

Según la PHP Foundation, un error fatal en el lugar equivocado puede dejar un estado interno que apunta a memoria de una petición anterior. Una petición posterior en el mismo worker puede entonces usar esa memoria liberada. La Foundation indica que el use-after-free y una caída del worker están confirmados, y que quien informó del fallo demostró ejecución remota de código contra una aplicación real en Apache con mod_php. La descripción del NCSC británico coincide con la frase de php.net.

El aviso de la Universidad de Toronto cita el progreso de subida de sesión, activado por defecto, como una vía confirmada. Según la recomendación provisional de PHP, session.upload_progress.enabled=0 bloquea las vías de sesión confirmadas, pero no otras variantes. Desactivarlo es una mitigación, no una corrección. No describimos cómo una petición alcanza la ventana del error fatal.

mod_php y PHP-FPM

Expel indica, citando a PHP, que PHP demostró esta CVE contra PHP-FPM cuando el propio código de la aplicación puede llevarse a un error fatal. La exposición de FPM depende de la aplicación y la configuración; aun así, PHP considera expuestas las instalaciones FPM. mod_php sigue siendo la configuración que el proyecto PHP califica de mayor riesgo. El Centro Canadiense de Ciberseguridad lo repite: un exploit demostrado en mod_php permite que una petición sin autenticación active el fallo antes del código de la aplicación.

Corrección

No hay un parche separado. Instale las versiones del 21 de octubre y reinicie cada worker. Para PHP 8.5, el proyecto cita además fatal_error_backtraces=0 como medida provisional, que solo bloquea la vía confirmada mediante backtraces de errores fatales. Ocultar los diagnósticos con error_reporting, display_errors o el operador @ no ayuda, según php.net. Google Cloud cita para el par de 5.4 a 8.5.11 como vulnerables; cómo encaja eso con las ramas realmente parcheadas figura en la página de versiones.

Por qué el fallo necesita dos peticiones en el mismo worker

El aviso completo de PHP describe el fallo como un par. Primero, una operación deja un puntero a la memoria de una petición en un estado global del worker (errores, sesión, objetos o extensiones) y se interrumpe antes de borrarlo, por ejemplo por un error fatal, un require fallido, un tiempo de ejecución agotado o falta de memoria. Después el worker libera esa memoria, atiende la siguiente petición, y algo que se ejecuta antes del arranque normal usa el puntero viejo. Las dos mitades deben caer en el mismo worker; más workers y el reciclado frenan un ataque, pero no lo impiden.

De dónde salen los ajustes tempranos, según el SAPI

Un disparador confirmado es un aviso o una deprecación emitidos mientras PHP aplica ajustes por petición antes del arranque, aunque el mensaje nunca se muestre ni se registre. Silenciar errores no sirve. Que exista ese camino depende de cómo llegan los ajustes a PHP:

• Apache mod_php: .htaccess y php_value / php_flag / php_admin_* se aplican pronto; una directiva errónea u obsoleta ahí cuenta. El php.ini normal se lee una vez al arrancar y no forma parte de esto.
• PHP-FPM: solo queda expuesto así si nginx, mod_proxy_fcgi u otro frontal pasa un PHP_VALUE o PHP_ADMIN_VALUE que produce un aviso. Los ajustes del pool y .user.ini no, porque se aplican al lanzar el worker o tras el arranque.
• LiteSpeed LSAPI: sus ajustes de entorno tempranos lo convierten en candidato condicional. FrankenPHP: sin camino temprano equivalente en su configuración por defecto, lo que según PHP no lo hace inmune.

Pasos adicionales del aviso si aún no puedes parchear

• Quitar directivas obsoletas o inválidas de todo lo que se aplica por petición, y preferir php.ini, la configuración del pool o del servidor.
• Corregir errores fatales y tiempos agotados que un visitante pueda provocar, también en código de subida, importación, páginas de error, destructores, serialización y plugins.
• Si el rendimiento lo permite, pm.max_requests=1 hace que cada worker de FPM atienda una sola petición. PHP lo presenta como opcional; es costoso.
• Desactivar session.upload_progress.enabled donde no se use, incluso tras parchear: PHP dice que es una función poco usada y poco probada.
• Para una auditoría acotada, registrar todo (log_errors=On, un error_log que funcione, error_reporting=E_ALL) y buscar avisos repetidos antes de los scripts, errores durante la limpieza, errores fatales y tiempos agotados. Un log limpio no prueba nada.