Infierno en un PHP2Shell: cómo la IA ha reducido la ventana de parcheo de días a horas

¿Qué tiene esta época del año que propicia un incidente cibernético generalizado e insidioso justo antes de las fiestas? Justo cuando los profesionales de la seguridad habían dejado de tener pesadillas con Log4J/Log4Shell, surge una serie de fallos críticos en PHP que están causando una interrupción masiva.

El 21 de octubre, cientos de sitios web fueron desconectados, no por atacantes con exploits, sino de forma proactiva por gobiernos, empresas y organizaciones para evitar que esos sitios fueran explotados mientras sus equipos técnicos revisaban y aplicaban parches. La causa fueron dos fallos críticos en PHP, el lenguaje que sustenta aproximadamente el 70% de los sitios web. Conocidos conjuntamente como PHP2Shell, CVE-2026-109618 y CVE-2026-109619 podrían permitir que un atacante no autenticado logre la ejecución remota de código (RCE) en un servidor bajo las condiciones adecuadas.

Los errores en sí se encuentran en el lenguaje C subyacente de PHP y, aunque es fascinante profundizar en los detalles técnicos de este incidente, la historia más importante aquí es que este error de falta de memoria (OOM) no es nuevo: se planteó por primera vez en 2004, luego nuevamente en 2019 y otra vez en 2024. Y la historia más relevante es, posiblemente, por qué en el verano de 2026, después de no haber sido priorizado durante 12 años, este mismo error OOM se convierte de repente en la máxima prioridad para todo el equipo de seguridad de la PHP Foundation.

Entonces, ¿qué pasó? Pasó la IA.

La IA ha reducido el tiempo entre el descubrimiento de un error y su explotación

Estos errores no son triviales de explotar. Encadenar estos fallos en un vector de ataque funcional requiere una comprensión profunda de cómo PHP asigna y reutiliza la memoria entre solicitudes. Los investigadores de seguridad experimentados saben que, a menudo, la parte más difícil del trabajo es demostrar el impacto: un error al que no se puede acceder no puede ser explotado, y un error que no puede ser explotado no genera la urgencia necesaria para que se aplique una solución, en un mundo donde los equipos técnicos tienen recursos limitados y listas de tareas pendientes que ya son demasiado largas.

Estos errores permanecieron sin resolver durante tanto tiempo porque nadie pudo averiguar cómo explotarlos. Y debido a que la solución era compleja y requería concesiones importantes entre la compatibilidad con versiones anteriores, el potencial de denegación de servicio (DoS) y cambios en extensiones de terceros imposibles de coordinar, los esfuerzos para corregir el error en 2024 se estancaron. Este escenario les resultará familiar a cualquier equipo que clasifique hallazgos de seguridad: un problema teórico con una solución costosa tiende a perder frente a problemas con un impacto claro y probado.

Hasta este verano, cuando el proyecto PHP fue añadido al programa Patch the Planet de OpenAI. Las nuevas rondas de auditorías de seguridad asistidas por IA en PHP no solo expusieron los errores, sino que también crearon las pruebas de concepto (PoC) de explotación necesarias para que las correcciones fueran priorizadas. La cronología de Calif muestra menos de 2 semanas desde que encontraron una ruta hacia el error hasta que entregaron una prueba de concepto (PoC) funcional a la PHP Foundation. Y en su informe, Wiz destaca explícitamente lo que marcó la diferencia: "con modelos de IA de vanguardia y las herramientas adecuadas, un solo investigador completó en una semana lo que anteriormente le habría tomado meses de trabajo a un equipo de clase mundial."

En pocas palabras, así es como se ve esta vulnerabilidad

Cuando una solicitud de PHP se queda sin memoria, PHP detiene la solicitud inmediatamente. Esta interrupción abrupta significa que se omite un paso de limpieza de memoria, lo que crea una vulnerabilidad de corrupción de memoria de tipo Use After Free. En el momento menos oportuno, PHP podría dejar datos internos parcialmente inicializados y tratarlos posteriormente como válidos, corrompiendo la memoria o dejando un estado interno que apunta a la memoria de una solicitud anterior.

Convertir estos dos errores en un ataque funcional fue complejo. Requirió:

• Forzar un error de falta de memoria en un punto exacto, utilizando una solicitud pequeña con campos de formulario profundamente anidados que hace que PHP asigne mucha más memoria que el tamaño de la solicitud (Calif)
• Hacer que los datos controlados por el atacante aterricen en la memoria liberada, para que PHP los lea como sus propias estructuras internas (Calif)
• En algunas cadenas, utilizar un segundo fallo para filtrar el contenido de la memoria y determinar dónde están las cosas, lo que derrota la aleatorización de direcciones (Wiz)

Si quieres entender los detalles técnicos de este exploit, visita nuestro tutorial público sobre PHP2Shell que explica paso a paso cómo funciona: [REPRODUCIR AHORA]

Un mundo nuevo: observar intentos de explotación en tiempo real

Ojalá solo fueran los investigadores de seguridad y los equipos técnicos los que recibieran ayuda de la IA. El incidente de PHP2Shell es la primera vez que podemos ver realmente el cambio radical en la rapidez con la que los atacantes pueden convertir las divulgaciones y los parches en exploits. Debido a que organizaciones como AWS y Cloudflare fueron informadas con antelación, pudieron vigilar los intentos de explotación en la naturaleza en toda su base de clientes. Y dado que se estima que PHP se utiliza en el 70% de los sitios web, la superficie de ataque de PHP2Shell es enorme.

• Cloudflare detectó miles de intentos de explotar PHP2Shell en las 10 horas previas a su anuncio público. Menos de 24 horas después del anuncio, estaban rastreando millones de intentos de explotación.
• Amazon Threat Intelligence identificó un intento de explotación de PHP2Shell que se remonta al 17 de octubre, cuatro días antes de la divulgación pública. A las pocas horas de la publicación del parche, AWS confirmó haber visto "intentos de explotación generalizados en la naturaleza".

Esto indica que los equipos ya no pueden contar con plazos de parcheo y mitigación de 30 días, ni siquiera de 7 días. Para las vulnerabilidades críticas, el uso de la IA ha reducido esos plazos a horas.

Las conclusiones

Para los equipos técnicos y de seguridad, es necesario revisar dos suposiciones.

En primer lugar, la frase "sin exploits conocidos" ya no ofrece la misma tranquilidad que antes, ya que las herramientas de IA han reducido drásticamente el coste de crearlos. Los hallazgos antiguos considerados teóricos merecen una revisión. El código es barato, y eso hace que los exploits también lo sean.

En segundo lugar, una solución que tarda semanas en implementarse compite ahora con ataques que se ejecutan en horas, lo que altera el cálculo del retorno de inversión. La prevención proactiva se está convirtiendo rápidamente en la mejor forma de mitigar riesgos. Si su equipo utiliza aplicaciones con versiones antiguas de PHP sin parches, podría enfrentarse a serios problemas al intentar actualizar. Su deuda técnica se ha convertido en un problema de seguridad crítico, y debemos esperar que esta tendencia continúe a medida que los atacantes que utilizan IA sean más capaces. Dado que PHP es la base de gran parte de la infraestructura de servidores de internet, el despliegue de parches será una tarea titánica. Si a esto sumamos que no solo las aplicaciones web están afectadas (lo que significa que dispositivos y prácticamente cualquier sistema o producto conectado a internet podría verse involucrado), esto tiene todas las características de ser un dolor de cabeza constante para el personal de seguridad. Es imperativo que los equipos estén alerta y preparados no solo para gestionar exploits críticos conocidos, sino para actuar con una mentalidad de seguridad desde el diseño en todos los aspectos de la creación de software, ya sea humano o generado por IA. [JUGAR EL DESAFÍO] [HABLAR CON UN EXPERTO]