PHP publicó el 21 de octubre de 2026 actualizaciones urgentes para dos vulnerabilidades críticas de su motor: CVE-2026-109618 y CVE-2026-109619. Ambas pueden permitir la ejecución remota de código sin autenticación en determinadas condiciones. La investigación que puso de manifiesto su alcance combinó trabajo de especialistas de Calif, OpenAI y Wiz con modelos de inteligencia artificial. Para quienes operan webs, tiendas y servicios empresariales sobre PHP, la medida prioritaria es actualizar el runtime que atiende las peticiones.
El equipo de PHP distribuyó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y asignó a los fallos una puntuación de 9,2 en CVSS 4.0. El aviso alcanza a instalaciones que sirven solicitudes web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed; sitúa el mayor riesgo demostrado en mod_php. La presencia de PHP en un sitio indica una dependencia tecnológica, pero por sí sola no acredita que ese servidor concreto sea explotable: importan la versión instalada, su configuración, el proveedor y la ruta de ataque.
La noticia tiene además una dimensión que va más allá del parche. La Fundación PHP reconoce que existían indicios del problema de memoria desde 2024, cuando todavía faltaba demostrar una vía concreta de explotación. La auditoría asistida por IA ayudó a convertir ese indicio en pruebas de impacto y aceleró la coordinación de una corrección compleja.
Dos fallos en el núcleo de PHP, con efectos distintos
CVE-2026-109618 afecta al tratamiento de errores por agotamiento de memoria. Si PHP alcanza su límite en un momento preciso, puede quedar información interna parcialmente inicializada que después se procesa como válida. La Fundación PHP confirma ejecución remota de código con la configuración predeterminada en Apache mod_php, incluso antes de que se ejecute el código de la aplicación. También se confirmó ejecución remota mediante rutas vinculadas a la aplicación en PHP-FPM.
CVE-2026-109619 se relaciona con estado global persistente tras un error fatal. Un proceso puede conservar una referencia a memoria ya liberada y utilizarla cuando atiende una petición posterior. La Fundación describe pruebas de uso de memoria liberada, caída del proceso y ejecución remota de código en una aplicación real con mod_php. Las dos vulnerabilidades se sitúan en la gestión de memoria y errores del motor, una capa compartida por aplicaciones muy diferentes.
Wiz documentó pruebas de ejecución remota sin autenticación sobre imágenes de contenedor de WordPress, Drupal y Joomla, además de una vía de lectura de memoria del proceso que puede exponer contraseñas, tokens o claves API. Son demostraciones de laboratorio sobre configuraciones concretas; las marcas de esos gestores sirven para entender el alcance potencial, sin convertir automáticamente cada instalación en un caso comprometido. Su investigación agrupa varios mecanismos técnicos bajo los dos identificadores CVE.
Qué aportó la inteligencia artificial a la investigación
La Fundación PHP sitúa el inicio de la auditoría de Calif dentro del programa Patch the Planet el 30 de julio. El investigador Ryan A comunicó el 11 de agosto una ejecución remota incondicional ligada al problema de agotamiento de memoria. OpenAI comunicó independientemente la misma causa de fondo ese día; Wiz aportó rutas adicionales el 24 de agosto. La Fundación había encontrado señales del fallo durante trabajos anteriores, pero la dificultad de corregirlo sin romper compatibilidad, afectar al rendimiento o exigir cambios en extensiones había frenado su resolución.
Wiz explica que empleó su sistema Atlas y los modelos Gemini 4 Argon y GPT-5.6 Sol durante el análisis, la construcción de pruebas y la validación de los cambios. La intervención humana siguió siendo determinante: investigadores reprodujeron los fallos, comunicaron los resultados y el equipo de PHP diseñó y publicó los parches. Atribuir toda la detección a un único modelo borraría la historia previa del proyecto y las aportaciones independientes de varios equipos.
El episodio también expone una tensión para la seguridad del software: las herramientas capaces de explorar rutas de ejecución y adaptar pruebas aceleran el descubrimiento defensivo y pueden reducir el tiempo necesario para estudiar un parche público. Tras la circulación anticipada de los identificadores CVE el 20 de octubre, PHP adelantó un día su publicación coordinada. La Fundación señaló que, en el momento de la divulgación, su equipo no había identificado exploits funcionales entre las pruebas que examinó; esa observación corresponde a aquel momento, no a una garantía sobre actividad posterior.
Actualización y comprobaciones para equipos de TI
El inventario debe comenzar por la versión de PHP que ejecuta cada servicio en producción, incluidas imágenes de contenedor, servidores compartidos, entornos gestionados y procesos de larga vida. PHP recomienda pasar a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 según la rama, o instalar el paquete corregido del fabricante cuando este haya incorporado el arreglo. La versión visible en un gestor de contenidos o en una herramienta de despliegue puede diferir de la que procesa las peticiones reales; conviene verificar el runtime operativo después de actualizar y reiniciar los procesos correspondientes.
Las ramas 8.1 y anteriores ya no reciben actualizaciones ordinarias del proyecto PHP. Algunas distribuciones y proveedores de soporte extendido ofrecen correcciones retroportadas, y el equipo publicó cambios mínimos de código fuente para 7.4, 8.0 y 8.1. En esos sistemas, el número de versión por sí solo tampoco demuestra ausencia de parche: se necesita confirmar con el proveedor el paquete instalado y el alcance exacto de su corrección. PHP 8.2 llegará al final de su soporte de seguridad el 31 de diciembre de 2026, de modo que su actualización urgente debe acompañarse de un plan de migración.
Para entornos que no pueden actualizar de inmediato, el aviso oficial detalla medidas parciales según la vía de ataque. Advierte expresamente de que ninguna sustituye al parche. El 23 de octubre, PHP publicó además una nota informativa sobre una combinación poco habitual de configuración y cambios del serializador de sesiones durante la ejecución; recomienda desactivar temporalmente session.upload_progress.enabled hasta la siguiente versión regular para cubrir esa ruta específica. La revisión operativa debe distinguir este seguimiento posterior de los dos fallos críticos ya corregidos.
Las empresas con aplicaciones PHP pueden aprovechar la intervención para comprobar quién mantiene cada runtime, cómo llegan las actualizaciones del proveedor y cuánto tarda un despliegue de emergencia. El caso muestra la importancia de mantener trazabilidad entre el componente base, la aplicación y su infraestructura: la corrección reside en PHP, mientras que la exposición efectiva se decide en el servidor que procesa cada solicitud.
