El 21 de octubre de 2026 se divulgaron públicamente dos vulnerabilidades críticas, PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Ambas tienen una calificación de 9.2 y permiten la ejecución remota de código en servidores vulnerables. Portales gubernamentales, servicios públicos y sitios comerciales de varios países quedaron fuera de servicio como medida de precaución mientras los equipos se apresuraban a aplicar los parches.
Pero los fallos se conocían desde el 20 de octubre y el parche no se publicó hasta el día 21. Esa brecha es donde operan los atacantes, y plantea la pregunta que todo equipo de seguridad se está haciendo: ¿cómo proteger los sistemas cuando la vulnerabilidad es conocida pero el parche aún no está disponible?
Donde la protección basada en firmas llega a su límite
Los WAF tradicionales dependen, al menos en parte, de firmas. Eso los hace predecibles, pero también genera un retraso. Alguien tiene que analizar el exploit, escribir la regla y distribuirla; en muchos casos, los clientes aún deben realizar pasos manuales antes de estar protegidos.
¿Y qué sucede si un exploit circula antes de que su proveedor se actualice? ¿Qué pasa si el atacante modifica el payload para que ya no coincida? Con la IA ayudando a los atacantes a analizar fallos y generar variantes de exploits en cuestión de horas, esa ventana de tiempo sigue reduciéndose.
PHP2Shell complica aún más la situación. Ambos CVE provienen de fallos en la gestión de memoria del propio motor PHP, no de la lógica de una aplicación específica. Esto significa que existen múltiples rutas de explotación con diferentes estructuras de solicitud y condiciones de activación. Una firma que detecta una variante no garantiza protección contra la siguiente.
Cómo es el ataque
Una cadena dirigida a CVE-2026-109618 incluye un PHP_SESSION_UPLOAD_PROGRESS campo en una carga multipart, a pesar de que el endpoint de la aplicación nunca lo define. Para un motor de firmas, la solicitud puede parecer una carga común. (El payload en este ejemplo se ha omitido).
Cómo lo ve Salt
Salt no necesita conocer el exploit. Salt aprende la estructura de sus API, llamadas MCP y endpoints de aplicación: qué campos, parámetros y formatos espera cada endpoint. Una solicitud que contiene un PHP_SESSION_UPLOAD_PROGRESS campo hacia un endpoint que nunca lo ha aceptado es una anomalía, y no se requiere ninguna firma para detectarla.
Pero detectar una anomalía no es suficiente. Muchas solicitudes inusuales son inofensivas: una nueva versión de cliente, una integración mal configurada, un desarrollador probando algo. Si cada anomalía genera una alerta, los defensores se ahogan en el ruido y los ataques reales se pierden en él.
La pieza que falta es la intención. La detección de intención conductual de Salt añade el contexto necesario para saber si una anomalía está vinculada a una actividad maliciosa. Salt observa la forma en que el consumidor realizó las solicitudes, la compara con el uso normal del endpoint de la aplicación y monitorea y compara cientos de otros atributos de comportamiento. Un campo extraño proveniente de un cliente conocido se ve muy diferente al mismo campo enviado por un consumidor que está sondeando endpoints, rotando variaciones de payload y comportándose de una manera totalmente distinta a la de un usuario legítimo.
La anomalía te dice que algo es diferente. La intención te dice si es un ataque.
Ya hemos visto esta película antes
Esto no es un caso aislado. Cuando ocurrió Log4Shell, Salt detectó intentos de explotación contra clientes antes de que se publicara ninguna firma. La vulnerabilidad era diferente, pero el principio era el mismo: los ataques a fallos de nivel de infraestructura deben llegar como solicitudes, y los consumidores que los envían se comportan de manera distinta a los usuarios legítimos de sus API y endpoints de aplicación.
La detección conductual es eficaz precisamente en las situaciones donde las firmas no lo son. Cuando una vulnerabilidad reside en la infraestructura y no en el código de la aplicación, una sola solicitud puede bastar para tomar el control de un sistema legítimo. La protección que comienza después de que se redacta la firma llega demasiado tarde.
La conclusión: los ataques de día cero son solo el calentamiento
Los ataques de día cero seguirán apareciendo. Lo que está cambiando es la superficie sobre la que impactan.
A medida que las empresas avanzan en sus transformaciones de IA, el tráfico entre máquinas crece rápidamente. Las API, los servidores MCP y los agentes que llaman a otros agentes y servicios se multiplican, y cada vez hay menos intervención humana en esas llamadas. Esto significa más objetivos, más consumidores y más puntos donde una sola vulnerabilidad puede ser explotada.
Al mismo tiempo, los actores de amenazas y los agentes maliciosos ya no se limitan a llamar a la puerta. Se han infiltrado. Una vez dentro, parecen cualquier otra carga de trabajo realizando llamadas a la API, y las herramientas perimetrales diseñadas para inspeccionar el tráfico en la entrada a menudo ni siquiera los detectan. En ese entorno, una firma no tiene nada con qué compararse y una anomalía estructural por sí sola no es suficiente, porque casi todo lo que ocurre dentro parece una máquina comunicándose con otra.
Por eso la intención importa más que nunca. La pregunta ya no es solo "¿esta solicitud parece inusual?", sino "¿quién la realiza, cómo se comporta y qué intenta hacer?". PHP2Shell es un ejemplo claro de la brecha de parcheo, pero lo más importante es que esa brecha existe ahora en todas partes donde las máquinas se comunican entre sí.
Los equipos de defensa necesitan una protección que comprenda sus propias API y la intención de quien las llama, para poder detener los ataques desde el día cero, antes del parche, antes de la firma y antes de que aparezca una variante que nadie ha documentado todavía.
Eso es para lo que está diseñado Salt.