CVE-2026-109619 en PHP: estado global reutilizado, sesiones y ejecución de código
Publicado el 2026-10-27 por frfrand
Análisis práctico de CVE-2026-109619: qué falla en los workers PHP, versiones reparadas, mitigación temporal oficial y cómo actualizar.
Un fallo distinto, publicado el mismo día
El 21 de octubre de 2026, PHP publicó una segunda vulnerabilidad crítica: CVE-2026-109619. A diferencia de la falla de memoria OOM del caso CVE-2026-109618, aquí el problema se vincula con estado interno que sobrevive indebidamente después de liberar memoria. Esto puede hacer que un trabajador PHP reutilice referencias que ya no son válidas y, bajo condiciones específicas, permita corrupción de memoria o ejecución remota de código.
¿Qué es un worker PHP y por qué importa?
Un worker es un proceso que atiende solicitudes. Muchos entornos lo reutilizan para responder a sucesivos visitantes. La aplicación debería dejar el estado correcto entre una solicitud y otra, y el motor debe limpiar referencias temporales. Si algo queda apuntando a memoria liberada, puede producirse un fenómeno llamado use-after-free.
¿Cómo se descubrió y a quién corresponde el reporte?
La investigación fue presentada por Wiz Research y el equipo PHP, junto con el otro CVE de octubre de 2026. Los investigadores examinaron cómo ciertos errores de ejecución podían interrumpir la limpieza de datos internos y dejar un estado reutilizable de forma peligrosa. La divulgación coordinada permite que el público conozca el fallo junto a las versiones corregidas.
¿Cómo se puede explotar?
El escenario general implica conducir el procesamiento de peticiones hacia errores que dejen estado interno inconsistente. Una operación posterior puede utilizar referencias a memoria ya liberada. Bajo condiciones favorables a un atacante esto podría facilitar ejecución de código o exposición de datos del proceso. La explotación varía según mod_php, PHP-FPM, el tipo de aplicación y su configuración. No debería difundirse un procedimiento reutilizable para comprometer servidores; para defensa importan el parche y las condiciones de exposición.
¿Por qué es un problema crítico?
Un proceso PHP puede tener acceso a archivos, secretos de conexión y operaciones internas de la aplicación. Ejecutar código con esos permisos puede bastar para causar daños importantes. Pero la calificación crítica no implica que todas las instalaciones puedan explotarse de la misma forma: hay dependencias de configuración y características del servidor.
¿Qué versiones necesitan actualizarse?
Los parches del proyecto PHP son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.1 y anteriores no reciben parches regulares del proyecto; consultá proveedores de mantenimiento extendido o planificá migración. Algunos Linux pueden llevar correcciones retroportadas bajo un número de versión que parece anterior, así que comprobá el boletín del paquete instalado.
¿Qué mitigaciones temporales publicó PHP?
El equipo recomendó deshabilitar session.upload_progress.enabled antes del procesamiento de solicitudes y reiniciar todos los workers para bloquear rutas confirmadas relacionadas con sesiones. En PHP 8.5 también mencionó fatal_error_backtraces=0 como medida para otra ruta conocida. Son defensas parciales y condicionadas: el propio proveedor advierte que no sustituyen instalar el parche. En el comunicado del 23 de octubre describió, además, un escenario muy inusual de cambios dinámicos del serializador de sesiones relacionado con otra investigación posterior, lo que recuerda que las configuraciones importan.
¿Cómo revisar una aplicación?
Inventariá versión de PHP, tipo de servidor, configuración de sesiones, uso de uploads y procesos que no se reiniciaron tras aplicar cambios. Si hay sospecha de explotación, revisá logs y procesos, privilegios del usuario web, cambios de archivos y credenciales que pudieron quedar accesibles. Guardá evidencia antes de hacer una limpieza indiscriminada.
Preguntas rápidas
¿Afecta a WordPress? Puede afectar a un WordPress servido por un PHP vulnerable: es un defecto de runtime, no del tema.
¿Cambiar la contraseña soluciona esto? No, aunque pueda ser parte de una respuesta a incidentes.
¿Qué hago hoy? Actualizá todos los runtimes que sirven tráfico, reinicializá workers y verificá versiones ejecutadas.
Fuentes: Avisos PHP octubre 2026 · Boletín del NCSC británico · Red Hat CVE · Registro CVE.
¿Dónde se actualiza la información y cómo pedir orientación?
En ArduMaker — CVE y soporte mantenemos información para revisar incidencias y canalizar consultas, especialmente en WordPress y las tecnologías que lo ejecutan. Para evaluar un caso concreto aportá tecnología, versión, sistema operativo, modo de despliegue y mensajes de error relevantes sin publicar credenciales. Un CVE anunciado no significa que todos los sistemas estén comprometidos.
Revisión editorial: 27 de octubre de 2026. Las recomendaciones pueden cambiar con nuevas publicaciones del fabricante.
Ejemplo práctico: comprobar la configuración de sesiones PHP
Situación: una web PHP utiliza sesiones y subida de archivos, con PHP-FPM atendiendo varias peticiones en cada proceso. CVE-2026-109619 se relaciona con referencias internas que sobreviven indebidamente entre solicitudes.
Primero identificá la configuración efectiva del servicio, no solo de la consola. Como orientación inicial:
php --ini
php -i | grep -E 'session.upload_progress.enabled|PHP Version'Ojo: la configuración CLI puede diferir de Apache y PHP-FPM. El boletín de PHP describe desactivar session.upload_progress.enabled y reiniciar los workers como medida temporal para rutas conocidas. No lo consideres parche completo.
Antes: un cambio aislado en php.ini que nunca se aplicó a los workers y una versión vulnerable. Después: versión corregida, configuración FPM comprobada, servicio reiniciado y pruebas de inicio de sesión/subida de archivos.
Ejemplo de impacto: si un worker reutiliza estado interno inválido, una petición posterior podría interactuar con memoria liberada. Ese es un error del runtime, no una cookie del usuario «mal escrita».