PHP2Shell no será la última. Aquí es donde aparecerá primero la próxima.

El 17 de octubre, la red de honeypots de Amazon registró un intento de explotación de PHP2Shell desde una dirección IP anonimizada. Sin embargo, la divulgación pública no llegaría hasta cuatro días después.

Cuando PHP publicó sus correcciones el 21 de octubre, los detalles técnicos ya se habían filtrado, los exploits de prueba de concepto circulaban ampliamente y se registraban intentos de explotación por todas partes. El problema era que había dos vulnerabilidades críticas de ejecución remota de código sin autenticación en el propio motor de PHP (CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS v4.0 de 9.2): lo que ahora conocemos como PHP2Shell.

Nuestro equipo de Investigación de Seguridad explicó lo que ocurrió y lo que debes hacer: a qué versiones actualizar, qué medidas podías implementar para reducir la exposición mientras actualizabas y dónde detecta el problema cada parte de la plataforma Snyk.

Esta publicación retoma el tema donde lo dejó nuestro equipo de Investigación de Seguridad. Queremos hablar de lo que nos enseñó la respuesta: dónde se origina y en qué consiste este tipo de exposición, por qué responder rápido depende del trabajo que hicimos meses antes y por qué la próxima vulnerabilidad ya viene en camino.

¿Por qué PHP2Shell fue un problema para equipos con código limpio?

Porque las vulnerabilidades están por debajo del código. ¿Y qué significa eso? Ambas CVE mencionadas ocurren en el ciclo de vida de las solicitudes del motor de PHP, por lo que se pueden explotar antes de que se ejecute cualquier código de la aplicación. En Apache, con mod_php, bastaba una sola solicitud sin autenticación para explotar la vulnerabilidad.

Piénsalo un momento. Probablemente tenías revisiones cuidadosas, código limpio y un árbol de dependencias ordenado, todo por encima del problema real. La primera pregunta que enfrentó cada equipo fue dónde respondía PHP a las solicitudes y si alguien podía explotarlo en ese mismo momento.

La pregunta se refería a las aplicaciones en ejecución. Es exactamente la misma pregunta por la que siempre empiezan los atacantes.

¿Qué inventario te indica dónde se está ejecutando PHP?

Cada tipo de inventario te da una parte de la respuesta.

PHP llega a producción a través de un Dockerfile, un paquete de distribución, una imagen de plataforma o una instalación manual. Una restricción "php": ">=8.2" en composer.json te indica qué acepta una aplicación; luego, la versión implementada depende de cuál de esas vías se usó para instalarlo. Los análisis de contenedores detectan PHP instalado desde paquetes de distribución una vez que cada distribución publica su aviso de seguridad. PHP compilado desde el código fuente, incluidas las imágenes oficiales de PHP para Docker, queda fuera de esa vista. (Una vez más, la publicación de nuestro equipo de investigación muestra exactamente qué vista de Snyk detecta cada parte de esta realidad.)

Luego está la cadena de versión. VirusTotal identifica mediante huellas digitales alrededor de 5.1 millones de direcciones IP que ejecutan PHP, y solo cerca de 1.1 millones anuncian una versión; es decir, aproximadamente cuatro de cada cinco la ocultan. Su resumen es una de las frases más claras que hemos leído sobre el tema: «Si solo buscas una cadena de versión, solo ves la parte del problema que se hace visible por sí sola».

La brecha entre lo que conocen tus herramientas internas y lo que realmente responde desde el exterior es donde está el riesgo real. Los atacantes llegan a tu URL, y PHP2Shell es el ejemplo más claro que hemos visto de esto. Quien busca explotarlo termina haciendo la misma pregunta: ¿PHP responde en esta URL?

¿Cómo se vio la respuesta desde el exterior?

