El aviso publicado el 25 de septiembre de 2026 sobre cinco vulnerabilidades en ServiceNow AI Platform exige revisar versiones, permisos y exposición de las instancias empresariales. El Centro para la Seguridad en Internet (CIS) advierte de la posibilidad de acceso no autorizado bajo determinadas condiciones y enumera correcciones por rama. No comunica explotación activa. Para organizaciones colombianas que usan ServiceNow, la prioridad es confirmar qué instancias están afectadas, aplicar el parche apropiado y validar que los permisos de aplicaciones, usuarios y agentes funcionan como se espera.

Qué se publicó y qué no se ha confirmado

El aviso de CIS/MS-ISAC reúne CVE-2026-86857, CVE-2026-86858, CVE-2026-13016, CVE-2026-86859 y CVE-2026-86860. Las describe como fallas que podrían permitir acceso no autorizado en la plataforma de IA de ServiceNow. La publicación facilita una acción inmediata de inventario y actualización, pero no equivale a una declaración de que todas las instancias fueron atacadas. El reporte no aporta una lista de víctimas colombianas ni una campaña dirigida al país.

Es importante separar tres conceptos: vulnerabilidad, exposición y compromiso. La primera es un defecto documentado en versiones concretas; la segunda depende de la instalación y de su configuración; el tercero requiere evidencia de acciones no autorizadas. La existencia de una CVE no establece automáticamente que hubo extracción de datos. Este orden evita tanto la falsa tranquilidad de una instalación sin verificar como mensajes alarmistas que atribuyen incidentes sin prueba.

Versiones y ruta de corrección

El aviso señala versiones anteriores a Yokohama Patch 13 Hot Fix 5a, Zurich Patch 10 Hot Fix 4a y Australia Patch 2 Hot Fix 4b, con referencias específicas a familias y compilaciones. La tabla original y el artículo de soporte de ServiceNow deben gobernar la decisión final, porque una etiqueta general de rama no basta para identificar una instancia corregida. Pida al administrador número de compilación, parche, fecha de aplicación y evidencia de la versión que está sirviendo tráfico.

Puede haber instancias de producción, desarrollo, pruebas, demostración y continuidad con ritmos de actualización distintos. Incluya cada una en la revisión. Una aplicación clonada o un entorno usado por un integrador conserva datos y permisos que pueden ser relevantes. Si el fabricante administra parte del servicio, documente qué corrección corresponde al proveedor y qué configuraciones, roles o extensiones siguen siendo responsabilidad del cliente.

Por qué el acceso no autorizado preocupa en una plataforma de IA

Una plataforma de flujos empresariales reúne solicitudes, aprobaciones, conocimiento interno e integraciones. Las funciones de IA pueden acceder a información para resumirla o ejecutar acciones según sus permisos. El alcance real de un fallo depende de qué capacidades están activadas, qué datos pueden consultar y si las verificaciones de autorización se realizan en cada paso. No se debe asumir que la IA tiene control total de la organización; tampoco basta con comprobar que el usuario humano tiene un rol limitado si el servicio opera con una identidad más amplia.

Revise identidades de agentes, conectores, cuentas técnicas y permisos heredados. Pregunte qué acciones requieren aprobación humana, qué registros permiten reconstruir una respuesta generada y qué fuentes alimentan una automatización. En un entorno de gestión de servicios, una consulta indebida a tickets puede revelar información operativa; una acción indebida en un flujo puede cambiar el estado de una solicitud. Son escenarios que deben evaluarse en la instalación concreta, no hechos atribuidos por el aviso a una empresa específica.

Inventario que sí permite decidir

Para cada instancia registre URL, región de alojamiento, responsable, rama, versión exacta, módulos de IA, integraciones, datos tratados, usuarios externos y método de actualización. Clasifique los flujos por impacto: atención al cliente, recursos humanos, operaciones, seguridad, compras o servicios internos. La clasificación permite ordenar correcciones y pruebas funcionales sin tratar todas las instancias como idénticas.

Incluya las conexiones con directorio corporativo, herramientas de colaboración, repositorios documentales y sistemas de tickets. Una autorización en ServiceNow puede depender de grupos sincronizados desde otro sistema. El equipo de identidad debe participar en las pruebas: si se ajusta una política sin comprender la sincronización, una cuenta podría conservar un privilegio anterior o perder acceso legítimo. El registro debe indicar quién aprobó cada excepción.

Plan de trabajo para las primeras horas

Abra un caso interno con un dueño de servicio y una fecha de revisión. Confirme si las versiones afectadas están presentes y coteje la guía de ServiceNow con el aviso de CIS. Preserve configuración y registros relevantes, programe el cambio y pruebe primero en un entorno representativo cuando el calendario lo permita. Aplique el parche oficial, verifique la compilación efectiva y ejecute una prueba de acceso permitida y otra denegada para cada flujo crítico.

Si no es posible corregir una instancia de inmediato, limite accesos y funcionalidades según el consejo del proveedor y el impacto del negocio. Una restricción temporal debe quedar documentada con fecha de expiración. No la presente como un parche: puede reducir superficie, pero no cambia el código vulnerable. Eleve la excepción al responsable del riesgo y establezca una ventana de actualización comprobable.

Cómo buscar señales sin asumir un incidente

