Dos fallos, una publicación de emergencia
El proyecto PHP publicó cuatro versiones de emergencia el 21 de octubre —8.5.12, 8.4.27, 8.3.36 y 8.2.35— que corrigen dos vulnerabilidades con una puntuación base CVSS v4.0 de 9.2 cada una y que permiten la ejecución remota de código sin autenticación. Los mantenedores publicaron un aviso junto a ellas pidiendo a los operadores que actualicen de inmediato.
La primera, CVE-2026-109618, es un fallo de gestión de memoria. PHP usa longjmp() para abandonar el contexto actual cuando se queda sin memoria, y el aviso describe casos en los que la memoria de la petición es accesible antes de estar inicializada del todo. Si una reserva falla en ese momento, la salida anticipada deja esa memoria inválida y el cierre de la petición puede leerla o bifurcar sobre ella. El aviso señala que un atacante puede alcanzar esa ruta mediante el análisis multipart —una cabecera content-length ausente, un exceso de cabeceras de parte, o muchos controles de fichero vacíos con nombres de campo anidados— y que eso puede derivar en ejecución remota de código con la cuenta del proceso web.
La segunda, CVE-2026-109619, es un fallo de estado residual: el estado interno propiedad de una petición puede sobrevivir después de que su memoria se libere, de modo que una petición posterior atendida por el mismo proceso puede seguir esas referencias colgantes.
El aviso de PHP dice que el riesgo es mayor en mod_php, pero que todas las instalaciones que sirven web están afectadas, y nombra PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. El aviso de GitHub es más preciso sobre hasta dónde llegó el trabajo: describe mod_php y FrankenPHP como los más directamente susceptibles, mientras que considera a FPM susceptible por análisis del código fuente sin haber demostrado un exploit completo.
Dónde entra la IA
OpenAI publicó su propio relato el mismo día. En una entrada sobre lo que llama Patch the Planet, la compañía dice que la firma de seguridad Calif identificó un fallo crítico usando GPT‑5.6 Sol, y que Wiz descubrió y reportó ambas vulnerabilidades de forma independiente. Los mantenedores de PHP dirigieron las correcciones y la publicación.
La lista de créditos del aviso de GitHub coincide con ese relato: nombra a cuatro informantes, entre ellos identificadores terminados en -wiz y -oai, y a cuatro desarrolladores de PHP que construyeron la corrección.
El encuadre de OpenAI es que el sector tuvo suerte con los tiempos. “Hasta donde sabemos, la IA de frontera encontró estas vulnerabilidades antes que los atacantes”, escribe la compañía, “abriendo una Ventana del Defensor para que mantenedores y proveedores de seguridad preparasen correcciones y protecciones antes de la divulgación”. Llama al par “uno de los problemas de seguridad más relevantes de la memoria reciente” dado el alcance de PHP, y dice esperar que hallazgos así “aumenten bruscamente en los próximos meses”. Junto a la entrada comprometió 1.000 millones de dólares en acceso subvencionado a su producto de seguridad Daybreak para organizaciones con pocos recursos de seguridad, y dijo haber contactado con la Super Intelligence Force de la Casa Blanca, la Oficina del Director Nacional Cibernético y CISA antes de la divulgación.
La versión de Cloudflare es menos cómoda
Cloudflare, que participó en la misma respuesta coordinada, bautizó al par —php2shell— y publicó su propio análisis diciendo que todo servidor web que ejecute PHP 5.4 o posterior está afectado. Afirma que empezó a construir reglas de cortafuegos de aplicaciones web a principios de octubre y las activó unas nueve horas antes de la divulgación pública, con los planes gratuitos y de pago protegidos por defecto desde las 03:02 UTC del 21 de octubre.
También dice que está viendo tráfico de ataque contra sus clientes, y que los atacantes cambiaron sus cargas para intentar esquivar las reglas, con sus analistas siguiendo los volúmenes de coincidencias para rastrear las mutaciones. Eso no contradice la afirmación de OpenAI de que los defensores encontraron los fallos primero, pero estrecha mucho la ventana: en la mañana de la divulgación, alguien ya lo estaba intentando.
Qué tienen que hacer los operadores
Actualizar es la única corrección completa. El aviso de PHP enumera medidas provisionales —fijar memory_limit=-1 mediante php_admin_value y no con ini_set(), bajar post_max_size, desactivar session.upload_progress y, en 8.5, poner fatal_error_backtraces=0— y es explícito en que ninguna deja la instalación segura. También advierte contra RLIMIT_AS y RLIMIT_DATA, que pueden activar la ruta vulnerable.
PHP 8.1 y anteriores ya no reciben actualizaciones upstream, así que quienes estén en esas ramas dependen de un backport de su distribución. Las distribuciones de Linux y los proveedores con soporte de larga duración recibieron parches por adelantado. PHP 8.2 llega al final de su vida el 31 de diciembre de 2026.
Cloudflare cita a W3Techs para la cifra de que PHP funciona en casi el 70% de los sitios web. El número a vigilar en la próxima quincena no es la puntuación de severidad, sino la tasa de parcheo en el alojamiento compartido, donde quien aplica la corrección rara vez es quien posee el sitio.
