El 21 de octubre, PHP publicó actualizaciones para dos vulnerabilidades críticas que, bajo ciertas condiciones, permiten ejecutar código sin autenticarse. Los fallos están en el propio motor de PHP, así que mantener WordPress o Drupal al día no sustituye a actualizar el intérprete que los ejecuta.
La noticia reúne dos cosas que conviene tratar por separado: una emergencia de actualización para quienes administran servidores y un caso concreto de investigación de seguridad asistida por IA. La conversación previa a la publicación de parches alcanzaba 304 puntos y 62 comentarios en Hacker News al consultarla el 26 de octubre. Es una señal de interés de esa comunidad, no una medida de impacto global.
Qué falla en PHP
Las vulnerabilidades son CVE-2026-109618 y CVE-2026-109619. Según CERT-EU, la primera afecta a cómo PHP limpia datos internos cuando una petición alcanza el límite de memoria en un momento concreto. La segunda implica estado interno que puede sobrevivir a una petición después de liberar la memoria asociada. En ambos casos, una gestión incorrecta de memoria puede abrir una vía hacia la ejecución remota de código.
No significa que cualquier petición comprometa automáticamente cualquier servidor: la explotación depende de condiciones concretas. Pero sí es un problema del motor, anterior incluso al código de la aplicación en una vía demostrada. CERT-EU incluye entre los entornos expuestos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Wiz indica que comprobó la explotación contra instalaciones de WordPress y Drupal.
Qué papel tuvo la IA
No fue una IA trabajando sola y avisando a todo internet. OpenAI explica que Calif identificó un fallo usando GPT-5.6 Sol y que Wiz descubrió y comunicó ambos de forma independiente. Wiz atribuye su investigación a su equipo y a herramientas de IA, incluidos Gemini 4 Argon y GPT-5.6 Sol. Los responsables de PHP dirigieron las correcciones y su publicación.
El matiz importa: los modelos participaron en una investigación con personas, herramientas y coordinación entre equipos. Es una muestra útil de lo que pueden aportar al analizar código complejo, pero no demuestra que la revisión humana ni la divulgación coordinada hayan dejado de ser necesarias.
Versiones corregidas
PHP publicó correcciones en 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si usas una distribución Linux o un proveedor con soporte, comprueba su aviso: puede aplicar el parche a una versión de paquete con numeración diferente. Para PHP 8.1 y anteriores, consulta a tu proveedor de soporte o planifica la migración; el proyecto PHP ya no mantiene esas ramas de forma ordinaria. CERT-EU recoge también la existencia de algunos parches retrospectivos.
La versión mostrada por php -v corresponde al ejecutable de línea de comandos. Puede ser distinta de la que atiende la web. Revisa también PHP-FPM, Apache, los contenedores y cualquier imagen que incluya PHP. En Docker, actualizar el host no actualiza por sí solo el PHP que hay dentro de una imagen: hay que obtener una imagen corregida y recrear el servicio siguiendo el procedimiento del proyecto.
Una vez actualizado, comprueba la versión del servicio que procesa las peticiones y que la aplicación sigue respondiendo. Si tienes varias webs o contenedores, haz inventario de todos: corregir uno no modifica los demás.
Si no puedes actualizar
La recomendación de CERT-EU es actualizar cuanto antes y, si no es posible, considerar aislar de internet las aplicaciones afectadas hasta aplicar y verificar la corrección. Un WAF o una configuración temporal puede reducir exposición a rutas conocidas, pero no equivale a un parche completo. El equipo de PHP también advierte de que no hay mitigaciones completas para estos dos fallos.
El mismo aviso de CERT-EU recoge una tercera vulnerabilidad divulgada el 23 de octubre, distinta de las dos anteriores y ligada a una configuración poco habitual. Si administras PHP, revisa el aviso actualizado y las indicaciones de tu proveedor, en lugar de asumir que los dos números de versión resuelven cualquier problema posterior.
La parte menos llamativa
El uso de IA hace interesante la historia, pero la tarea inmediata sigue siendo bastante terrenal: saber dónde se ejecuta PHP, quién distribuye sus parches y cómo desplegarlos. Un inventario actualizado y una forma fiable de reconstruir contenedores valen más en una emergencia que descubrir que el PHP de producción lleva años sin dueño.