ServiceNow RCE: seis comprobaciones antes del ticket

Una plataforma de tickets que gestiona procesos de incidentes, cambios y RRHH es una superficie de ataque de alta calidad. CVE-2026-6875 es un escape de sandbox pre-autenticación en la plataforma de IA de ServiceNow. Las versiones autoalojadas tienen una orden de parche inmediato, mientras que las alojadas en la nube requieren una verificación.

Relacionado: Modelos de OpenAI y pipeline de Hugging Face: qué verificar · ¿Qué es SOAR? Definición y delimitación

ServiceNow está profundamente integrado en los flujos de trabajo de incidentes, cambios y RRHH de numerosas empresas. Una vulnerabilidad RCE pre-autenticación en su plataforma no es solo otro agujero en una aplicación web: afecta a datos de procesos y sistemas conectados, desde Active Directory hasta APIs en la nube. Esta lista distingue las acciones inmediatas para versiones autoalojadas de las verificaciones necesarias para clientes en la nube.

¿Qué es CVE-2026-6875? Un escape de sandbox pre-autenticación en la plataforma de IA de ServiceNow. Searchlight Cyber identificó el fallo en el endpoint assessment_thanks.do. Más tarde, Defused reportó cargas útiles activas en entornos reales. ServiceNow proporciona parches y minimiza el riesgo en instancias alojadas.

1. Mantener el parche y la versión de lanzamiento frente a KB3137947

ServiceNow cerró la vulnerabilidad para las instancias alojadas en abril. Para las instancias autoalojadas, la actualización de seguridad bajo la KB3137947 se publicó en julio, con informes sobre su despliegue el 13.07.2026. El primer punto crítico es la verificación de la versión de la instancia y el estado de la KB.

«Estamos en la nube» ya no es una respuesta suficiente. Los clientes con instancias alojadas exigen una prueba de salud del proveedor o de la instancia. Los clientes con instancias autoalojadas deben documentar la compilación tras aplicar la KB.

2. Verificar el destino Pre-Auth y la exposición a Internet

Investigaciones y fuentes de inteligencia sobre amenazas señalan la ruta Pre-Auth a través del endpoint assessment_thanks.do. Si la URL es accesible desde redes no confiables, se priorizan reglas WAF, registros (logging) y, en su caso, una restricción temporal hasta aplicar el parche correspondiente.

Un enfoque basado únicamente en firmas no es suficiente. Defused ha observado un gadget de escape de sandbox distinto al PoC público. La telemetría del endpoint y la detección de anomalías en el destino (Sink) son más relevantes que un filtro estático.

3. Leer el radio de explosión de cuentas de acceso e integración

El código en el contexto de la plataforma suele heredar los permisos de usuarios de integración, cuentas cercanas a MID y aplicaciones OAuth. El inventario de todas las integraciones con privilegios elevados determina qué sistemas serían accesibles tras un RCE exitoso: AD, controladores de cloud, sistemas de RRHH, tuberías de CI/CD.

El inventario no evita el exploit. Sin embargo, sí define qué secretos y relaciones de confianza se consideran comprometidos durante el incidente.

4. Registros: accesos pre-autenticación y actividad inusual de scripts

La búsqueda comienza con accesos inusuales en puntos de evaluación y endpoints de pre-autenticación. También se incluyen rutas de scripts fallidas y exitosas. Las acciones de administrador fuera de las ventanas de cambio conocidas deben incluirse en el filtro.

El período analizado debe cubrir al menos la primera ventana pública de investigación y parches. La ausencia de registros de aplicación es un hallazgo en sí mismo. En ese caso, quedan los registros de WAF, proxy inverso e identidad, incompletos pero mejor que nada.

5. Ventana de cambios y congelación de tickets en instancias autoalojadas sin parchear

Las instancias autoalojadas sin parchear que están expuestas a internet deben pasar al modo de emergencia. La aplicación de parches tiene prioridad sobre los despliegues de funciones. Las actualizaciones de plugins de riesgo no se ejecutan en paralelo. Una comunicación clara al responsable del servicio garantiza el proceso.

