Por Canuto  

ServiceNow confirmó un incidente de seguridad tras detectar actividad anómala vinculada a un punto final de API que, en ciertas circunstancias, permitía acceso no autenticado a instancias de clientes. La empresa ya aplicó una actualización de seguridad y abrió casos de soporte con los usuarios afectados, mientras administradores revisan registros en busca de señales de exposición.
***

  • ServiceNow dijo que atacantes explotaron una falla de acceso no autenticado en un endpoint de API para consultar tablas de instancias de clientes.
  • La actualización de seguridad fue aplicada el 5 de junio de 2026 y limitó el acceso al punto final solo a usuarios autenticados.
  • La compañía señaló que el problema afecta principalmente a clientes en la versión Australia de la plataforma o a instancias antiguas con ciertos cambios de configuración.

 

ServiceNow advirtió sobre un incidente de seguridad después de detectar actividad anómala relacionada con un defecto que, en ciertas circunstancias, podía permitir a un usuario no autenticado obtener más acceso del previsto a instancias de clientes. La compañía comunicó el problema a los clientes afectados mediante un boletín de soporte y casos de soporte directos.

De acuerdo con la información publicada por BleepingComputer, ServiceNow aplicó una actualización de seguridad a las instancias alojadas de clientes el 5 de junio de 2026. El cambio estuvo dirigido a un punto final de API cuya configuración fue modificada para restringir el acceso exclusivamente a usuarios autenticados.

El caso vuelve a poner el foco sobre un riesgo persistente en servicios empresariales basados en la nube. Cuando una plataforma centraliza tickets de soporte, flujos de trabajo, inventarios y documentación interna, una falla en autenticación puede abrir la puerta a información muy valiosa para atacantes, incluso si el acceso observado fue limitado a consultas de tablas.

ServiceNow no detalló públicamente cuáles fueron los datos específicos comprometidos durante los ataques. Sin embargo, este tipo de instancias suele concentrar información empresarial sensible, como tickets de soporte de TI, registros de empleados, documentación interna, inventarios de activos, reportes de incidentes de seguridad, datos de flujos de trabajo y detalles de configuración de sistemas y servicios corporativos.

Qué ocurrió y cómo respondió la empresa

En su boletín de soporte, ServiceNow indicó que el 5 de junio de 2026 aplicó una actualización de seguridad a las instancias alojadas de clientes. Según la propia empresa, la actualización abordó un problema que podía permitir a un usuario no autenticado obtener un nivel de acceso mayor al que se pretendía bajo ciertas condiciones.

La compañía explicó que el ajuste de seguridad cambió la configuración del endpoint de la API para limitar su uso a usuarios autenticados. También confirmó que atacantes explotaron la falla para consultar con éxito tablas pertenecientes a instancias de clientes, un punto clave porque confirma que el problema no fue solo teórico.

ServiceNow añadió que abrió casos de soporte con los clientes que considera afectados. Según el aviso, si una organización no recibió una notificación directa, la empresa no cree que haya sido impactada por el incidente. Ese criterio sugiere una evaluación caso por caso, aunque no aclara cuántos clientes están involucrados.

Hasta el momento, la empresa no ha revelado públicamente detalles técnicos completos sobre la vulnerabilidad. Tampoco había respondido antes de la publicación a preguntas sobre desde cuándo ocurría la actividad, qué originó exactamente el problema y si hubo robo de información de clientes.

La compañía también señaló que sigue evaluando si asignará un CVE al incidente. Esa decisión suele ser relevante para equipos de seguridad y cumplimiento, ya que facilita la trazabilidad formal del fallo y su gestión en programas corporativos de respuesta a vulnerabilidades.

El endpoint bajo sospecha y los indicadores de compromiso

Aunque ServiceNow no divulgó la mecánica técnica en detalle, administradores que discutieron el incidente en Reddit apuntaron a un endpoint REST ubicado en /api/now/related_list_edit/create. Según uno de los comentarios citados en la cobertura, el punto final estaba configurado con requires_authentication=false, lo que habría permitido solicitudes no autenticadas para acceder a datos de la instancia.

