ServiceNow corrige tres fallos 10.0: la nube ya está parcheada, el servidor propio no

ServiceNow divulgó el 27 de agosto de 2026 tres vulnerabilidades CVSS 10.0 en ServiceNow AI Platform: CVE-2026-18885, CVE-2026-18886 y CVE-2026-74820. La compañía ya actualizó las instancias que aloja, mientras que las instalaciones autogestionadas no quedan parcheadas automáticamente: cada operador debe aplicar la versión corregida.

Los fallos permiten, bajo determinadas condiciones, ejecutar código, elevar privilegios o enviar instrucciones SQL sin autenticación ni interacción del usuario. El aviso de seguridad de ServiceNow señalaba al publicarse que la empresa no tenía constancia de explotación maliciosa contra sus instancias.

Tres fallos distintos con acceso previo innecesario

Las vulnerabilidades afectan a componentes y operaciones diferentes, aunque comparten la puntuación máxima asignada por ServiceNow bajo CVSS 4.0. El desglose técnico de The Hacker News recoge para las tres un ataque accesible por red, de baja complejidad, sin privilegios previos y sin intervención de la víctima.

• CVE-2026-18885 — inyección de código. Afecta a GraphQL Composite Data API. Un atacante no autenticado podría ejecutar código arbitrario y acceder a datos de la instancia o modificarlos.
• CVE-2026-18886 — control de acceso incorrecto. Reside en el procesador de carga de imágenes de configuración del sistema. Podría permitir que un usuario no autenticado cree o altere datos de la instancia y eleve sus privilegios.
• CVE-2026-74820 — inyección SQL. Se alcanza mediante una cláusula dinámica ORDER BY del esquema. Podría permitir la ejecución de instrucciones SQL arbitrarias contra la base de datos subyacente.

La puntuación 10.0 no demuestra que ya exista una campaña de ataques. Describe la combinación de accesibilidad y consecuencias potenciales calculada por el fabricante: ninguno de los tres escenarios exige primero obtener una cuenta válida, y un ataque exitoso podría afectar a la confidencialidad, integridad y disponibilidad.

Qué ramas aparecen en la relación de versiones corregidas

El aviso comprende las familias Xanadu, Yokohama, Zurich y Australia. La compilación adecuada depende de la rama de mantenimiento; por tanto, no basta con comprobar el nombre general de la versión.

• Xanadu: Patch 11 Hot Fix 7a.
• Yokohama: Patch 12 Hot Fix 3b o Patch 13 Hot Fix 4, según la rama instalada.
• Zurich: Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m para la rama m, Patch 10 Hot Fix 3 para la estándar, Patch 11 o Patch 12.
• Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 o Patch 5, conforme a la línea de mantenimiento.

Hay una salvedad en Australia: el registro de CVE-2026-18886 marca como desconocido el estado de las versiones anteriores a Australia Patch 5, mientras que los otros registros las clasifican como afectadas. Esa diferencia impide tratar toda la lista como un único umbral universal; el operador debe contrastar su compilación con el registro específico de cada CVE.

La ruta cambia entre la nube y la autogestión

En una instancia alojada por ServiceNow, la corrección fue desplegada por la propia compañía. La tarea del cliente es verificar en los datos de versión o en su canal de soporte que su instancia recibió la actualización administrada; el título no significa que todas las instalaciones propias sigan vulnerables, sino que ServiceNow no instala allí el parche por el operador.

En una instancia autogestionada —incluidas las administradas por un socio— disponer del paquete no equivale a haberlo instalado. El responsable debe identificar la familia y la rama exactas, comparar la compilación en producción con la versión corregida correspondiente y completar el despliegue mediante su procedimiento de cambios.

La distinción importa porque “nube parcheada” describe una acción ya realizada por ServiceNow, mientras que “servidor propio no” describe la ausencia de actualización automática. Una organización que ya haya instalado manualmente la corrección puede estar protegida; una que solo haya recibido el aviso todavía debe confirmar su estado.

Integraciones y cuentas privilegiadas amplían la revisión

La comprobación no debería limitarse al número de compilación. ServiceNow puede concentrar API, flujos empresariales, credenciales de integración y cuentas técnicas con permisos elevados, de modo que una actividad sospechosa dentro de la plataforma también puede afectar a sistemas conectados.

El análisis de CSO sobre las integraciones afectadas recomienda inventariar API, conexiones externas y cuentas de servicio privilegiadas, además de revisar solicitudes inusuales a las funciones implicadas. Entre las señales propuestas figuran cambios administrativos inesperados, creación o modificación inexplicable de registros, comportamiento anómalo de cuentas técnicas y accesos atípicos a datos sensibles.

En entornos autogestionados, esa revisión puede abarcar la actividad anterior a la instalación y continuar después del cambio. En las instancias alojadas, el parche administrado cierra la exposición conocida del software, pero no explica por sí solo cualquier anomalía registrada antes de la actualización.

El estado confirmado al publicarse los avisos es limitado pero claro: ServiceNow no había observado explotación maliciosa de estos tres fallos y las coberturas iniciales no habían localizado código público para explotarlos. La ausencia de explotación conocida no demuestra que nunca hubiera intentos; por ahora, la diferencia operativa decisiva sigue siendo si ServiceNow ya actualizó la instancia alojada o si un operador propio todavía debe instalar y verificar la corrección.

Lee también:

• Zoomsday tomaba un equipo sin clics: la actualización que cierra tres fallos
• Mythos 5 busca fallos sin quedar abierto: Anthropic limita lo que entrega
• Cloudera lleva la IA hasta los datos que no pueden ir a la nube