ServiceNow Patches an Unauthenticated API Endpoint That Let Customer Instance Tables Be Queried Without Credentials

ServiceNow fixed a REST API endpoint that shipped without authentication, after confirming a subset of customer instances were queried. It has not assigned a CVE.

Verified pipeline

Sources: 2 Publisher: signed Contributor: signed Hash: 19d6a5bcc7 View

Editor's Note · June 13, 2026

Correction:

The article quotes Cory Michal of AppOmni as saying the issue involved "An unauthenticated, internet-facing ServiceNow API endpoint that could be accessed without authentication when certain conditions were present." In the cited CSO Online report, only "An unauthenticated, internet-facing ServiceNow API endpoint" is a direct quotation from Michal; the clause "that could be accessed without authentication when certain conditions were present" is CSO Online's own narration and was not spoken by Michal.

Clarification:

The article renders ServiceNow's statement as one continuous quote: "We have reason to believe the observed activity can be attributed to security researchers or customers conducting their own research. However, our investigation is ongoing." The cited CSO Online report presents these as two separate quoted fragments — "...conducting their own research," and "Our investigation is ongoing, however, and subject to additional validation" — and the article omits the closing phrase "and subject to additional validation" and relocates the word "however." The wording is otherwise verbatim and the meaning is unchanged.

Overview

ServiceNow has disclosed a security incident and deployed a fix after a REST API endpoint on its enterprise platform was found to be reachable without authentication. According to BleepingComputer, the vulnerable endpoint was /api/now/related_list_edit/create, and the security update set its requires_authentication flag to true after it had previously accepted unauthenticated requests. ServiceNow described the underlying issue as one that “could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended,” per BleepingComputer.

The company has confirmed that customer data was queried but, as of its latest advisory, attributes the activity primarily to security research rather than malicious actors. It has not assigned a CVE.

What We Know

ServiceNow applied the security update to hosted customer instances on June 5, 2026, according to CSO Online, which reported that the fix was distributed as support bulletin KB3067321 for hosted customers and KB3067372 for self-hosted deployments. The misconfiguration sat in a Scripted REST resource that shipped with requires_authentication = false, as reported by CSO Online, meaning requests could reach the endpoint without valid credentials.

In its advisory, ServiceNow stated: “Based on our investigation to date, it appears that a subset of customer instances were queried successfully as part of this activity,” according to CSO Online. On the question of who was responsible, the company said: “We have reason to believe the observed activity can be attributed to security researchers or customers conducting their own research. However, our investigation is ongoing,” again per CSO Online.

The timeline drew scrutiny because the exposure was not new to ServiceNow. The company disclosed that it had received a confidential bug bounty submission describing a similar issue on April 22, 2026, but did not apply a security update until June 5, after activity targeting customer instances reportedly began days earlier, according to BleepingComputer. Administrators were advised to review logs for requests to the vulnerable endpoint, including requests from the IP address 51.159.98.241, as reported by BleepingComputer.

Reporting on which deployments were exposed points to ServiceNow’s Australia platform release being impacted, along with customers on earlier releases who had made certain configuration changes, according to BleepingComputer. CSO Online similarly reported that only the Australia release was understood to be affected, based on private security notifications ServiceNow sent to customers.

Updating its position after the initial disclosure, ServiceNow published an advisory stating it believes the observed activity was likely tied to security researchers or customer-led research associated with bug bounty submissions rather than malicious threat actors, according to BleepingComputer.

What We Don’t Know

ServiceNow has not publicly specified which data was accessed in the instances that were queried. ServiceNow instances commonly hold IT support tickets, employee records, internal documentation, and asset inventories, but the company has not detailed the contents of the affected tenants, per BleepingComputer.

The attribution also remains unsettled. Cory Michal, CISO of AppOmni, characterized the problem as “An unauthenticated, internet-facing ServiceNow API endpoint that could be accessed without authentication when certain conditions were present,” according to CSO Online, and the same report noted that security experts urged organizations to review at least 90 days of logs before drawing conclusions about scope. ServiceNow’s own advisory acknowledged that its investigation is ongoing, per CSO Online.

Finally, ServiceNow has not assigned a CVE identifier to the issue. The fix was delivered through KB support bulletins rather than a numbered vulnerability advisory, according to CSO Online.