El viernes 18 de julio de 2026 aparecieron los primeros intentos de explotación reales contra CVE-2026-6875, un fallo crítico en ServiceNow AI Platform que permite ejecutar código en la instancia sin necesidad de credenciales, sin phishing y sin un punto de apoyo previo. Lo inquietante no es solo la gravedad —CVSS 9.5— sino el reloj: ServiceNow publicó el parche el 13 de julio y los ataques llegaron cinco días después.
ServiceNow es una de las plataformas de gestión de servicios más extendidas en grandes organizaciones: sostiene la gestión de incidentes, el inventario de activos (CMDB), la automatización de procesos y flujos con inteligencia artificial. Cuando un fallo permite tomar esa plataforma desde fuera, el atacante no aterriza en un servidor cualquiera: aterriza en el sistema nervioso operativo de la empresa, con visibilidad sobre tickets, datos de configuración y las integraciones que conectan la instancia con la red interna. Este artículo explica, desde la óptica del defensor, cómo funciona el problema, qué rastro deja y qué controles concretos reducen el riesgo.
Qué es CVE-2026-6875 y por qué es tan grave
El fallo es un escape del entorno aislado (sandbox) de scripting de la plataforma. ServiceNow evalúa expresiones y pequeños fragmentos de código en un aislamiento pensado para que ese código no toque el sistema subyacente. La vulnerabilidad rompe esa frontera: encadenando primitivas del propio motor, un atacante consigue que el código deje de ejecutarse dentro de la caja y pase a ejecutarse con los privilegios del servidor.
La parte que eleva el riesgo es que el punto de entrada es previo a la autenticación. La investigación técnica que originó el aviso —publicada por el equipo de Assetnote (Searchlight Cyber) bajo el título «Smashing the ServiceNow Sandbox»— identifica un endpoint accesible sin sesión que acepta entrada controlada por el usuario. Es decir: cualquiera con acceso de red a la instancia puede alcanzar el punto vulnerable. No hay una contraseña ni un segundo factor que se interponga.
ServiceNow reconoce en su aviso KB3137947 el alcance del compromiso: lectura de datos almacenados en las tablas, creación de cuentas de administrador y —esto es lo que convierte un incidente cloud en un problema de red interna— la posibilidad de ejecutar comandos en los MID Server conectados, los servidores intermediarios que la instancia usa para hablar con sistemas dentro del perímetro corporativo.
La cronología que importa: de la investigación al ataque
El caso es un ejemplo de manual de lo rápido que se cierra hoy la ventana entre «se conoce» y «se ataca». La vulnerabilidad se reportó a ServiceNow a principios de abril de 2026. El aviso y el parche salieron el 13 de julio. Los primeros intentos de explotación se observaron el 18 de julio, cinco días después.
Y hay un matiz que conviene subrayar: la firma de inteligencia de amenazas Defused documentó una segunda cadena de escape distinta de la prueba de concepto pública. Importa porque muchas defensas improvisadas se calibran contra el primer patrón conocido; una variante que llega por otra ruta las esquiva. Quien haya bloqueado solo la firma del PoC inicial puede estar cubriendo media puerta.
Cifras y hechos que puedes contrastar directamente en las fuentes:
| Dato | Valor |
|---|---|
| Producto | ServiceNow AI Platform |
| Tipo | Escape de sandbox → RCE sin autenticar |
| CVSS | 9.5 (crítica) |
| Reporte inicial | Principios de abril de 2026 (Assetnote / Searchlight Cyber) |
| Parche y aviso | 13 de julio de 2026 (KB3137947) |
| Primera explotación | 18 de julio de 2026 (5 días tras el parche) |
| Agravante | Segunda cadena de escape que evade defensas ajustadas al PoC |
Fuentes: NVD, ServiceNow KB3137947, Help Net Security, SecurityWeek.
Por qué los controles habituales se quedan cortos
Tres factores hacen que la receta defensiva tradicional falle aquí. El primero es que no hay autenticación que romper: el arsenal habitual —MFA, políticas de contraseñas, detección de fuerza bruta— no entra en juego porque el atacante no inicia sesión. El segundo es la confianza implícita en la plataforma: ServiceNow suele estar integrado en profundidad, con permisos amplios y conexiones a directorios, sistemas de tickets, correo y, vía MID Server, a la propia red interna. Comprometerlo no es tomar un servidor aislado, es heredar sus privilegios.
El tercero es la velocidad de adaptación del atacante. Como demuestra la segunda cadena de escape, una regla de WAF calibrada contra el primer patrón público envejece en horas. La defensa no puede depender de una firma concreta; tiene que apoyarse en detección de comportamiento y en la reducción de la superficie expuesta. Priorizar bien qué se parchea y en qué orden es justo el tipo de decisión que un buen proceso de gestión de vulnerabilidades debería resolver con criterios como KEV, EPSS y SSVC, un tema que ya tratamos en detalle en el blog.
Detección: qué rastro deja y dónde mirar
Este es el terreno donde el defensor recupera ventaja. Aunque el ataque sea silencioso en su entrada, deja huellas observables si se está mirando en el sitio adecuado.
En los registros de la instancia y del borde:
- Peticiones anómalas a endpoints previos a la autenticación, en particular a /assessment_thanks.do, el punto de entrada documentado en la investigación pública.
- Creación inesperada de cuentas con rol de administrador o cambios de rol repentinos en usuarios existentes.
- Modificaciones no justificadas en Script Includes, reglas de negocio o cualquier objeto que ejecute código del lado servidor.
- Accesos o extracciones masivas de datos de tablas fuera del patrón habitual de uso.
En los sistemas MID Server, que son el puente hacia la red interna:
- Creación de procesos inesperada en el host del MID Server: es una señal de ejecución de comandos y merece alerta inmediata.
- Conexiones salientes del MID Server hacia destinos nuevos o poco habituales, posible indicio de movimiento lateral o exfiltración.
- Comandos emitidos a la instancia que no se corresponden con ninguna automatización aprobada.
Instrumentar los hosts que alojan MID Server con EDR y correlacionar sus eventos en el SIEM convierte una intrusión invisible en una alerta accionable. Cuando el patrón no encaja en ninguna regla previa, la búsqueda proactiva de amenazas —threat hunting— es lo que cierra el hueco entre lo que se conoce y lo que ya está pasando.
Defensa práctica: qué hacer esta semana
El orden importa. Estas son las acciones que reducen exposición de forma inmediata, no una lista genérica de buenas intenciones.
- Aplicar el parche de ServiceNow (KB3137947) en todas las instancias afectadas. Es la medida que cierra la puerta; el resto contiene y verifica.
- Activar el modelo «Guarded Script» que ServiceNow introdujo con el parche: limita el código de baja confianza a expresiones simples y obliga a mover la lógica compleja —variables, condicionales, bucles, asignaciones— a Script Includes controlados.
- Revisar la exposición de la instancia: restringir el acceso de red al panel y a los endpoints administrativos a rangos e identidades conocidos reduce quién puede siquiera alcanzar el punto vulnerable.
- Segmentar y vigilar los MID Server: mínimo privilegio en las cuentas de servicio que usan, y aislamiento de red para que un compromiso no se traduzca en acceso libre a sistemas internos.
- Auditar cuentas de administrador y roles creados o modificados desde principios de julio, y rotar credenciales y tokens de integración que la instancia custodia.
- Asumir la posibilidad de compromiso si la instancia estuvo expuesta entre el 13 y el parcheo efectivo: activar el plan de respuesta a incidentes y buscar indicios de persistencia, no solo del acceso inicial.
El ángulo que no conviene olvidar: riesgo de terceros
Un compromiso de ServiceNow no es solo un problema técnico; es, por definición, un incidente en un proveedor tecnológico crítico. Para muchas organizaciones, la plataforma es el sistema desde el que se gobierna la operación de TI. Ese encuadre —el de la gestión del riesgo de terceros— es el que conecta este caso con la sala de reuniones y con la normativa. La lección de fondo es la misma que dejó la brecha de la Comisión Europea y que venimos documentando en las lecciones de la cadena de suministro digital: el riesgo ya no vive solo en tu perímetro, vive en las plataformas de las que dependes.
Para las entidades sujetas a NIS2, un incidente significativo en un sistema de esta importancia activa obligaciones de notificación —alerta temprana en las primeras 24 horas— y de evaluación de impacto. Bajo DORA, ServiceNow encaja como proveedor de servicios TIC: debería estar en el registro de terceros, con sus dependencias mapeadas y un plan claro de continuidad si la plataforma falla o queda comprometida. Y como el fallo vive en la capa de IA de la plataforma, es también un recordatorio de que la seguridad de la inteligencia artificial en la empresa no es un debate futuro: es superficie de ataque hoy.
En esencia
CVE-2026-6875 no es un fallo más de la lista semanal. Reúne los tres ingredientes que convierten una vulnerabilidad en una crisis: ejecución remota sin autenticar, una plataforma que está en el centro de la operación y explotación activa a los pocos días del parche. La buena noticia es que la defensa no depende de adivinar el próximo payload: parchear, activar Guarded Script, reducir exposición, vigilar los MID Server y tratar el caso como lo que es —un incidente de proveedor crítico— cubre lo que hay que cubrir. Lo caro no es actuar; es descubrir dentro de seis semanas que la instancia llevaba abierta desde julio.