Una congelación sin un plan de parcheo no tiene efecto. El cambio requiere un procedimiento de reversión, una indicación en la instancia de prueba y la evidencia de la aplicación del boletín de seguridad (KB).

6. Actores externos: servidores MID, aplicaciones personalizadas y exportaciones de datos

La plataforma rara vez opera en solitario. Los servidores MID, los spokes del Integration Hub y las aplicaciones personalizadas con ámbito específico amplían las rutas de ejecución y de datos. Tras una explotación confirmada o sospechada, estos nodos deben incluirse en el mismo ámbito del incidente que la instancia principal.

No todo script personalizado representa una ruta de ejecución de código remoto (RCE) para la CVE-2026-6875. Este punto aborda la posible compromiso subsiguiente y la filtración de datos, no la causa raíz de la vulnerabilidad en el entorno aislado.

Qué hacer primero y qué después

Inmediatamente: Poner al día el entorno autoalojado hasta el nivel KB3137947, aclarar la exposición de los *pre-auth sinks*, y listar las integraciones de alto privilegio. En paralelo (entornos alojados): Verificar el estado de los parches del proveedor y la telemetría de las instancias. El fabricante no ha encontrado pruebas de la actividad observada en instancias alojadas, pero recomienda a todos los clientes mantener el nivel de parches actualizado. A continuación: Revisar los registros, rotar los secretos en las cuentas de integración si hay sospecha, y generar la documentación justificativa para el CISO y, si es necesario, cumplir con la obligación de notificación según la Directiva NIS2.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿El CVE-2026-6875 solo es relevante para instalaciones locales (self-hosted)?

Las soluciones alojadas en la nube conllevan un riesgo operativo más bajo, ya que el proveedor gestiona los plazos de parcheado. Las soluciones alojadas recibieron los parches a partir de abril. Sin embargo, el fabricante recomienda a todos los clientes mantenerse al día con las actualizaciones. Los clientes con soluciones alojadas deben verificar el estado, mientras que los usuarios de soluciones autoalojadas deben aplicar los parches y medir su exposición.

¿Qué significa exactamente «preautorización» en este contexto?

Los atacantes no necesitan una sesión válida de ServiceNow en el sink afectado. La complejidad del *escape gadget* puede ser elevada. La barrera de entrada «sin inicio de sesión» sigue siendo la diferencia decisiva frente a fallos de administración posteriores a la autenticación.

¿Bastan las reglas de WAF en lugar de parches?

Los WAF y las restricciones en los endpoints son medidas inmediatas sensatas. La solución del proveedor sigue siendo la solución definitiva. Defused describe un gadget distinto al PoC público; una firma basada únicamente en el PoC se queda corta.

¿ServiceNow ha confirmado una explotación activa?

Defused detecta actividad en entornos reales. ServiceNow declaró ante BleepingComputer que, hasta el momento, no ha encontrado pruebas de esta actividad en instancias alojadas en ServiceNow. El fabricante, a su vez, hace referencia a las actualizaciones disponibles. Ambas afirmaciones deben documentarse de forma paralela.

¿Qué papel desempeñan las integraciones tras un RCE?

Usted define el alcance del impacto: aprovisionamiento de AD, APIs de cloud, datos de RRHH y CMDB. Tras una explotación confirmada o altamente probable, las cuentas de servicio y las aplicaciones OAuth deben incluirse en el mismo incidente que la plataforma en sí.

Selección de la redacción

RecomendadoModelos de OpenAI hackean Hugging Face: qué revisar ahoraRecomendado¿Qué es SOAR? Definición, guiones y diferenciaciónRecomendadoPlugins de CoreDNS: DNS en clúster sin protección de

Más de la red MBF Media

Digital ChiefsPor qué la factura de la nube nunca disminuyecloudmagazinSanción DMA contra Google: 890 millones de euros