La ventaja inicial: antes del lanzamiento de PHP, a las 14:00 UTC del 21 de octubre, Snyk ya tenía avisos de seguridad activos para ambas CVE, así que los proyectos supervisados recibirían una alerta en cuanto se conocieran las versiones corregidas. Unos 30 minutos después del lanzamiento, esos avisos ya incluían los rangos afectados y las versiones corregidas; los avisos de las distribuciones se publicaron a medida que cada una los emitía. Esto cubría lo que podían detectar Snyk Container y los análisis de software no administrado.

Tres preguntas guiaron el trabajo de Snyk API & Web:

1. ¿Dónde se está ejecutando PHP? Discovery enumera los activos de tus dominios e identifica las tecnologías de su stack. Selecciona PHP en el filtro de tecnología para obtener todos los hosts y endpoints detectados donde se identificó PHP, junto con su calificación de riesgo, puntuación y fecha de última detección. Los números de versión se obtienen después, directamente de los hosts. Como señaló nuestro equipo de investigación, antes de aplicar parches, necesitas tener la lista.

2. ¿Alguien puede explotarlo? En las 24 horas posteriores al lanzamiento de PHP, el perfil de análisis completo ya probaba PHP2Shell, y los equipos podían ejecutar esa verificación por su cuenta como perfil personalizado para obtener rápidamente una respuesta en todos los objetivos que ejecutaban PHP.

3. ¿Funcionó la corrección? Ejecuta el mismo perfil personalizado después de aplicar el parche y combínalo con el aviso de seguridad o el nivel de parche de tu distribución, porque una versión compilada y corregida de una distribución puede conservar un número de versión anterior.

Entonces: Discovery --> verificación dirigida --> parche --> nueva prueba: sondear, observar y deducir, mientras el reloj corre en horas. Y eso es precisamente lo que más nos preocupa y lo que más nos importa. Para los equipos que ya usaban Snyk API & Web, el trabajo difícil estaba hecho antes del 21 de octubre: sus dominios estaban mapeados y sus aplicaciones configuradas como objetivos. Cuando estuvo lista la verificación, responder solo requirió aplicar un filtro y ejecutar un análisis rápido.

Para nosotros, ese es uno de los principales beneficios de las pruebas continuas desde el exterior: el trabajo que permite responder el primer día se hace meses antes.

Si PHP2Shell se puede detectar desde el exterior, ¿qué fue lo difícil?

El tiempo.

En mayo, explicamos la distinción en la que se basa COS. Las vulnerabilidades que pueden detectarse mediante heurísticas se manifiestan ante herramientas deterministas: envían cargas útiles a una aplicación o API en ejecución, observan las respuestas y deducen lo que ocurre. Las vulnerabilidades que dependen del contexto (BOLA, filtraciones entre inquilinos y cadenas de lógica de negocio) no tienen ninguna firma, porque se encuentran en la brecha entre lo que se supone que debe hacer una aplicación y lo que realmente hace.

Una vez que se conocieron los detalles de PHP2Shell, fue posible probarla desde el exterior, así que pertenece claramente a la primera categoría: vulnerabilidades detectables mediante heurísticas. La dificultad, la limitación, era la brecha entre la divulgación y tener una verificación en marcha contra todo lo que expones. Esa brecha es la ventana que tienen los atacantes para explotar la vulnerabilidad, y esta vez se abrió cuatro días antes de que finalmente se divulgara.

Además, la divulgación siguió evolucionando. El 23 de octubre, el proyecto PHP describió una omisión parcial de las medidas de protección (CVE-2026-115560) que se aplica cuando una aplicación cambia el controlador de serialización de sesiones con ini_set() antes de iniciar la sesión, con el progreso de carga habilitado. Sus condiciones previas son poco comunes, pero lo que concluiste el miércoles aún debía revisarse el viernes. Una respuesta puntual queda desactualizada en cuestión de días.

¿Por qué PHP2Shell no será la última?

Hay tres razones. Se deben a la naturaleza de cómo se descubrieron:

1. Porque se descubrieron con ayuda de la IA en un motor que lleva tres décadas impulsando la web. Nuestro equipo de investigación lo dijo claramente: «En un mundo de LLM y agentes, todo el mundo sigue usando servidores.» Y los atacantes ahora tienen en sus manos el mismo tipo de modelo que descubrió estas vulnerabilidades.

