Un aviso reciente, con una lista concreta de versiones

El Centro Canadiense de Ciberseguridad publicó el 25 de septiembre de 2026 el aviso AV26-963 sobre vulnerabilidades en ServiceNow AI Platform. Su alcance práctico es claro: administradores y equipos de seguridad deben identificar la versión de su instancia y contrastarla con los niveles de corrección enumerados por el proveedor. El aviso del organismo canadiense se refiere a información vigente al 24 de septiembre. No es, por sí solo, una confirmación de que una instancia determinada esté expuesta o haya sido comprometida.

La alerta es útil precisamente porque separa el nombre comercial de la plataforma de las ramas de versión afectadas. No basta con saber que una organización utiliza ServiceNow ni con ver que su entorno pertenece a una familia reciente: hay que revisar la rama y el parche aplicado. La decisión operativa depende de esa comparación, y las organizaciones con entornos alojados, autogestionados o administrados por terceros deberían confirmar quién aplica la actualización y cómo se acredita.

Qué ramas deben compararse con los parches

El aviso lista versiones anteriores a tres niveles de Australia: Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3 y Patch 5. Para Yokohama, establece como umbral Yokohama Patch 13 Hot Fix 5a. En Zurich, menciona tres referencias distintas: Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32 y Patch 11 Hot Fix 3. El formato «anteriores a» indica que el administrador debe comparar su versión exacta con el umbral correspondiente, no asumir que cualquier instalación de la misma familia está corregida.

La lista tiene una cautela importante: el aviso no presenta un único número de parche que se aplique a todas las ramas. Además, Zurich incluye varias rutas de actualización, por lo que conviene evitar convertir esa enumeración en una regla simplificada del tipo «instalar el parche más alto». La versión de origen, el calendario de mantenimiento y la modalidad del servicio pueden cambiar cuál es el camino apropiado. Si el inventario interno no permite establecer con seguridad la rama y el hot fix, debe pedirse confirmación al administrador responsable o al soporte del proveedor.

Cinco identificadores CVE, pero no cinco historias técnicas completas

La alerta italiana del CSIRT de Toscana, que remite al boletín de ServiceNow, enumera cinco identificadores: CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860 y CVE-2026-13016. También caracteriza el conjunto como dos fallos críticos y tres de gravedad alta. Esta descripción ayuda a entender que la lista de versiones responde a varias vulnerabilidades, pero no sustituye la lectura del aviso técnico de cada CVE ni determina por sí sola la exposición de una configuración particular.

Entre los registros accesibles durante esta verificación, CVE-2026-86857 se describe como un problema de autorización que podría permitir a una persona autenticada acceder a datos de AI Platform para los que no tiene autorización. CVE-2026-86859 se describe como un problema de autorización con posible acceso no autenticado a datos. Esos casos muestran por qué el control de acceso y la exposición de información son asuntos relevantes; no justifican, sin embargo, atribuir esos mismos detalles a los otros tres identificadores. No conviene inferir técnicas, condiciones o consecuencias específicas para cada CVE a partir de la lista agregada del aviso.

Qué se sabe sobre explotación y alcance

En la descripción del registro de CVE-2026-86857, ServiceNow indica que desplegó una actualización en instancias alojadas y que proporcionó la actualización a socios y clientes autogestionados. El mismo texto dice que la empresa no tenía conocimiento de explotación maliciosa contra instancias de ServiceNow en el momento de publicarse el registro. Esa formulación debe conservar su alcance temporal: describe lo que el proveedor conocía entonces, no demuestra que nunca haya existido explotación ni garantiza que no aparezca información posterior.

El aviso canadiense enumera producto y versiones, pero no informa de incidentes concretos en organizaciones usuarias ni permite medir cuántas instancias estarían afectadas. Tampoco debe confundirse «vulnerabilidad publicada» con «intrusión confirmada». Para valorar un caso específico hacen falta datos de la propia instancia, registros y la confirmación del proveedor; con las fuentes revisadas no es posible afirmar que haya explotación activa de estos fallos.

Lista de comprobación para operaciones y seguridad

Primero, identifique la modalidad del servicio y quién se ocupa de mantenerlo. Si la instancia está alojada por ServiceNow, solicite confirmación de que la actualización correspondiente fue aplicada a ese entorno y registre la respuesta, junto con la fecha. Si la instalación es autogestionada o la mantiene un socio, compare la rama y el nivel de parche exactos con la lista del aviso y coordine la actualización según las instrucciones de ServiceNow. El texto público recomienda revisar los enlaces indicados y aplicar las actualizaciones necesarias; no ofrece una ruta de consola universal que pueda darse por válida para todos los despliegues.

Después, documente la evidencia de cierre: rama, parche o hot fix, fecha de aplicación y responsable de la validación. Si la organización mantiene varios entornos —por ejemplo, producción, pruebas o instancias separadas por unidad— compruebe cada uno, en lugar de extrapolar el estado de una instalación a las demás. Para cualquier versión que parezca anterior a los umbrales, trate el asunto como pendiente hasta que soporte confirme el camino de mitigación. Si la versión ya alcanza el nivel indicado, conserve evidencia de esa comparación; no la interprete automáticamente como evaluación completa de otros riesgos o configuraciones.

El dato clave es la versión exacta, no una suposición

La conclusión verificable al 26 de septiembre de 2026 es acotada: el Centro Canadiense de Ciberseguridad publicó una alerta sobre ServiceNow AI Platform con ramas y niveles de parche concretos; un resumen de CSIRT enumera cinco CVE; y los registros consultados describen dos de ellos como problemas de autorización y acceso a datos. Para un administrador, la acción razonable es comparar el nivel exacto de cada instancia con la lista, confirmar la cobertura con ServiceNow cuando corresponda y aplicar las actualizaciones pertinentes según el boletín del proveedor.

Quedan límites informativos. La alerta no detalla por sí sola los componentes técnicos de cada uno de los cinco CVE, el efecto de cada uno por separado ni el estado de explotación observado en todas las instancias. La falta de esos detalles en el aviso público no prueba que no existan; simplemente impide afirmarlos aquí. Hasta que el proveedor o los registros técnicos aporten información adicional, la prioridad no es especular sobre incidentes, sino verificar el estado de parche de cada despliegue y dejar constancia de la confirmación.