Revise cambios de roles, accesos a registros fuera de las funciones habituales, ejecuciones de agentes con privilegios inesperados y modificaciones de conectores. Compare eventos con la línea base de su organización y con la ventana en que la instancia ejecutó una versión afectada. Un evento de acceso denegado puede demostrar que un control funcionó; un acceso permitido fuera de perfil merece investigación. Correlacione usuario, identidad de servicio, acción, recurso y momento.

Si aparecen indicios, preserve registros originales, identifique las acciones posteriores y delimite la información potencialmente expuesta. Evite borrar automatizaciones o rotar todas las credenciales antes de capturar evidencia cuando ello impida reconstruir hechos. La contención y la preservación deben coordinarse. El Análisis Forense Digital puede ayudar a establecer el alcance de una actividad confirmada.

Preguntas para proveedor e integrador

Si un tercero administra ServiceNow, solicite un reporte por instancia: versión anterior, corrección aplicada, fecha, resultado de prueba, estado de conectores y cobertura de logs. Pregunte quién revisará los eventos de la ventana previa y quién decide una comunicación si se confirma exposición de datos. El proveedor de la plataforma, el integrador que configuró flujos y el cliente que asignó permisos tienen responsabilidades diferentes; el cierre exige evidencia de cada uno.

Los acuerdos de servicio deberían incluir un mecanismo para avisos urgentes, acceso a los registros necesarios y un contacto que pueda autorizar cambios. Un correo genérico que diga «estamos al tanto» no permite saber si su instancia está corregida. Pida una respuesta delimitada a activos y fechas, y conserve la confirmación con el expediente del cambio.

Lectura para empresas colombianas

La relevancia local consiste en el uso de una plataforma global para procesos de organizaciones colombianas. Las fuentes citadas no acreditan ataques en Colombia. Un banco, empresa de servicios, entidad pública o proveedor tecnológico debe evaluar su propia arquitectura y su propia evidencia. También debe determinar si la instancia maneja datos personales o información contractual cuya exposición tendría consecuencias específicas para su actividad.

La dirección puede pedir cuatro respuestas verificables: qué instancias tenemos, cuáles ejecutaron versiones afectadas, cuándo se corrigieron y qué se observó en los registros. Un Análisis de Vulnerabilidades ayuda a ordenar exposición y seguimiento; una revisión de Ethical Hacking autorizada puede comprobar límites de permisos en flujos seleccionados. La actualización del fabricante sigue siendo prioritaria.

Qué debe quedar instalado como práctica

Convierta la respuesta en un ciclo de mantenimiento: propietario por instancia, inventario de conectores, revisión periódica de permisos, pruebas de regresión y retención de registros. Antes de activar un nuevo agente o flujo de IA, establezca qué datos lee, qué acciones ejecuta, con qué identidad y cómo se revoca ese acceso. Documente quién acepta riesgos residuales y cuándo deben revisarse.

Prepare una prueba sencilla de abuso de permisos dentro de un entorno autorizado: un usuario de un área intenta consultar un registro que pertenece a otra y un agente con un propósito definido intenta ejecutar una acción fuera de su alcance. El resultado esperado debe ser denegación con registro. Una prueba así no reproduce necesariamente las CVE; valida que los controles de negocio alrededor de la plataforma limitan daños si aparece otro defecto.

Validación funcional y de seguridad

Después del parche, seleccione flujos que representen información de distintas áreas. Un empleado de atención debería acceder a sus solicitudes autorizadas y recibir denegación al intentar consultar un expediente de recursos humanos. Un agente de IA con permiso para resumir un ticket no debería adquirir permiso para aprobar cambios o exportar registros por esa sola función. Estas pruebas deben efectuarse con cuentas y datos de ensayo, bajo un alcance acordado y con resultados registrados.

La prueba debe incluir integraciones que crean o leen registros mediante cuentas técnicas. Un parche que corrige una ruta pero rompe una conexión puede provocar que un equipo restaure una configuración insegura bajo presión. Prepare criterios de aceptación y reversión antes del cambio. Si se requiere una excepción temporal, determine duración, responsable y control de monitoreo. La seguridad duradera depende de que el servicio continúe operando con permisos correctos.

Conserve una matriz de roles antes y después. La comparación permite detectar cambios introducidos por personalización, clonación de instancias o sincronización de grupos. Al cerrar el caso, resuma qué CVE y ramas se revisaron, qué instancias quedaron fuera de alcance y cuándo serán verificadas. Una conclusión que cubre solo producción debe decirlo expresamente; un entorno de prueba con datos reales puede tener un impacto significativo.

Preguntas frecuentes

¿El aviso confirma explotación activa?

No. CIS advierte del potencial de acceso no autorizado, pero no comunica explotación en este aviso. La prioridad se basa en versiones y exposición propias.

¿Un SaaS se actualiza sin acción del cliente?

La operación del fabricante puede incluir correcciones, pero el cliente debe confirmar versión efectiva, funciones afectadas, pruebas e integraciones. No dé por cerrado un cambio sin evidencia.

¿Basta con desactivar la IA?

Depende de módulos y versión. Una medida temporal solo debe aplicarse con evaluación del proveedor y un plan de parcheo; no sustituye la corrección.

Cierre el hallazgo con evidencia

Fuentes y límites

La publicación describe vulnerabilidades y versiones. Los escenarios operativos son criterios de evaluación, no evidencia de afectación de una entidad colombiana.