El informe llegó el uno de abril
El 1 de abril de 2026, Adam Kues, de Assetnote, el brazo de investigación de Searchlight Cyber, envió a ServiceNow un informe que describía una forma de ejecutar código en la ServiceNow AI Platform sin credencial alguna. La compañía reaccionó rápido. En su propio relato de la divulgación, el equipo de investigación deja constancia de que ServiceNow "desplegó mitigaciones sólidas en todas las instancias en la nube en las 24 horas siguientes a nuestro informe" y que después publicó parches para los fallos de fondo en las semanas posteriores. Todo cliente con una instancia alojada por ServiceNow estaba protegido a comienzos de abril, y ninguno tuvo que hacer nada, ni siquiera enterarse.
Los clientes que ejecutan sus propias copias no supieron nada hasta el 13 de julio, cuando ServiceNow publicó el aviso de seguridad KB3137947 y liberó actualizaciones para los despliegues autoalojados. El fallo se identifica como CVE-2026-6875. ServiceNow, que actúa como su propia CNA, le asignó una puntuación CVSS 4.0 de 9,5 sobre 10. El vector recoge una complejidad de ataque alta, pero ningún privilegio y ninguna interacción del usuario, que es justo la combinación que vuelve apetecible una instancia accesible desde internet para quien escanea a gran escala.
Entre esas dos fechas caben 103 días. Para una empresa de SaaS, eso es una divulgación coordinada bien llevada. Para la parte de su clientela que opera la plataforma por su cuenta, es un trimestre entero sosteniendo un fallo crítico previo a la autenticación que el fabricante ya había cerrado en su propio parque.
Un sandbox que aceptó evaluar JavaScript
La vulnerabilidad reside en el sandbox de la ServiceNow AI Platform, la capa de contención que debería dejar que el código de la plataforma se ejecute sin llegar a nada que no le corresponda. El punto de entrada es la API GlideRecord, que admite la evaluación de JavaScript dentro de los filtros de consulta. La entrada facilitada por el usuario llegaba a una llamada addQuery con el prefijo javascript:, y la plataforma la evaluaba.
Un sandbox secundario tenía que atrapar exactamente eso y bloquear las funciones peligrosas. Los investigadores lo sortearon con una cadena de gadgets construida con Object.clone y Class.create.constructor, que juntos permiten la ejecución arbitraria de funciones durante los script includes. El punto de entrada demostrado fue el endpoint /assessment_thanks.do mediante su parámetro sysparm_assessable_type, y nada de ello exigía iniciar sesión.
Lo que eso le compra a un atacante no es un punto de apoyo en un rincón del producto. El análisis de Searchlight describe la lectura de datos de las tablas, la creación de cuentas de administrador y la ejecución de comandos de shell en cualquier proxy MID Server configurado que, como apuntan los investigadores, suele estar situado dentro de las redes internas de las empresas. El MID Server es la pieza que se adentra en su parque para descubrir activos y ejecutar automatismos. Es el puente, y el puente queda al alcance del fallo.
Quién soportó el riesgo de verdad
El instinto habitual en los consejos europeos dice que el autoalojamiento es la opción prudente. Los datos se quedan en hierro propio, la pregunta sobre la residencia se despacha en una frase y uno se ahorra ponerle al regulador un diagrama incómodo delante. En los sectores regulados de la UE, en la administración pública, en la banca y entre los grandes grupos del Mittelstand, ese instinto explica por qué una parte nada menor de los parques de ServiceNow no está en la nube de ServiceNow.
Este aviso de seguridad le da la vuelta a esa lógica. Los clientes que eligieron la nube del fabricante quedaron protegidos en los primeros días de abril por una mitigación que jamás tuvieron que pedir. Los clientes que eligieron operarlo ellos mismos, por control, cargaron con un fallo de ejecución remota de código sin autenticar durante abril, mayo, junio y medio julio, y solo fueron avisados cuando la corrección ya estaba lista para salir. El control sobre el despliegue acabó significando la propiedad de la ventana de exposición.
Nada de esto convierte la gestión de ServiceNow en algo reprochable. Llevar mitigaciones a un parque que uno mismo opera es sencillamente más rápido que llevar parches a un parque ajeno, y guardarse el detalle del aviso hasta que los clientes puedan actuar es práctica habitual y no ocultación. La lección para quien opera es más estrecha y más provechosa: "el fabricante lo ha corregido" y "nosotros estamos corregidos" son dos afirmaciones distintas, y en este caso mediaron cien días entre una y otra.
Las dos afirmaciones son ciertas a la vez
Durante el fin de semana del 18 y 19 de julio, el grupo de inteligencia de amenazas Defused informó de explotación activa, con los primeros intentos observados el viernes 17 de julio. El aviso de seguridad de ServiceNow, a lunes por la mañana, sigue afirmando que "no tiene constancia por ahora de explotación contra instancias de ServiceNow". Puestas una al lado de la otra, la cosa parece un fabricante que tarda en reconocer lo evidente.
El asunto es más interesante que eso, y encajar las dos versiones es el fondo de esta historia. Cada parte está midiendo una población distinta. ServiceNow dispone de telemetría directa sobre el parque que aloja, y ese parque está mitigado desde principios de abril, así que allí no se está explotando nada realmente. Defused vigila el tráfico de todo internet, que es donde viven las instancias autoalojadas. La población que el fabricante no puede ver es precisamente la que sigue sin parchear.
Así que la frase del fabricante es exacta y al mismo tiempo inservible como insumo de riesgo para usted. Un "sin explotación confirmada" de un proveedor de SaaS es una afirmación sobre el parque del propio proveedor, salvo que diga expresamente otra cosa. Si es usted quien ejecuta el software, el único estado de explotación que describe su situación es el que deduzca de sus propios registros.
El exploit no esperó a la prueba de concepto
Defused fue muy concreta sobre lo que vio. Las cargas, informó, "alcanzan el mismo sumidero previo a la autenticación que documentó @SLCyberSec (/assessment_thanks.do), pero el gadget de escape del sandbox llega a la misma primitiva de ejecución de código por una vía distinta a la de su PoC publicada". Los atacantes no estaban repitiendo el exploit de los investigadores. Habían llegado a la misma primitiva por su cuenta, tras hacer su propio trabajo desde el mismo punto de partida.
Ese detalle desarma una costumbre de planificación muy extendida en las casas con control de cambios: tomar la aparición de una prueba de concepto pública como el momento en que arranca el reloj y parchear en la ventana siguiente. Aquí la capacidad independiente llegó a la par que el análisis público y no después, y el propio aviso de seguridad, el 13 de julio, fue la última advertencia fiable que nadie iba a recibir.
Qué comprobar antes del martes
Empiece por la familia de versiones, porque los nombres de las correcciones no son intuitivos. Las versiones parcheadas son Brazil EA y Brazil GA, Australia Patch 2, Zurich Patch 7b o Zurich Patch 9, y Yokohama Patch 12 Hot Fix 1b o Yokohama Patch 13. Todo lo que quede por debajo de la línea correspondiente es vulnerable, y una instancia autoalojada que no haya tenido ventana de mantenimiento desde el 13 de julio no ha sido corregida por nadie en su nombre.
Después, dé por hecho que la ventana tuvo consecuencias. Saque los registros de acceso de /assessment_thanks.do y mire en concreto el parámetro sysparm_assessable_type. Revise la creación de cuentas de administrador a lo largo de todo el periodo y no solo de la última quincena, porque el fallo permite a un atacante crear una. Vaya luego a los MID Server, busque ejecuciones de procesos inesperadas y recuerde que esos equipos están dentro de la red interna y no delante de ella, que es lo que convierte un fallo de plataforma en un problema de movimiento lateral.
Si encuentra algo, el reloj es regulatorio además de técnico. Para las entidades esenciales e importantes de la UE, NIS2 exige una alerta temprana al CSIRT nacional en un plazo de 24 horas desde que se tiene conocimiento de un incidente significativo y una notificación más completa en 72 horas. En el Reino Unido, donde NIS2 no se aplica, el NCSC sigue siendo la vía de notificación, y es ese mismo trabajo probatorio lo que hace que valga la pena presentar el informe.
Leer a continuación: Una petición podía secuestrar tu sitio WordPress | Parchear SharePoint ya no cierra la puerta
