La IA halló dos fallas críticas en PHP antes que los atacantes. Ahora la ventana depende de sus parches

La frase más importante del aviso de seguridad de PHP de esta semana es una sola: no hay mitigaciones completas, y actualizar es la única opción segura.

El 21 de octubre, el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, con una puntuación de 9,2 en CVSS v4.0. En las condiciones adecuadas, ambas permiten que un atacante sin autenticar ejecute código en el servidor. Están en el propio runtime de PHP, así que alcanzan a toda aplicación construida sobre él: sitios en WordPress, Drupal y Joomla, herramientas internas, portales de clientes y el PHP que corre dentro de productos de proveedores que nadie recuerda haber comprado.

Se encontraron con IA de frontera. Esa es la parte de la historia que se va a repetir.

Qué ocurrió

Las dos fallas se activan cuando una petición hace que PHP falle a mitad de camino, por ejemplo al alcanzar su límite de memoria o provocar un error fatal, y dependen de que una petición posterior reutilice el mismo worker. PHP indica que toda instalación que atiende peticiones web está en riesgo, incluidos PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed, con el mayor riesgo en mod_php. Wiz, que publicó su investigación el mismo día, afirma que casi todas las versiones desde PHP 5.4 tienen al menos uno de los problemas y describe cadenas de explotación sin autenticación contra WordPress, Drupal y Joomla.

En el hallazgo participaron varios actores. Según la PHP Foundation, Calif, una firma de seguridad que trabaja en el programa Patch the Planet de OpenAI, reportó la causa raíz el 11 de agosto usando GPT-5.6 Sol, y OpenAI y Wiz reportaron otras vías de ataque en las semanas siguientes. Wiz dice que encontró ambas fallas de forma independiente, con su agente Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol. La Foundation también escribe, con una franqueza poco habitual, que la causa raíz ya había aparecido en una auditoría de 2024 y que la corrección estuvo “detenida durante meses” por “una falla estructural” en su toma de decisiones y sus recursos.

La ventana fue más corta de lo previsto

OpenAI presenta el caso como una IA de frontera que encontró las fallas antes que los atacantes y abrió lo que llama una ventana para los defensores. La ventana existió, y se cerró antes de tiempo:

• Los detalles empezaron a filtrarse hacia las 15:00 UTC del 20 de octubre, según la Foundation, que adelantó la publicación un día, a las 14:00 UTC del 21 de octubre.
• Un proveedor de imágenes de contenedores publicó imágenes con la corrección más de seis horas antes del lanzamiento coordinado, lo que entregó el parche a los atacantes en formato binario.
• Cloudflare, que desplegó reglas de web application firewall unas nueve horas antes de la divulgación, dice que después observó tráfico de ataque contra sus clientes, con payloads modificados para evadir las reglas.

La Foundation no tenía constancia de exploits funcionales en el momento de la publicación, y OpenAI dice no saber de ningún atacante que hallara las fallas antes. Ambas afirmaciones eran ciertas cuando se hicieron. Ninguna es motivo para esperar. La evaluación de Wiz es la que debe guiar el plan: estas cadenas de explotación son complejas, y los modelos de frontera “redujeron sustancialmente esa barrera”.

Qué no cuenta como corrección

Actualizar WordPress o sus plugins. La falla está por debajo de la aplicación. Cloudflare es explícita: actualizar el código del sitio o los plugins no la corrige. Si un proveedor de hosting gestiona PHP, es el proveedor quien tiene que actualizar el runtime.

Una regla de WAF. Las reglas de firewall de Cloudflare y otros ganan tiempo, y los atacantes ya trabajan para eludirlas. PHP enumera cambios de configuración provisionales para quien no pueda actualizar de inmediato, y aclara que reducen la exposición sin hacer segura la instalación.

Una versión sin soporte. PHP 8.1 y anteriores no reciben correcciones oficiales. El equipo de seguridad de PHP publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1, para quien compila desde el código fuente, y algunas distribuciones Linux aplican backports, pero la respuesta por defecto para esos sistemas es migrar de versión. PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026.

Qué hacer hoy

1. Encuentre cada runtime de PHP, no cada sitio web. El inventario que importa es el de runtimes: servidores, contenedores, imágenes base, plataformas alojadas y appliances. Los sitios de marketing y las intranets antiguas son los puntos ciegos habituales.
2. Actualice primero lo expuesto a internet. Priorice por exposición y, después, por lo que el sistema alcanza si se ve comprometido.
3. Reconstruya las imágenes, no solo los hosts. Un contenedor generado el mes pasado a partir de una imagen base sin corregir sigue siendo vulnerable después de actualizar el host.
4. Pida confirmación por escrito a sus proveedores. Empresas de hosting, proveedores de SaaS y fabricantes de appliances que ejecutan PHP deben confirmar qué versión usan ahora y cuándo actualizaron.
5. Busque señales de intentos. Wiz menciona peticiones multipart inusuales seguidas de errores de límite de memoria, respuestas HTTP 500 repetidas, cookies PHPSESSID malformadas y reinicios de workers sin explicación. Los logs de la aplicación pueden mostrar poco, porque las fallas operan por debajo de ella.

OpenAI publicó un verificador de versiones de PHP como una skill de Codex para ayudar a identificar versiones expuestas. Es una comodidad. La lista oficial de versiones corregidas es la de PHP.

Por qué volverá a ocurrir

OpenAI escribe que estas fallas “están entre varias vulnerabilidades significativas que ya hemos encontrado y estamos trabajando para corregir”, y que espera que hallazgos similares “aumenten de forma pronunciada en los próximos meses”. Tómelo al pie de la letra. Cuando la IA abarata encontrar y explotar fallas en código antiguo y muy extendido, el cuello de botella pasa al lado de los defensores: los mantenedores voluntarios, como muestra el propio relato de PHP, y el proceso de parches de cada organización.

Hemos sostenido que la capacidad de verificación, y no la de generación, marca el ritmo de la IA en producción. La seguridad tiene ahora la misma forma: el descubrimiento se acelera, y el paso lento es confirmar, corregir y desplegar. Y los procesos de parches pensados para ciclos mensuales son un ejemplo más de sistemas dimensionados para el ritmo humano. La pregunta para cualquier responsable de seguridad después de esta semana no es si su equipo puede actualizar PHP. Es cuántos días tarda el próximo parche de emergencia de un runtime fundamental, de principio a fin, y quién es responsable de reducir esa cifra.