ServiceNow is notifying customers after discovering and remediating a vulnerability that could have exposed data via an unauthenticated API endpoint on affected instances.

The issue emerged publicly after customers began discussing security notifications from ServiceNow and reports of suspicious activity linked to their environments.

According to the company’s advisory, the vulnerability was initially reported through ServiceNow’s bug bounty program in April, prompting an investigation and subsequent security updates. ServiceNow said hosted customers received a security update (KB3067321)  on June 5, while guidance (KB3067372) was issued for self-hosted deployments.

The flaw appears to have affected tenants running specific versions and configurations. Cory Michal, CISO at SaaS and AI security company AppOmni, said the issue involved “An unauthenticated, internet-facing ServiceNow API endpoint” that could be accessed without authentication when certain conditions were present.

“In practical terms, anyone who knew the endpoint URL and how to structure the request could access data from the affected ServiceNow tenant without authenticating first,” Michal said.

Because ServiceNow often stores IT service requests, employee information, and internal security data, unauthorized access to customer instances can pose significant risks to enterprises.

The advisory said that suspicious activity highlighted in security notifications sent to customers can, so far, be linked to security researchers investigating the vulnerability.

An API endpoint from a specific release was impacted

While ServiceNow’s advisory offered few technical details about the vulnerability itself, customers discussing the issue on Reddit have mentioned the affected endpoint as “/api/now/related_list_edit/create,” an API that could allegedly be queried without authentication under certain circumstances. The API shipped with “requires_authentication = false”.

The same discussions point to only ServiceNow’s Australia release being impacted, as ServiceNow reportedly told customers through private security notifications. This suggested that release-specific changes may have played a role in the exposure.

However, customers were far from convinced that the issue was confined to a single release. Several participants speculated that older releases with particular configurations may also have been vulnerable.

“Don’t assume you’re safe just because you’re on a different release,” one of them commented. Speaking of the impacted API, the user added, “That’s a config flag, not a release-specific code change. Worth pulling up your own instance’s Scripted REST API table and auditing any resources where that checkbox is unchecked, especially anything that hasn’t been touched since before 2022.”

Researchers, attackers, or both?

The important question surrounding the incident is whether the activity observed against affected ServiceNow environments was solely the work of security researchers or whether malicious actors may also have taken advantage of the flaw.

ServiceNow confirmed that unauthorized access could all be attributed to research attempts. “We have reason to believe the observed activity can be attributed to security researchers or customers conducting their own research,” the company said, adding a “however”. “Our investigation is ongoing, however, and subject to additional validation.”

Michal urged caution before assuming all observed activity was benign.

“The attribution question is less clear,” he said. “At least one system publicly associated with exploitation of this vulnerability appears to have targeted tenants of other SaaS platforms with similar unauthenticated-access weaknesses. So while researcher activity clearly occurred, I would be cautious about saying all observed activity was benign research until the investigation is complete.”

Customers urged to investigate, not just patch

While ServiceNow says fixes and mitigations are available, Michal warns that applying updates should be only the first step.

According to him, organizations should definitely verify that the June 5 security update has been applied or that recommended mitigations have been implemented for self-hosted deployments. Just as importantly, they should also examine historical logs for evidence of exploitation.

“Review ServiceNow access and transaction logs for known IoC, unauthenticated requests to the affected API endpoint, and unusual table or field queries, ideally covering at least the last 90 days,” he said. “If suspicious activity is found, determine which data was accessed and treat it as an incident investigation, not just a patching exercise.”

ServiceNow reassured customers that mitigations have been applied and that it continues to investigate the incident internally. “Based on our investigation to date, it appears that a subset of customer instances were queried successfully as part of this activity, and dedicated support cases have been created for impacted customers,” the company noted in its advisory.

Associated activities from confirmed researcher IP addresses were investigated for possible sharing, using, or retention of data. Involved researchers reportedly told ServiceNow “they queried tables and fields only for purposes of validating their finding and submitting bug bounty reports.”