2. Un ritmo más intenso. Manoj Nair, CTO y director de Innovación de Snyk, lo describió en septiembre: «El tipo de falla grave que la IA ahora detecta en software de uso generalizado, el tipo de hallazgo que antes aparecía una o dos veces al año y trastocaba el trimestre de todos, está apareciendo varias veces por semana, según lo que estoy viendo.»

3. Un reloj que avanza mucho más rápido. CJ Moses, CISO de Amazon Integrated Security, señaló dos lecciones de PHP2Shell que se aplican mucho más allá de este caso. Los equipos de defensa «no deben asumir que la fecha de divulgación pública es la fecha más temprana en que pudo empezar la explotación.» Y «por razones estructurales, el tiempo entre la publicación de un parche y la disponibilidad de un exploit funcional se está reduciendo,» porque el análisis asistido por IA abarata la conversión de las diferencias de un parche o un aviso de seguridad en un exploit funcional. Su recomendación para vulnerabilidades críticas en sistemas expuestos a Internet: «midan los plazos para aplicar parches y medidas de mitigación en horas.»

¿Qué necesitas para estar preparado para la próxima?

Si dejamos de lado los nombres de productos, todo se reduce a cuatro características. Evalúa cualquier enfoque según estas características, incluido el nuestro. No pienses en los nombres de productos, sino en estas cuatro características. Y evalúa cualquier enfoque con esos criterios, incluido el nuestro.

1. Un inventario disponible antes de que se publique el aviso. Creado desde el exterior y actualizado constantemente, para que una nueva divulgación se aborde con un filtro.

2. Verificaciones disponibles en cuestión de horas. La brecha entre un aviso de seguridad y una prueba en ejecución es la ventana de ataque. Mídela.

3. Nuevas pruebas a pedido. La misma verificación dirigida, ejecutada una y otra vez hasta confirmar que la corrección funciona.

4. Pruebas que no necesitan una firma. Las heurísticas detectan lo que alguien ya describió. Para todo lo demás se necesita razonamiento: pruebas que determinan qué se supone que debe hacer tu aplicación y luego buscan la brecha entre eso y lo que realmente hace.

En cuanto a Snyk, así se relaciona esto con lo que ofrecemos.

Snyk API & Web cubre las tres primeras características: Discovery, un motor que el equipo mantiene actualizado a medida que se publican avisos de seguridad y perfiles dirigidos que puedes ejecutar una y otra vez. Evo Continuous Offensive Security agrega la cuarta: AI Pentesting analiza tu aplicación como lo haría un pentester; Agent Red Teaming actúa en cuanto el reconocimiento detecta un LLM en el stack, y Dynamic Testing, el motor de Snyk API & Web, cubre continuamente las categorías que se detectan mediante heurísticas. En los términos de nuestra plataforma, eso es Validate: atacar tus aplicaciones continuamente para demostrar que las correcciones funcionaron y mostrar qué sigue siendo explotable.

Luego está la postura. En The AI Security Panel: Unfiltered, el 14 de octubre, Manoj hizo la pregunta a la que siempre volvemos: «Si un atacante autónomo va a atacarte, ¿por qué no te atacas tú primero?» Esa pregunta es la esencia de COS. De nuestro lado, el trabajo consiste en reducir cada una de las brechas de esta historia: desde el aviso hasta la verificación en ejecución y desde la verificación hasta la confirmación de la corrección.

¿Dónde aparecerá primero la próxima vulnerabilidad?

A estas alturas, es imposible saber qué motor se verá afectado ni cuándo. Es más fácil predecir dónde aparecerá primero: en tu URL. Tus pruebas ya deberían estar allí.

¿Quieres ver qué encontraría hoy un atacante en tu URL? Reserva una demo de Evo Continuous Offensive Security y descubre cómo mapea tu superficie de ataque desde el exterior, comprueba qué hallazgos son explotables y repite las pruebas hasta confirmar que la corrección funciona.