technology 8 min de lectura

Armagedón del PHP: Lo que significa la caza de errores de IA para

Los agentes de IA de OpenAI y Google Wiz descubrieron dos vulnerabilidades críticas de PHP de décadas atrás que afectan a 33 millones de sitios web. El hallazgo marca un hito en la investigación de seguridad asistida por IA y advierte sobre la doble cara de la explotación automatizada.

  • Noam Shazeer
  • infraestructura crítica
  • UAT-10147
  • ejecución remota de código
  • PHP
  • Google Wiz

Internet acaba de recibir un recordatorio de que su columna vertebral es ancestral.

Se descubrieron y parchearon dos vulnerabilidades críticas en PHP —el lenguaje de programación del lado del servidor que sustenta aproximadamente el 70 % de los sitios web, o más de 33 millones de propiedades—, no gracias a un equipo de investigadores humanos de seguridad trabajando de forma aislada, sino a agentes de IA de OpenAI y Wiz de Google. La Agencia de Seguridad Nacional de EE. UU. respondió con una orientación inusualmente directa: si no puede parchear de inmediato, saque el sitio fuera de línea.

La verdadera historia aquí no son los errores en sí mismos. Es lo que significa su descubrimiento para la forma en que se protegerá —o dejará de protegerse— la internet en el futuro. Este momento marca un cambio tectónico en la relación entre la IA y la ciberseguridad, uno que resonará a través de cada capa de la pila de infraestructura web durante los próximos años.

Décadas de óxido, encontradas en días

PHP 5 se lanzó en 2004. Estas dos fallas vivieron dentro de cada versión desde entonces, ocultas en rutas de código que tocan billones de líneas de software pero que pocos seres humanos tienen razón para examinar de cerca. Permiten que un atacante se infiltre en el sistema de archivos de un servidor o en una base de datos de la que depende una aplicación web. Eso es tan malo como puede llegar a ser.

Los parches ya están disponibles. PHP 8.5.12 es la versión recomendada actualmente. Pero la realidad en el terreno es más caótica: los sitios que aún ejecutan PHP 8.1 y versiones anteriores se encuentran en lanzamientos sin soporte. No hay forma de saber con precisión cuántos de esos 33 millones de sitios web siguen funcionando sobre versiones vulnerables. La estimación de la propia Fundación PHP sugiere que decenas de millones podrían necesitar atención urgente.

La NSA no anduvo con rodeos sobre el nivel de riesgo. Su recomendación de desconectar los sitios sin parches es severa para un lenguaje tan profundamente arraigado en la pila web. Pero la urgencia de la agencia también revela algo incómodo: a pesar de décadas de escaneo automatizado de seguridad, estas vulnerabilidades se ocultaron a plena vista durante casi veinte años. Los auditores humanos las pasaron por alto. Las herramientas de análisis estático las pasaron por alto. Se necesitaba un agente de IA —un sistema diseñado para razonar a través del código a escala— para encontrar lo que generaciones de investigadores de seguridad no pudieron.

La IA encontró los errores. La IA también reducirá la barrera para explotarlos.

Aquí es donde la historia se complica.

Calif, una empresa de pruebas de seguridad, estaba trabajando dentro de la iniciativa “Patch the Planet” de OpenAI para encontrar fallas en software de código abierto cuando utilizó GPT-5.6 Sol para descubrir una de las vulnerabilidades. Independientemente, Wiz desplegó su agente de seguridad Wiz Atlas ejecutando Gemini 4 Argon y GPT-5.6 Sol para encontrar múltiples fallas en PHP. Ambos equipos siguieron prácticas de divulgación responsable, trabajando con la Fundación PHP en los parches antes de hacerlos públicos.

OpenAI confirmó que las fallas fueron encontradas por investigadores antes de que aparecieran explotaciones conocidas en la naturaleza. Esa es la buena noticia. La mala noticia es lo que Wiz escribió en su propio blog sobre los descubrimientos: antes de la IA, estas fallas eran demasiado difíciles para que los hackers las explotaran. “Los LLM pueden ayudar a adaptar un exploit a diferentes versiones de PHP, configuraciones y disposiciones de memoria”, advirtió Wiz.

En otras palabras, la IA es simultáneamente la herramienta de descubrimiento y el habilitador. Encontró las vulnerabilidades primero, que es exactamente cómo debería funcionar esto. Pero también reduce el umbral de habilidad para convertir una falla divulgada en un ataque funcional. La carrera ya no es entre investigadores humanos y hackers humanos. Es entre defensores asistidos por IA y atacantes asistidos por IA —y los defensores están comenzando una campaña de parcheo contra decenas de millones de sitios que nunca fueron diseñados para parchearse rápidamente.

Esta dinámica de doble uso definirá la próxima era de la ciberseguridad. Cada sistema de IA que descubra vulnerabilidades más rápido también acelerará la creación de exploits weaponizados. El tiempo entre el descubrimiento y la explotación se reduce hacia cero, y las organizaciones que dependen de infraestructura heredada cargarán con el peso de esa compresión.

La cadena de suministro de la que nadie habla