Esos mismos comentarios sostienen que la actualización aplicada el viernes cambió la configuración a requires_authentication=true. Si esa interpretación es correcta, el problema habría residido en un control de acceso insuficiente en un endpoint expuesto, una clase de error especialmente delicada en plataformas empresariales ampliamente integradas con procesos internos.

Varios administradores también compartieron posibles indicadores de compromiso. Entre ellos destacó la dirección IP 51.159.98.241, asociada a solicitudes de API que habrían apuntado al endpoint vulnerable. Por ese motivo, se recomendó a otros equipos revisar los registros de ServiceNow en busca de llamadas a /api/now/related_list_edit.

La recomendación de revisar logs no es menor. En incidentes de este tipo, los registros de API son esenciales para reconstruir el alcance, determinar qué tablas fueron consultadas y establecer si información sensible, como credenciales o tokens, pudo haber quedado expuesta a terceros no autorizados.

ServiceNow aconsejó precisamente a los administradores revisar los registros por solicitudes dirigidas al endpoint mencionado, con especial atención a la IP 51.159.98.241. Además, las organizaciones potencialmente afectadas deberían examinar tickets y registros expuestos, rotar credenciales o tokens compartidos a través de flujos de soporte y verificar que el registro de API esté habilitado.

Qué tipo de información podría estar comprometida

Aunque la empresa no precisó qué datos fueron accedidos, el contenido habitual de una instancia de ServiceNow ayuda a dimensionar la gravedad potencial. Estas plataformas suelen funcionar como un eje operativo de la organización, donde convergen solicitudes de soporte, incidencias, cambios de infraestructura y documentación técnica.

Eso implica que un atacante podría encontrar desde nombres de empleados y inventarios de activos hasta procedimientos internos y datos de configuración. En ciertos casos, también pueden aparecer detalles de incidentes de seguridad previos, elementos muy útiles para mapear defensas, detectar debilidades repetidas y preparar ataques posteriores.

Un riesgo adicional está en los tickets de soporte. Como recordó la cobertura original, los casos de soporte se han convertido en un objetivo cada vez más atractivo para actores maliciosos, ya que pueden incluir credenciales, tokens de API, documentación interna y secretos de autenticación que fueron compartidos durante procesos de resolución de problemas.

Para empresas que operan infraestructura crítica o manejan grandes volúmenes de datos, incluso una exposición parcial puede derivar en costos altos de remediación. A veces el daño principal no surge de la consulta inicial, sino del uso posterior de credenciales, información contextual o accesos heredados descubiertos en sistemas de soporte.

Versiones afectadas y próximos pasos

El boletín de soporte indicó que el problema afecta principalmente a clientes que usan la versión de plataforma Australia. También mencionó a clientes en versiones anteriores a Australia que realizaron ciertos cambios de configuración en sus instancias, aunque no precisó públicamente cuáles fueron esos cambios.

Esa aclaratoria sugiere que la exposición no habría impactado de forma uniforme a toda la base de clientes. Sin embargo, también plantea una dificultad operativa, ya que algunas organizaciones podrían no saber de inmediato si modificaciones históricas en la configuración las colocan dentro del grupo de riesgo descrito por la empresa.

En este contexto, la señal más importante para los clientes es si recibieron o no un caso de soporte directo por parte de ServiceNow. Aun así, para organizaciones con altos requisitos de cumplimiento, la práctica más prudente sigue siendo revisar logs, validar configuraciones y renovar cualquier secreto o token que haya circulado por tickets o flujos administrativos.

El incidente llega en un momento en que la seguridad de plataformas de soporte y operación gana más atención entre empresas, reguladores y equipos de ciberdefensa. A medida que más procesos críticos se concentran en software empresarial en la nube, los fallos de control de acceso dejan de ser errores aislados y se convierten en riesgos sistémicos.

Por ahora, ServiceNow mantiene la investigación en curso y no ha aclarado si publicará un CVE. Mientras tanto, la prioridad para los clientes es determinar si hubo consultas no autorizadas en sus instancias, medir el tipo de información expuesta y cerrar cualquier vía secundaria de acceso derivada del material que pudo haber quedado al descubierto.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados