php2shell: la IA no encontró el fallo sola

El 21 de octubre PHP publicó parches de emergencia para php2shell, dos fallos que permiten ejecutar código en un servidor web sin autenticarse. Casi todos los titulares lo resumieron igual: la IA ha encontrado un bug que pone en riesgo al 70 % de la web.

Es cierto, pero es la parte menos interesante. Si se leen los informes de quienes lo descubrieron, la historia es otra: un fallo con raíces en 2004 avisado varias veces y un investigador que sabía exactamente qué preguntarle al modelo.

Qué es php2shell y por qué es tan grave

php2shell agrupa dos vulnerabilidades del núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS v4.0 de 9,2. Permiten a un atacante sin credenciales ejecutar código en el servidor o leer memoria del proceso, donde puede haber contraseñas, tokens o claves de API.

Lo excepcional es dónde están: en el propio intérprete, no en la aplicación. Da igual que un WordPress, un Drupal o un simple “Hola, mundo” estén bien escritos. Afecta a cualquier instalación que sirva peticiones web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed), con versiones vulnerables desde PHP 5.4.

La causa en una frase es cuando PHP se queda sin memoria u otro error fatal interrumpe su código nativo, abandona la operación a medias sin limpiar. Queda un estado interno que apunta a memoria ya liberada y la siguiente petición que atiende ese mismo proceso lo reutiliza.

La reacción da la medida del problema. Países como Finlandia, Países Bajos, Francia y Canadá desconectaron webs gubernamentales de forma preventiva el día del parche.

Una historia de 22 años

El fallo no salió de la nada. Calif lo cuenta como una genealogía y es lo más valioso de su informe.

2004. Stefan Esser, entonces la referencia en seguridad de PHP, publica la primera vulnerabilidad remota basada en el límite de memoria (memory_limit). Se corrigen esos caminos concretos, pero no la clase de problema.
2020. Se reporta el bug #78876: variables muy largas en formularios multipart agotan la memoria y dejan ficheros temporales sin borrar. Se trata como algo menor.
2024. Durante la primera auditoría externa de PHP, realizada por Quarkslab con OSTIF y financiada por la Sovereign Tech Agency alemana, vuelven a aparecer señales del problema. No se demuestra que sea explotable y no se corrige.
2026. Dos equipos, por separado y con pocas semanas de diferencia, convierten esa pista en ejecución remota de código.

La PHP Foundation reconoce que en 2024 tuvo varias propuestas de arreglo sobre la mesa y pasó meses sin decidirse. Ella misma lo llama un fallo estructural, por su forma de tomar decisiones y por falta de recursos.

Cómo se encontró en 2026

En julio, OpenAI invitó a la empresa Calif a su iniciativa Patch the Planet, que financia auditorías de software abierto con modelos de frontera. Calif eligió PHP sin grandes expectativas, porque ya había pasado por muchas auditorías asistidas por IA. El investigador Ryan Austin, que conocía bien el trabajo de Esser, partió de una hipótesis: quizá seguían vivos parientes de aquel fallo de 2004.

Su método, tal como lo describe, fue una conversación dirigida en cuatro pasos:

Provocar el fallo a voluntad. Pidió al modelo formas de agotar la memoria con una sola petición. La más elegante usa subidas de ficheros vacías con nombres de campo muy anidados: un cuerpo de menos de 8 MiB llega a ocupar más de los 128 MiB de memoria por defecto.
Buscar dónde duele la interrupción. Pidió al agente revisar el gestor de memoria, los errores fatales y el cierre de peticiones. El agente vio que una función de las tablas hash incrementa sus contadores antes de inicializar el elemento. Si la memoria se agota justo ahí, la limpieza posterior trata datos a medio hacer como válidos.
Generalizar el patrón. Pidieron al modelo convertir ese hallazgo en una regla de búsqueda reutilizable: publicar un estado, hacer algo que puede fallar y solo después confirmar. Con ella apareció otra variante, en el seguimiento del progreso de subidas de sesión.
Llevarlo a PHP-FPM. Las primeras variantes solo servían contra Apache con mod_php. Para la configuración más común hoy recurrieron al deserializador de PHP viejo conocido de la seguridad del lenguaje y a su estado compartido.

