Se avecina un trimestre muy favorable para las empresas de seguridad de aplicaciones. PHP2Shell se convertirá en el mejor argumento presupuestario que los proveedores del sector hayan tenido en años. La inteligencia artificial ayudó a los investigadores a localizar dos vulnerabilidades de ejecución remota de código en el lenguaje que sostiene el 69% de la web, los atacantes las aprovecharon antes de que existiera el parche y el mensaje de venta se escribe solo: encontrar más fallos y corregirlos más rápido.
Las organizaciones deberían cuestionar esa premisa. Los equipos de seguridad no pueden parchear a la velocidad de una máquina, pero sí pueden limitar hasta dónde llega un atacante tras la explotación si tratan la identidad como el plano de control. Más allá del acceso inicial, la gravedad final de un incidente depende en gran medida de las cuentas de servicio, claves de API, roles en la nube y tokens que puede usar la carga de trabajo comprometida, y de a qué puede llegar con ellos.
De la vulnerabilidad a la explotación
Conviene medir primero cuánto más rápida es ahora la explotación. Los dos fallos detrás de PHP2Shell llevaban en el código de PHP desde 2012. Los investigadores de Calif y Wiz los descubrieron en agosto con ayuda de modelos de OpenAI y Google, y los divulgaron de forma conjunta con OpenAI. Amazon detectó un intento de explotación el 17 de octubre, cuatro días antes de la divulgación. PHP publicó el parche el 21 de octubre y watchTowr observó intentos de explotación reales ese mismo día. Cloudflare registró un aumento rápido del tráfico de ataque tras la divulgación y, el 26 de octubre, CISA añadió ambos fallos a su lista de vulnerabilidades conocidas y explotadas.
La explotación suele comenzar ahora antes de la divulgación, pero la remediación no avanza al mismo ritmo. El informe DBIR 2026 de Verizon indica que el tiempo medio para corregir una vulnerabilidad explotada conocida es de 43 días. Según Qualys, el tiempo medio de remediación es de 21,2 días, el 63% de las vulnerabilidades críticas sigue abierto tras una semana y se publican alrededor de 195 nuevos CVE cada día.
PHP2Shell tardará más que la mayoría en quedar limpio. PHP se distribuye dentro de dispositivos y paneles de control de alojamiento que los clientes no pueden parchear por sí mismos, y las versiones 8.1 y anteriores no recibieron compilaciones oficiales. A 27 de octubre, Censys contabilizó 32,5 millones de servicios PHP expuestos a internet que seguían ejecutando versiones potencialmente vulnerables, además de más de 60 millones que no informan de su versión. En cualquier escenario, la velocidad de remediación seguirá siendo inferior al ritmo de explotación en el futuro previsible, incluso cuando el propio parcheo se beneficie enormemente de los flujos de trabajo impulsados por inteligencia artificial.
Cada agente necesita una identidad
Los agentes actúan ahora en los sistemas con accesos que nadie ha revisado. La seguridad de agentes de IA de Token Security localiza cada agente, lo vincula a un propietario y limita lo que puede hacer, ofreciendo un orden basado en identidad para controlar el caos de la IA agéntica.
Encontrar no es corregir
Con la brecha de explotación ampliándose, resulta tentador invertir todo lo posible en contener la marea. Pero aunque un escaneo impulsado por IA encontrara mañana 2.000 nuevas vulnerabilidades de día cero en el entorno, eso no se traduciría en una postura de seguridad más sólida. Daría una lista: algunos elementos serán fáciles de parchear y otros requerirán más tiempo del que tiene el equipo. Para las ramas de PHP con soporte, la solución directa era sencilla, instalar la versión actualizada, y aun así gobiernos y empresas retiraron sus sitios mientras esperaban.
Hay una forma más optimista de verlo. Las vulnerabilidades llevan a exploits y los exploits a ataques, pero en el contexto empresarial el impacto de un ataque lo determina hasta dónde llegan las identidades comprometidas. Un shell en un servidor PHP da al atacante acceso a todo lo que ese servidor puede leer, desde variables de entorno hasta claves de nube en archivos de configuración. PHP2Shell también puede filtrar la memoria de los procesos trabajadores, incluidas contraseñas, tokens y claves de API. Un atacante que ejecuta código en un host abre la puerta a un pasillo, pero los objetos de valor suelen estar en habitaciones cerradas. Los controles que limitan el movimiento lateral no dependen de ganar una carrera contra el descubrimiento: encontrar vulnerabilidades es un proceso abierto, mientras que limitar el alcance de una cuenta de servicio es una tarea cuantificable.
Los atacantes toman el camino más fácil
Este enfoque tiene límites. Si la vulnerabilidad está en el proveedor de identidad o en el gestor de secretos, las capacidades de movimiento lateral vienen incluidas. Si está en la base de datos o en el proveedor de almacenamiento, el atacante ya está donde quiere estar. Por eso, con recursos limitados, es tentador seguir priorizando las vulnerabilidades: catalogar lo que encontraron los avisos y los escáneres, clasificarlo y trabajar de arriba abajo. Pero catalogar lleva semanas y corregir los hallazgos más urgentes aún más. La apuesta es que los agujeros más explotables de los sistemas centrales serán los primeros en cerrarse.
Esa apuesta prioriza la gravedad de la vulnerabilidad (la puntuación CVSS) sobre el radio de impacto. Los atacantes no buscan el camino más directo, sino el más fácil: usar una credencial filtrada y moverse con ella es más sencillo que encadenar vulnerabilidades de día cero para llegar directamente a una base de datos. Otros titulares de octubre muestran ese camino. En LiteLLM, los atacantes utilizaron una clave maestra expuesta en un repositorio público para obtener un token de propietario de organización de GitHub sin alcance delimitado desde una plataforma de agentes interna. Esa identidad les permitió robar otros dos tokens de mantenedores, subvertir el flujo de publicación y publicar artefactos que robaban credenciales.
Reduce primero el radio de impacto
No puedes ganar la carrera de parchear cada servidor antes de que lleguen los atacantes, pero sí puedes determinar cuánto vale para ellos un servidor comprometido. Descubre e inventaría cada agente de IA y cada identidad no humana, y empieza por asegurar los que más alcance tienen. Asigna un propietario, delimita el acceso según el propósito y la intención, elimina las credenciales inactivas y gobierna de forma continua el ciclo de vida de las identidades. Para los agentes de IA, ve más allá y concede acceso según la intención: eso es tratar la identidad como el plano de control.
El parcheo decide con qué rapidez cierras un agujero. La identidad decide cuánto consigue un atacante cuando no puedes cerrarlo.
Patrocinado y redactado por Token Security.
Deja una respuesta