Tabla de contenidos

Hace unos días, el 40 % de Internet estuvo al borde del colapso

La gestión de las vulnerabilidades php2shell ha puesto patas arriba el ecosistema de la ciberseguridad global.

Lo ocurrido no solo ha expuesto a más del 70 % de las páginas web del mundo a un riesgo inminente de Ejecución Remota de Código (RCE), sino que ha puesto de manifiesto la grave fragilidad de una infraestructura digital envejecida y la ruptura del modelo tradicional de divulgación de fallos críticos.

La raíz del problema: una infraestructura que envejece

La infraestructura que sostiene Internet lleva décadas en funcionamiento. Que un sistema como PHP lleve años funcionando correctamente no garantiza que sea seguro.

La necesidad de mantener la compatibilidad con aplicaciones, bibliotecas y extensiones antiguas hace que corregir un fallo en el código sea un proceso lento y complejo: tocar una línea de código antigua puede romper miles de aplicaciones que dependen de ella.

De hecho, la Fundación PHP ya había identificado en 2024 una de las fallas de esta crisis durante una revisión rutinaria, pero en su momento no se halló una vía de explotación conocida y su corrección se postergó debido a su enorme complejidad.

Lo que nadie anticipó es que la llegada de los modelos de inteligencia artificial de frontera iba a acelerar drásticamente este envejecimiento, convirtiendo fallos «dormidos» en amenazas mortales en cuestión de horas.

Cronología de un caos anunciado

El modelo de divulgación coordinada existe por una razón fundamental: dar tiempo a los mantenedores de software libre para validar hallazgos, preparar correcciones y distribuir parches antes de que los detalles técnicos permitan a cualquiera intentar explotar el fallo. Con php2shell, las reglas volaron por los aires.

  • 20 de octubre: Un post en Hacker News filtró la próxima divulgación de las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, rompiendo el embargo tradicional. De inmediato, las pruebas de concepto (PoC) comenzaron a circular públicamente antes de que el equipo de PHP pudiera validar el impacto real o preparar las correcciones.
  • 20 de octubre (12:30 UTC): Apenas unas horas después de la filtración, Amazon Threat Intelligence detectó los primeros intentos automatizados de explotación activa en su telemetría de MadPot.
  • 20 de octubre (15:00 UTC): Bajo una presión sin precedentes, la Fundación PHP se vio obligada a publicar un aviso extraordinario (advance notice) anunciando la llegada de actualizaciones de seguridad de emergencia.
  • 21 de octubre: Se lanzaron a toda prisa las versiones corregidas de PHP: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

El papel de la IA y OpenAI: ¿Solución o parte del problema?

La inteligencia artificial ha demostrado ser una herramienta de doble filo. Por un lado, empresas como Google Cloud o firmas de ciberseguridad usan modelos de IA para revisar grandes volúmenes de código, detectar patrones complejos de memoria e incluso generar parches. Por otro lado, esa misma capacidad de procesamiento ha destruido el margen de reacción de los humanos.

OpenAI afirmó que su iniciativa Patch the Planet permitió descubrir estas vulnerabilidades ocultas durante una década en el código de PHP.

Sin embargo, el 21 de octubre, en pleno pico de crisis y mientras los administradores de sistemas intentaban contener los ataques, OpenAI publicó su propuesta para un nuevo marco de coordinación de vulnerabilidades críticas.

Este movimiento generó un fuerte rechazo en la comunidad técnica: presentar una propuesta de autorregulación a posteriori, tras haber colapsado el proceso coordinado previo y sin haber evitado la filtración del embargo, debilita drásticamente la credibilidad de cualquier nuevo esquema promovido por la industria de la IA.

El cuello de botella humano frente al ritmo de la IA

La acumulación de fallos críticos en las últimas semanas —sumada a incidentes como el Linux PwnEscape o vulnerabilidades RCE 10/10 en GitLab— evidencia el problema estructural de fondo: la IA detecta vulnerabilidades a la velocidad de la luz, pero la respuesta y corrección dependen de recursos humanos limitados.

Actualizar sistemas en grandes empresas no es tan simple como presionar un botón; requiere migrar dependencias obsoletas y auditar código heredado.

Cuando la capacidad de análisis de la IA supera por completo la velocidad de parcheado de los equipos informáticos, la deuda técnica deja de ser un problema de rendimiento para convertirse en una amenaza directa a la supervivencia del servicio.

Preguntas frecuentes

¿Por qué la IA acelera el riesgo en el software antiguo?

Porque permite a analistas y ciberdelincuentes auditar millones de líneas de código en minutos y hallar vectores de ataque en fallos de gestión de memoria que a los humanos les tomaba años descubrir.

¿Por qué fue tan grave la ruptura del embargo en este caso?

Porque dejó al descubierto a más de 1,3 millones de servidores expuestos antes de que los mantenedores de PHP tuvieran listas las versiones corregidas.

¿Qué deben hacer las organizaciones frente a esta nueva dinámica?

Eliminar la deuda técnica, migrar de versiones obsoletas (EOL) y asumir que el tiempo de reacción entre el hallazgo de una falla y su explotación activa se ha reducido prácticamente a cero.