Un reciente incidente de seguridad relacionado con ServiceNow pone de manifiesto un riesgo significativo para las empresas que utilizan plataformas de gestión de flujos de trabajo en la nube y de servicios de TI. ServiceNow reveló que un fallo de software que afectaba a determinadas instancias de clientes permitía el acceso sin autenticación a los datos a través de un punto final de API vulnerable. Esta situación eludía de hecho los controles de autenticación, lo que permitía a terceros consultar los datos almacenados sin credenciales válidas.

La vulnerabilidad parece estar relacionada con un punto final de la API (según se informa, /api/now/related_list_edit/create) que estaba mal configurado, con la autenticación desactivada. Como resultado, cualquier parte que conociera el punto final podía intentar recuperar datos de las instancias afectadas. ServiceNow solucionó el problema el 5 de junio de 2026, aplicando requisitos de autenticación en el punto de extremo. Sin embargo, la empresa reconoció que ya se habían observado actividades anómalas antes de la corrección, y que se habían consultado con éxito algunos datos de instancias de clientes.

Aunque ServiceNow afirmó que la actividad observada estaba relacionada con investigadores de seguridad y notificaciones de recompensas por errores, más que con actores maliciosos confirmados, esta distinción no elimina el impacto en la seguridad. Desde el punto de vista de la defensa y la gestión de riesgos, el resultado sigue siendo el mismo: se produjo una exposición de datos a través de una vía no autenticada. Además, la empresa no especificó públicamente el alcance total de los clientes afectados, ni proporcionó información detallada sobre a qué tipos de datos se accedió en cada caso.

Esta vulnerabilidad es especialmente preocupante debido a la naturaleza de los datos que suelen almacenarse en entornos ServiceNow. Las instancias empresariales suelen contener información sensible relacionada con la seguridad y las operaciones, incluyendo tickets de servicio de TI, registros de empleados, datos de respuesta a incidentes, documentación interna y, potencialmente, credenciales incrustadas o tokens de API compartidos durante los flujos de trabajo de resolución de problemas. Los actores maliciosos suelen atacar los sistemas de soporte porque sirven como puntos de agregación de información contextual de gran valor que puede aprovecharse para ataques posteriores, como la escalada de privilegios, el movimiento lateral o el compromiso de la cadena de suministro.

La cronología del problema suscita una preocupación adicional desde el punto de vista de la inteligencia sobre amenazas. Según se informa, ServiceNow recibió en abril de 2026 una notificación confidencial de recompensa por errores que describía un problema similar, pero no implementó una actualización de seguridad hasta principios de junio, cuando la actividad dirigida a las instancias de los clientes ya había comenzado. Este lapso entre el descubrimiento y la corrección aumenta la probabilidad de que el conocimiento de la vulnerabilidad se haya extendido más allá de los investigadores de confianza, ya sea a través de un descubrimiento independiente o de una divulgación involuntaria.

Otro aspecto destacable es la posible variabilidad en la exposición. Aunque ServiceNow indicó que el problema afectaba principalmente a instancias de la versión de la plataforma «Australia» o a aquellas con cambios de configuración específicos, los informes de la comunidad sugieren un impacto más amplio en otras versiones. Esto plantea la posibilidad de que las configuraciones erróneas o los ajustes heredados entre entornos pudieran haber ampliado la superficie de exposición más allá de los límites inicialmente previstos.

Los indicadores de compromiso asociados a esta actividad incluyen solicitudes procedentes de la dirección IP 51.159.98.241 e intentos de acceso dirigidos al punto final de la API mencionado anteriormente. Aunque la atribución sigue sin estar clara, los defensores deben tratar cualquier indicio de acceso no autenticado a la API como sospechoso, independientemente de su origen.

Desde la perspectiva del panorama de amenazas, este incidente refuerza varias tendencias importantes. Las plataformas SaaS en la nube siguen representando objetivos centralizados de gran valor en los que una sola vulnerabilidad puede exponer a múltiples organizaciones simultáneamente. Las configuraciones erróneas de las API y los fallos en el control de acceso siguen siendo una de las principales causas de exposición de datos en entornos en la nube. Además, la dependencia de la seguridad gestionada por el proveedor no elimina la necesidad de controles de visibilidad, registro y validación por parte del cliente.

Qué debe hacer

Las organizaciones que utilicen ServiceNow deben realizar inmediatamente un análisis retrospectivo de los registros que abarque, como mínimo, desde principios de abril hasta mediados de junio de 2026, prestando especial atención a las solicitudes de API no autenticadas o anómalas. Cualquier intento de acceso que implique el punto final relevante o que se origine en indicadores conocidos, como 51.159.98.241, debe investigarse como un posible incidente de exposición de datos. Incluso si la actividad se atribuye a investigadores, los datos a los que se ha accedido deben considerarse potencialmente comprometidos.

Debe revisar todos los registros que puedan haber quedado expuestos a través de los flujos de trabajo de ServiceNow, especialmente los tickets de soporte, los registros de incidentes y las entradas de la base de conocimientos. Cualquier caso en el que se hayan compartido credenciales, claves API, tokens de autenticación o detalles de configuración sensibles debe desencadenar un proceso de rotación obligatorio. Esto incluye contraseñas, claves de cuentas de servicio, tokens OAuth y cualquier secreto incrustado en archivos adjuntos o notas.

Asegúrese de que el registro de acceso a la API esté totalmente habilitado y se conserve durante un periodo de tiempo adecuado en el futuro. Si el registro estaba deshabilitado o era insuficiente anteriormente, este incidente debe tratarse como una brecha en la capacidad de detección que requiere corrección. Considere la posibilidad de integrar los registros de ServiceNow en una plataforma SIEM o XDR centralizada para permitir la correlación con otras señales de seguridad.

Es fundamental verificar que todas las instancias de ServiceNow ejecutan la configuración parcheada y que ninguna personalización o configuración heredada anule los requisitos de autenticación en los puntos finales de la API. Se debe evaluar la desviación de la configuración, especialmente en instancias más antiguas o entornos con un alto grado de personalización.

Si le preocupa alguna de las amenazas descritas en este boletín o necesita ayuda para determinar qué medidas debe tomar para protegerse de las amenazas más importantes a las que se enfrenta su organización, póngase en contacto con su gestor de cuentas o, si lo prefiere, contáctenospara averiguar cómo puede proteger su organización.