El 21 de octubre, PHP publicó de una sola vez cuatro versiones de seguridad: 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación de 9.2 en CVSS v4.0. Un atacante remoto sin autenticar puede aprovecharlas, y el peor desenlace es la ejecución remota de código. En su aviso, el proyecto afirma que no existe una mitigación temporal completa; actualizar es la única solución definitiva.
Quien descubrió este conjunto de fallos fue la empresa de seguridad en la nube Wiz, que bautizó el incidente como PHP2Shell. Durante la búsqueda, el equipo de investigación de Wiz utilizó su propia herramienta Wiz Atlas, además de Gemini 4 Argon de Google y GPT-5.6 Sol de OpenAI.
El problema está en el propio motor
Detrás de los dos CVE hay cuatro defectos en total: un use-after-free en el deserializador del progreso de subida, la lectura remota de la memoria del proceso, un use-after-free en el backtrace de errores fatales y una confusión de tipos (type confusion) en OPcache. La raíz común está en cómo PHP gestiona los errores fatales, sobre todo los causados por agotamiento de memoria.
Cuando una solicitud termina de forma anómala, quedan datos corruptos en el estado interno; el mismo proceso worker, al atender la siguiente solicitud, reutiliza ese estado obsoleto, lo que provoca fugas o corrupción de memoria. Incluso sin ejecutar código, el atacante puede leer contraseñas, tokens y claves de API de la memoria del proceso.
El fallo está en el motor de PHP y no tiene que ver con lo seguro que esté escrita la aplicación que corre encima. Wiz demostró la explotación en las imágenes de contenedor más recientes de WordPress, Drupal y Joomla; incluso una página que solo muestra Hello World puede verse afectada, y la fuga de memoria se produce aunque la aplicación nunca haya llamado a session_start(). El alcance se remonta hasta PHP 5.4: todas las versiones publicadas en la última década caen en al menos uno de los problemas.
En qué parte ayudó la IA
La cronología de Wiz: el primer fallo se descubrió el 19 de agosto, se comunicó al equipo de seguridad de PHP el 24 de agosto, PHP lo confirmó el 21 de septiembre y empezó a preparar la corrección coordinada, y se hizo público el 21 de octubre. Desde el informe hasta la publicación del parche pasaron casi dos meses, la mayor parte dedicados a la corrección y la coordinación.
Según Wiz, Argon participó en el descubrimiento de fallos, la escritura de exploits, la detección de ataques y la verificación de parches; los grandes modelos ayudaron a los investigadores a adaptar el código de explotación a distintas versiones de PHP, configuraciones y distribuciones de memoria y, cuando fallaba, analizaban la causa e iteraban. En palabras de Wiz:
"Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."
(Los modelos de frontera redujeron sustancialmente esa barrera y convirtieron un fallo antiguo en un exploit funcional.)
Wiz afirma que un solo investigador completó en una semana lo que antes llevaba meses a los mejores equipos. OpenAI también publicó un texto sobre esta divulgación coordinada; según informaciones públicas, además lanzó una habilidad de Codex para que los sitios comprueben si están afectados, aunque por ahora no es posible verificar uno por uno los escenarios que cubre.
El problema de los sitios antiguos en China
Un gran número de sitios web pequeños y medianos, webs corporativas y foros en China funcionan con PHP, a menudo en entornos instalados con un clic desde paneles de alojamiento, y no es raro que la versión se haya quedado en la 7.x. Según la lista oficial de versiones, los parches de esta vez solo cubren cuatro ramas, de la 8.2 a la 8.5; la 7.x hace tiempo que dejó de recibir soporte y no obtiene corrección oficial, y la 8.2 solo se mantiene hasta el 31 de diciembre de este año.
Para los sitios que aún no han actualizado, Wiz enumera varias señales de comprobación: solicitudes multipart anómalas seguidas de un error por exceso de memoria, HTTP 500 recurrentes, cookies PHPSESSID inusualmente grandes o con formato corrupto y reinicios anómalos y frecuentes de los procesos worker de PHP. Cloudflare, Fastly, Google y otros proveedores ya han desplegado reglas de protección, por lo que los sitios detrás de una CDN pueden bloquear parte de los ataques, pero la conclusión oficial no cambia: el asunto solo queda resuelto cuando se aplica el parche.
Fuentes: aviso de seguridad oficial de PHP, blog de investigación de Wiz, CocoLoop, aviso de seguridad de OpenAI; se verificaron los números de las versiones corregidas, los identificadores CVE, las puntuaciones CVSS v4.0 y el alcance de las versiones afectadas.