La mayor parte de la discusión pública sobre el riesgo de la cadena de suministro de software se centra en las dependencias —un paquete malicioso en npm, una tubería de construcción comprometida, una biblioteca envenenada—. Las vulnerabilidades de PHP pertenecen a una categoría diferente de riesgo. Se ubican en la capa de infraestructura, debajo de las aplicaciones y frameworks construidos sobre ellas.

La lista de empresas que Wiz agradeció por su ayuda —Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft, Vercel— lee como un directorio de quién es quién en la pila de infraestructura web. WordPress emitió específicamente un comunicado indicando que las fallas no son específicas de WordPress. Los sitios que ejecutan WordPress deben parchear sus servidores y coordinarse con sus proveedores de alojamiento. Ese es el quid de la cuestión: la mayoría de los sitios de WordPress no se ejecutan en servidores que sus propietarios controlan directamente.

Esto crea una cadena de dependencias que se extiende desde la Fundación PHP hasta las empresas de alojamiento, los operadores de sitios y los usuarios finales. Cuando surge un error como este, las personas que pueden solucionarlo suelen ser las menos visibles en la cadena. Las pequeñas empresas, las ONG y los bloggers individuales que ejecutan versiones obsoletas de PHP en planes de alojamiento compartido son el flanco blando aquí.

Los efectos de segunda orden de este problema de dependencia ya son visibles. Los proveedores de alojamiento compartido se preparan para una ola de tickets de soporte. Los equipos de TI empresariales están descubriendo que sus aplicaciones heredadas de intranet dependen de versiones de PHP que han alcanzado el fin de vida. Los gobiernos municipales y las instituciones públicas, que a menudo funcionan con sistemas de gestión de contenido desactualizados, enfrentan el mismo dilema que las pequeñas empresas: no pueden simplemente actualizar software que ha sido estable durante años, incluso si esa estabilidad ahora conlleva un riesgo inaceptable.

La economía del código olvidado

También existe una dimensión económica en esta crisis que se extiende mucho más allá de la seguridad. Se estima que entre el 60 y el 70 por ciento de los sitios web aún se ejecutan en PHP, y una proporción significativa de ellos está en versiones que ya no reciben actualizaciones de seguridad. El costo de actualizar —no solo técnicamente, sino organizativamente— es prohibitivo para muchos operadores. Migrar de una versión antigua de PHP a menudo requiere reescribir el código de la aplicación, realizar pruebas contra nuevo comportamiento y capacitar al personal. Para un pequeño restaurante con un sitio de WordPress de treinta páginas que ejecuta PHP 7.4, esa migración no es un proyecto de fin de semana. Es una decisión presupuestaria.

Los proveedores de alojamiento quedan atrapados en el medio. Muchos planes de alojamiento compartido aún tienen por defecto PHP 8.0 o 8.1, versiones que han superado sus fechas de fin de vida. Actualizar los valores predeterminados a través de millones de cuentas es operativamente complejo y financieramente riesgoso: un cambio que rompe algo en el sitio de un cliente puede desencadenar una ola de cancelaciones. Algunos proveedores están avanzando agresivamente. Otros están esperando, calculando la probabilidad de un ataque real frente a la probabilidad de insatisfacción del cliente con migraciones forzadas.

La directiva de la NSA de sacar los sitios vulnerables fuera de línea exacerba la tensión. Para una pequeña empresa, desconectarse significa perder ingresos. Para un hospital o un servicio de emergencia, significa poner en riesgo la seguridad de los pacientes. La política es técnicamente sólida pero socialmente costosa, y esa brecha entre la corrección técnica y la viabilidad práctica se ampliará a medida que el descubrimiento impulsado por IA haga que la divulgación de vulnerabilidades sea más frecuente.

Qué sucede a continuación

El impacto inmediato será ruidoso. Los equipos de seguridad se agitarán. Los proveedores de alojamiento responderán tickets de soporte. Algunos sitios saldrán fuera de línea a medida que los operadores sigan el consejo conservador de la NSA. La carrera de parcheo revelará cuánto de internet se ejecuta sobre software que no ha sido actualizado en años.

Pero la implicación a largo plazo es más significativa. El descubrimiento de vulnerabilidades impulsado por IA ya no es teórico. Ocurrió con dos fallas importantes en uno de los lenguajes más ampliamente desplegados de internet, en un esfuerzo coordinado que habría sido casi imposible a esta velocidad y escala sin modelos de lenguaje grandes haciendo el trabajo pesado de análisis de código.

Esto se volverá rutinario. Los equipos de seguridad en empresas como Calif y Wiz ahora tienen un manual. OpenAI tiene una iniciativa dedicada a ello. La pregunta es si el ritmo del descubrimiento por IA superará al ritmo de la explotación habilitada por IA, o si estamos entrando en una era donde los errores más peligrosos son los encontrados primero por máquinas —y luego, casi inmediatamente, weaponizados por otras máquinas.

El apocalipsis de PHP evitado hoy es una señal, no un final. La infraestructura más antigua de internet acaba de recibir una llamada de atención, y la alarma fue tocada por la IA. Las máquinas que encontraron estas fallas encontrarán más. La pregunta es si la humanidad podrá construir el andamiaje institucional y económico lo suficientemente rápido para mantener los sitios funcionando cuando eso ocurra.