La versión de seguridad publicada el 21 de octubre de 2026 corrige los problemas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y las ramas anteriores no reciben una nueva versión oficial del proyecto. Se han publicado backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1. Algunos proveedores pueden ofrecer paquetes corregidos para versiones antiguas. Son medidas temporales y no sustituyen a un runtime con soporte.

terminal
composer why-not php 8.4
composer audit
vendor/bin/rector process --dry-run
vendor/bin/rector process

CVE-2026–109618 afecta al gestor de memoria de Zend. Si el agotamiento de memoria interrumpe la inicialización de estructuras internas, el código de limpieza puede tratar una estructura incompleta como si fuera válida. El procesamiento de multipart/form-data es una superficie relevante porque puede generar asignaciones importantes antes de que se ejecute el código de la aplicación. Los investigadores demostraron ejecución remota de código sin autenticación contra Apache mod_php. En PHP-FPM, un fallo durante el inicio de la petición suele terminar el worker afectado. El agotamiento de memoria después de un inicio correcto todavía puede crear condiciones inseguras. Por eso el advisory considera vulnerable a FPM, aunque no documenta un exploit completo de FPM para esta CVE.

PHP 8.5.12 sustituye la ruta inmediata de zend_bailout() presente en PHP 8.5.11 por un mecanismo diferido para los errores de memoria. El runtime registra un estado pendiente en EG(delayed_oom).state y solicita su tratamiento mediante EG(vm_interrupt) en un punto más seguro de la máquina virtual. Un límite duro separado puede finalizar el proceso con _exit(137) cuando continuar podría corromper el estado interno. El cambio afecta a la arquitectura de gestión de errores, no solo a una validación de entrada.

CVE-2026–109619 se debe a un estado perteneciente a una petición cuya referencia sobrevive después de liberar la memoria. Una petición posterior procesada por el mismo worker de Apache o PHP-FPM puede acceder entonces a un puntero obsoleto. Entre las rutas relevantes están la gestión de errores, los backtraces de errores fatales, el progreso de subida de sesiones y los diagnósticos de configuración. El progreso de subida puede ejecutarse durante el procesamiento del cuerpo de la petición, antes de la inicialización normal de la sesión. La aplicación no tiene que llamar necesariamente a session_start() para que exista esta superficie. El advisory describe una ruta de explotación de FPM validada que depende de una operación adecuada de la aplicación después del inicio de la petición.

La corrección amplía la limpieza al finalizar la petición. zend_shutdown_executor_values() elimina, entre otros campos, EG(last_fatal_error_backtrace), reinicia EG(num_errors) y asigna NULL a EG(errors) y EG(exception). La finalidad es impedir que un estado propiedad de una petición siga disponible para el siguiente ciclo del worker después de una ejecución anómala.

Las dos vulnerabilidades tienen una puntuación CVSS v4.0 de 9.2. La puntuación refleja la gravedad potencial, no la exposición exacta de cada instalación. La primera CVE tiene una ruta confirmada antes del código de la aplicación en mod_php. Para la segunda existen rutas confirmadas en mod_php y PHP-FPM, aunque FPM depende de requisitos concretos de la aplicación y la configuración. Los equipos deben comprobar la versión del runtime, la SAPI, las rutas accesibles, la configuración, el ciclo de vida de los workers y los requisitos conocidos. Un cambio temporal de configuración puede limitar algunas rutas. La corrección completa sigue siendo instalar un runtime actualizado.

En una rama con soporte, la intervención puede mantenerse pequeña, por ejemplo al pasar de PHP 8.4.26 a PHP 8.4.27. No conviene mezclar una migración importante del lenguaje con la respuesta urgente sin una justificación operativa concreta. Hay que verificar el paquete o la imagen que realmente atiende el tráfico, ejecutar pruebas automatizadas y validar los flujos críticos. En contenedores, php:8.4-fpm es una etiqueta mutable. Las cachés, los espejos internos, los retrasos del registro y los digests fijados pueden dejar una versión antigua en la imagen. Una comprobación de versión durante el build y un digest inmutable permiten verificar el artefacto. Actualizar PHP en el host no actualiza el intérprete dentro del contenedor.

Las pruebas deben cubrir subidas de archivos, importaciones, trabajos largos, excepciones, sesiones e integraciones. Después del despliegue hay que vigilar peticiones fallidas, caídas de workers, presión de memoria, reinicios y errores de negocio. Cuando la infraestructura lo permita, la publicación debe hacerse de forma progresiva. El rollback debe conservar un artefacto conocido. Volver de forma permanente a un runtime vulnerable no es una respuesta de seguridad aceptable.

El problema es mayor en PHP 8.1 y versiones anteriores. PHP 8.1 llegó al final de su vida útil el 31 de diciembre de 2025, y las ramas anteriores ya habían perdido el soporte upstream. Un backport verificable proporcionado por un proveedor puede reducir el riesgo inmediato. El objetivo estratégico debe ser una rama con soporte. PHP 8.2 llegará al final de su vida útil el 31 de diciembre de 2026. PHP 8.4 o PHP 8.5 son destinos más duraderos cuando el framework y las dependencias lo permiten.

La evaluación de compatibilidad debe revisar las restricciones de Composer, las extensiones sin soporte, las funciones eliminadas, los comportamientos obsoletos, los requisitos del framework y las dependencias de infraestructura. composer why-not php 8.4 ayuda a encontrar bloqueos de dependencias. composer audit comprueba avisos conocidos de los paquetes. Ninguno de los dos comandos demuestra la compatibilidad en ejecución. RectorPHP aplica transformaciones basadas en AST para muchos cambios del lenguaje. Una configuración puede usar RectorConfig::configure(), withPaths(), withPhpSets() o niveles graduales mediante withPhpLevel(). Los dry-runs y los lotes pequeños facilitan la revisión. Rector no actualiza el intérprete, no resuelve todos los conflictos de dependencias y no sustituye las pruebas de regresión. Las herramientas de migración asistidas por IA tienen las mismas limitaciones y requieren revisión humana.

Una actualización importante debe gestionarse como un programa de ingeniería, no como una única tarea de código. Las transformaciones, las dependencias y las pruebas deben separarse del cambio de runtime en producción. El entorno de staging debe reproducir las extensiones relevantes, la configuración, el comportamiento de la infraestructura y los datos representativos. También deben probarse los errores y la recuperación. Después, el despliegue puede avanzar por etapas con métricas técnicas y de negocio.

El análisis recuerda que la PHP Foundation reconoció indicios iniciales del problema de memoria en 2024. En ese momento todavía no se había establecido una vía concreta de explotación. La organización atribuyó parte del retraso a limitaciones de recursos y organización, y describió cambios en sus procesos de seguridad. Los parches y la documentación pública son avances importantes, pero no eliminan la responsabilidad de mantener los sistemas actualizados. El riesgo empresarial no se limita a una intrusión. También existe cuando aplicar un parche exige iniciar un proyecto urgente de modernización.