Calif encontró los primeros caminos a ejecución remota el 1 de agosto, lo reportó el 11 y envió una prueba de concepto el 14. Wiz Research llegó a la misma clase de fallos por su cuenta el 19 de agosto, con su sistema Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol, y lo reportó el 24. El equipo de seguridad de OpenAI añadió más vectores de ataque en septiembre.

Lo que aportó la IA y lo que no

Aquí está, para mí, la lección de fondo. Austin insiste en que no usó ningún entorno especial ni modelos fuera del alcance del público. Lo que marcó la diferencia fue conocer el objetivo, su historial de vulnerabilidades y partir de una teoría. Su consejo cabe en tres palabras: know your target.

Añade una observación muy útil para quien investiga con estas herramientas. Cuando buscan variantes, los modelos tienden a partir de los bugs más recientes y conocidos y a moverse hacia el código cercano. No suelen empezar por primitivas oscuras de hace veinte años. Quien conoce esa historia puede llevarlos hasta allí.

Wiz pone el acento en la otra mitad del trabajo: la explotación. Convertir estos fallos en un exploit fiable exige encadenar errores y ajustarse a cómo cada versión y configuración organiza la memoria. Antes eso suponía mucha depuración manual por cada objetivo. Con los modelos, adaptaron exploits a varias aplicaciones en horas.

Según su estimación, una sola persona hizo en una semana lo que antes habría ocupado meses a un equipo de primer nivel.

Las dos lecturas encajan. La IA no tuvo la idea, pero abarató muchísimo comprobarla y explotarla. Y eso cambia el cálculo: un fallo demasiado complejo para merecer la pena ya no está protegido por su complejidad.

La otra cara: quien mantiene el software

La historia tiene una parte menos vistosa y quizá más importante. La seguridad de PHP, que sostiene buena parte de la web, depende de un equipo pequeño financiado por la PHP Foundation y de algo de ayuda voluntaria.

Desde julio, ese equipo ha publicado 15 CVE y ha revisado más de 100 informes que resultaron inválidos, duplicados o imposibles de reproducir. La IA no solo encuentra fallos reales, también multiplica el ruido que llega a los mantenedores.

La divulgación coordinada tampoco aguantó del todo:

20 de octubre, sobre las 15:00 UTC. Circulan los identificadores CVE con una puntuación y una fecha erróneas, sin detalles técnicos. PHP adelanta el aviso y mueve el parche del 22 al 21.
Esa misma noche. Calif publica por error un vídeo de su prueba de concepto que revela algunos detalles.
21 de octubre, 07:41 UTC. Más de seis horas antes de lo acordado, Chainguard publica imágenes con el parche y rompe el embargo.

La Foundation ya ha cambiado su forma de trabajar. Entre otras cosas, sus decisiones de seguridad pasan del consenso a la votación por mayoría y pide a las empresas que usan PHP que financien su seguridad.

Qué hacer ahora

Si gestionas servidores con PHP, la única solución completa es actualizar.

Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La 8.1 y anteriores no tienen versión oficial. PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1.
Paquetes de distribución: revisa el aviso de seguridad de tu distribución. El número de versión puede ser distinto aunque el parche esté incluido.
Reinicia los procesos: PHP-FPM, Apache y cualquier proceso PHP de larga duración. Un proceso que no se reinicia sigue ejecutando el código vulnerable.
Busca PHP escondido: productos, appliances y contenedores que lo incluyen, aunque tu web principal no lo use.
Mitigaciones temporales: desactivar session.upload_progress o quitar el límite de memoria son medidas parciales con efectos secundarios. Sirven para ganar tiempo, no sustituyen al parche.

Lo que nos deja

Para quienes investigamos y enseñamos seguridad en redes, sistemas y servicios y comunicaciones seguras, php2shell deja tres ideas claras:

El conocimiento del dominio sigue siendo la ventaja decisiva. Los modelos amplifican a quien sabe qué preguntar. No sustituyen esa intuición.
La complejidad ya no es una defensa. Un fallo conocido pero “difícil de explotar” debe tratarse como explotable.
El cuello de botella se ha desplazado al mantenimiento. Encontrar fallos es cada vez más barato pero arreglarlos, coordinarlos y desplegarlos sigue dependiendo de equipos pequeños y con pocos recursos.

Recomendamos leer los informes originales, sobre todo el de Calif. Es una clase práctica de investigación de vulnerabilidades con IA.