¿Habría detenido php2shell un WAF con IA? Pregunta equivocada.
php2shell es un fallo crítico del propio motor de PHP, y casi la mitad de los sitios PHP ejecutan una versión que no recibirá parche. Los dueños de sitios asustados recurren a los WAF con IA. Aquí explico por qué esa es la pregunta equivocada, y qué es lo que de verdad evita que te comprometan.
Esta semana apareció un nuevo fallo en PHP, y es grave. La gente lo llama php2shell. Son dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619. PHP les asigna a ambas un 9.2 sobre 10. Algunos investigadores hablaron de un 10 redondo. Fuente: Help Net Security | SecurityWeek
Los detalles se filtraron antes de que el parche estuviera listo. Para el 21 de octubre los atacantes ya golpeaban sitios en producción a escala. Fuente: Hadrian
Esta es la parte que asusta a la gente. El fallo está en el propio PHP, no en tu código. Tu aplicación puede estar limpia y aun así quedas expuesto. Fuente: The Hacker News
Así que me hacen una pregunta una y otra vez. ¿Habría detenido esto un WAF con IA? Creo que es la pregunta equivocada. Déjame explicarte por qué.
Qué es php2shell en realidad
La mayoría de los fallos web viven en tu aplicación. Un campo de formulario mal hecho. Una página de login débil. php2shell es distinto. Vive en el motor de PHP. Ese es el motor que ejecuta todos los sitios PHP. Fuente: Hadrian
Las configuraciones más peligrosas usan mod_php con Apache. Ahí un atacante no necesita iniciar sesión. El fallo puede dispararse antes de que tu código llegue a ejecutarse. PHP marca ese caso como el de mayor riesgo. Fuente: Hadrian
La mayoría de los ataques hasta ahora abusan de una sola función. Se llama session upload progress. PHP gestiona mal la memoria mientras lee una subida de archivo. Fuente: Hadrian
Y ahora la parte fea para quien defiende. La petición maliciosa puede parecer normal. Es una subida de archivo. No hay comillas raras de SQL. Ninguna etiqueta de script. Ningún ../ en la ruta. No hay nada contra lo que un filtro pueda saltar.
Esta película ya la hemos visto
Todo esto me resulta familiar. Me recuerda a los primeros días de la inyección SQL. Un truco de nicho se volvió masivo muy rápido. Las herramientas se abarataron. Para 2008 una botnet rastreaba la web en masa buscando un solo campo débil y envenenaba todos los sitios que encontraba. Fuente: Dark Reading (Asprox, 2008)
php2shell tiene la misma forma. No requiere autenticación. Está en el motor. Es trivial de rastrear. Así que ahora mismo todos los actores, buenos y malos, están peinando la web en busca de sitios vulnerables. Con tantas aplicaciones abandonadas por ahí, es casi seguro que encontrarán varias.
Pero esto es peor que la inyección SQL en un aspecto clave. La inyección SQL era un fallo de tu aplicación. Una aplicación mantenida podía corregirlo en el código. php2shell es un fallo del motor de PHP. En una versión que llegó al final de su vida, el dueño no tiene arreglo alguno. La aplicación abandonada no solo está sin parchear. Es imposible de parchear.
Sí, la IA acelera ahora a ambos bandos. Los atacantes generan escáneres de forma automática. Los defensores escriben parches virtuales de forma automática. Pero no es un intercambio justo. El atacante necesita ganar una sola vez entre millones de sitios. El defensor tiene que arreglarlos todos y cada uno. Unas herramientas más rápidas no ayudan a un sitio que ya no tiene a nadie que lo administre.
Esto es el descubrimiento de vulnerabilidades disparándose en vertical. Escribí sobre ese cambio cuando un modelo de IA sacó a la luz miles de zero-days de golpe. php2shell es uno de los primeros efectos de ello, no el último.
El problema real es el PHP antiguo
PHP publicó los arreglos el 21 de octubre. Las versiones seguras son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Fuente: Help Net Security Parcheas y estás a salvo. Sencillo, ¿verdad?
No para la mayor parte de la web. Mira lo que ejecutan de verdad hoy los sitios PHP. Estas cifras vienen de la tabla de versiones de PHP y arreglos de Hadrian, construida sobre datos de W3Techs. Fuente: Hadrian, tabla de versiones de PHP / arreglo oficial (W3Techs, 21 oct 2026)
Suma todo. Alrededor del 48.5% de los sitios PHP ejecutan una versión sin arreglo oficial en camino. Fuente: Hadrian, tabla de versiones de PHP / arreglo oficial PHP ejecuta en torno al 69.3% de todos los sitios con un backend conocido. Así que esto es cerca de un tercio de toda la web. Fuente: W3Techs vía Hadrian
Son versiones que llegaron al final de su vida. El proyecto dejó de darles soporte hace años. PHP sí publicó parches en código fuente puro para 7.4, 8.0 y 8.1, pero tienes que compilarlos tú mismo. Fuente: Hadrian La mayoría de los dueños de sitios nunca lo harán.
Aquí está el meollo. Una porción enorme de la web no puede parchear. Así que salen a buscar algo que comprar en su lugar. Y el mercado tiene una respuesta lista. Es el WAF con IA.
Por qué "¿me salvará un WAF con IA?" es la pregunta equivocada
Escribí una guía entera sobre lo que de verdad significa "con IA" en un WAF. Léela para el panorama completo. La versión corta es esta. Un WAF con IA de verdad aprende tu tráfico normal y marca lo que se sale de lo común.
Suena perfecto para un fallo contra el que todavía nadie tiene una regla. Pero piensa en lo que ve el modelo. Ve la petición. php2shell hace su daño dentro de la memoria de PHP, después de que la petición ya se dejó pasar. La pista no está en los bytes que viajan por el cable. Así que el modelo no tiene nada de lo que aprender.
Una vez que existe un exploit público, un WAF puede bloquear la forma conocida del ataque. Eso es real y útil. Pero eso es una firma. Es un parche virtual. Un WAF corriente basado en reglas hace lo mismo, a menudo más rápido.
Así que la etiqueta de IA aporta poco aquí. Aquello para lo que se vende, atrapar un ataque recién nacido leyendo la intención, es justo lo que no puede hacer con un fallo de memoria. Saber qué bytes rompen PHP viene del CVE. No viene de que el modelo sea listo.
Qué es lo que de verdad evita que te comprometan
Un WAF es un cinturón de seguridad. No es el freno. Esto es lo que hace el trabajo de verdad.
- Sal del PHP que llegó al final de su vida. Este es el único arreglo real. PHP 8.2 o más nuevo recibe parches. Todo lo anterior vive de prestado.
- Ejecuta PHP con el mínimo privilegio. Usa php-fpm, no mod_php. Dale al proceso trabajador su propio usuario con pocos permisos.
- Haz que tu carpeta de subidas no sea ejecutable. Si ahí aterriza un shell, no debería ejecutarse. Un archivo
.phpsoltado no sirve de nada si el servidor se niega a ejecutarlo. - Desactiva session upload progress si no lo usas. Configúralo en php.ini o en el pool de FPM, y reinicia los procesos trabajadores.
- Bloquea las peticiones sueltas a
.php. Un atacante que entra suele soltar un shell y luego llamarlo. Una regla que devuelve 404 a archivos.phpdesconocidos entorpece ese paso. - Mantén copias de seguridad limpias. Una máquina comprometida sigue comprometida. El arreglo honesto ante una brecha es restaurar desde una copia que sabes que está sana. Fuente: Hadrian
; php.ini o tu pool de FPM, luego reinicia los procesos trabajadores.
; Configúralo aquí, no con ini_set() ni .user.ini.
; Esto ayuda, pero por sí solo no es un arreglo completo.
session.upload_progress.enabled = 0Dónde un WAF sí se gana su lugar
No estoy diciendo que te saltes el WAF. Un WAF te compra tiempo. Eso importa muchísimo cuando no puedes parchear hoy.
Toma Nivoli Edge como un ejemplo honesto. Su "PHP parser guard" bloquea las subidas malformadas en el borde, antes de que PHP las lea. Su propia documentación incluye CVE-2026-109618 y CVE-2026-109619 entre los fallos que cubre. Fuente: documentación de Nivoli
Pero lee la línea siguiente en esa misma documentación. El guard "reduce la exposición a fallos del propio PHP" y "no reemplaza la actualización de PHP". Fuente: documentación de Nivoli Ese es el planteamiento honesto. Ojalá más proveedores escribieran así.
Una regla para los .php sueltos y un parser guard ralentizan a un atacante. No vuelven seguro un motor sin parchear. Ningún WAF lo hace.
La conclusión
Entonces, ¿habría detenido php2shell un WAF con IA? Para el ataque recién nacido, no. Para la forma conocida más adelante, una firma lo detiene, y para eso no necesitas IA.
La lección de verdad es más vieja y más aburrida. Parchea lo que puedas. Si no puedes parchear, fortifica. Mínimo privilegio. Subidas no ejecutables. Copias de seguridad limpias. Luego pon un WAF delante para comprar tiempo.
La caja que compras no es el arreglo. Los hábitos sí.