ServiceNow API Flaw Exposed Federal Customer Data

Server room with rows of dark rack-mounted equipment and blinking status lights — Photo via Unsplash

TL;DR: ServiceNow disclosed on June 9, 2026 that attackers had exploited an unauthenticated access flaw in one of its API endpoints, allowing them to query data from customer instances without credentials ^[1]. The vulnerable endpoint, identified by ServiceNow administrators as /api/now/related_list_edit/create, was configured with requires_authentication=false, and the fix was to flip the setting to true ^[1]. The company received a confidential bug bounty submission describing a similar issue on April 22, 2026, but did not deploy a security update to hosted customer instances until June 5, six weeks later, after activity targeting customer instances had already been observed ^[1]. ServiceNow is the IT service management platform that runs the help desk, change management, HR delivery, and asset inventory workflows for the bulk of the U.S. federal government and roughly 85% of the Fortune 500 ^[2][3]. The bulletin states the issue primarily impacts customers on the Australia platform release, and customers on older releases who made certain configuration changes ^[1]. ServiceNow says the activity was likely tied to security researchers or customer-led research rather than malicious threat actors ^[1]. The company has not yet committed to publishing a CVE.

The Flaw: A Single Configuration Flag, Set Wrong

The bug is the kind of error security teams spend their careers trying to prevent, because it cannot be detected by code review and is invisible to anyone who is not specifically looking for it.

ServiceNow exposes a large set of REST API endpoints for customers to integrate their instances with the rest of their IT estate. Each endpoint carries an access property, requires_authentication. When set to false, the endpoint will answer a request from any client on the public internet, with no API key, OAuth token, or session cookie, as long as the request is well-formed ^[1].

The endpoint identified in this incident, /api/now/related_list_edit/create, is normally used to create related-list records on a parent record. On June 5, 2026, ServiceNow pushed a configuration change to hosted customer instances that set requires_authentication=true on that endpoint. That single flag flip is the patch ^[1].

Anyone who found the endpoint while it was misconfigured could issue queries against customer instance tables. ServiceNow's bulletin, which is hidden behind the customer support login portal, confirms that attackers did exactly that, and that the queries returned real data ^[1].

The Timeline: 44 Days From Flag to Fix

The dates in the bulletin, as reported by BleepingComputer, are the part that federal IT security teams will read twice.

April 22, 2026: ServiceNow receives a confidential bug bounty submission describing a similar issue ^[1]. Bug bounty programs exist specifically so companies can fix issues quietly, before they are exploited in the wild. ServiceNow has not publicly said what it did with the report between April 22 and early June.

Late May 2026: ServiceNow begins observing "anomalous activity" against customer instances. Administrators on Reddit's r/servicenow start sharing indicators of compromise, including a specific source IP, 51.159.98.241, posting to the vulnerable endpoint ^[1].

June 5, 2026: ServiceNow applies the security update to hosted customer instances. The bulletin says the update "concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended" ^[1].

June 9, 2026: ServiceNow notifies impacted customers through support cases and the hidden bulletin. BleepingComputer publishes its story, written by Lawrence Abrams, the same day ^[1].

June 10, 2026: ServiceNow publishes a public advisory stating that it believes the activity "was likely tied to security researchers or customer-led research associated with bug bounty submissions rather than malicious threat actors" ^[1]. The company also discloses, for the first time, the April 22 bug bounty submission.

The gap between April 22 and June 5 is the line a congressional committee will eventually want to walk through. A researcher reports an issue. The vendor does not patch. Activity is observed in the wild. The patch ships. The public learns about it four days after the patch, and the existence of the bug bounty report is disclosed only in the second update.

The Federal Exposure: Real, But Still Unnamed

ServiceNow is one of the major IT service management platforms sold to U.S. federal agencies. The platform is sold to federal agencies through GSA's Multiple Award Schedule and government-wide acquisition contract vehicles, covering ITSM, IT asset management, HR service delivery, and security operations workflows for federal civilian agencies ^[2]. For agencies running the platform, ServiceNow is the system of record for help desk tickets, employee onboarding and offboarding records, security incident reports, change-management approvals, and the configuration items that document what software is running on what machine across the agency's network ^[2][3].

None of that is in dispute. The dispute is whether federal customers were caught in this incident.

BleepingComputer's reporting, the primary source for this story, does not name any federal agency as confirmed affected. The bulletin itself says the issue "primarily impacts customers who are on the Australia platform release or made certain configuration changes to instances on releases prior to Australia" ^[1]. ServiceNow's customer base spans thousands of enterprise customers worldwide, including Fortune 500 companies, federal agencies, and healthcare organizations ^[3]. The bulletin instructs customers that "if a customer has not received a support case, they are not believed to be affected" ^[1].

What that means in practice: any federal agency running the Australia platform release, or running an older release with custom configuration changes touching related-list endpoints, was potentially exposed between late May and June 5. Whether any specific agency was actually queried is something only ServiceNow's instance logs can answer, and ServiceNow is not saying publicly. Affected customers have been notified through support cases. No federal agency has, as of this writing, publicly named the scope of its exposure.

That silence is itself the story. Federal agencies are required to report major cyber incidents to the Cybersecurity and Infrastructure Security Agency under the Federal Information Security Modernization Act, with the timeline defined in current binding operational directives. A two-month-old unauthenticated access flaw on a platform that handles the agency's IT help desk, change management, and asset inventory is the kind of incident that would normally trigger an urgent reporting chain. No federal agency has, as of this writing, publicly disclosed a CISA incident report tied to this ServiceNow bulletin.

What Attackers Could Have Gotten

The unauthenticated endpoint could be used to query any table in a customer instance that the underlying API user had read access to. That is a wide aperture. ServiceNow customer instances typically store ^[1][3]:

IT support tickets with attached screenshots, file shares, and full text of the conversation, often including credentials, API tokens, and VPN configurations that users emailed or pasted into the ticket during troubleshooting.
Employee records for HR service delivery, including salary bands, performance review history, and home contact information.
Change-management records documenting planned and completed changes to production systems, including the names of approvers, the systems affected, and the change window.
Configuration items representing the agency's entire IT estate, from the model and serial number of every laptop to the IP address and software version of every server and network device.
Security incident tickets created by the SOC, often containing the indicators of compromise, the affected systems, and the analyst's notes on the response.
Integration credentials for the dozens of other enterprise systems ServiceNow talks to in a typical deployment: Active Directory, the SIEM, the vulnerability scanner, the cloud cost dashboard, the contract management system, and the identity provider.

Support case content has been a rising target for initial-access brokers over the past two years because tickets routinely contain live credentials, and the people who put them there, the support engineers, are not the people who monitor them for theft ^[1]. A federal help desk ticket from a Tier 2 engineer, sent to a user who is locked out at 2 a.m., is a one-stop shop for an adversary who wants to pivot from a ServiceNow instance into the rest of the agency's network.

The Attribution: Likely Bug Bounty. The Patch Delay Is Still the Story.

On June 10, ServiceNow published an advisory stating it believes the activity "was likely tied to security researchers or customer-led research associated with bug bounty submissions rather than malicious threat actors" ^[1]. That language matters. If the activity was a researcher or a customer doing authorized security testing, then the data was not stolen, and the exposure is limited to the integrity of the platform's access controls.

That does not mean the incident is benign. It means the worst case (a malicious actor exfiltrating data over weeks) is not what happened, but the second-worst case (a configuration flaw that would have let a malicious actor do exactly that, had they found it first) is exactly what the timeline suggests was possible. The endpoint was misconfigured for an unknown period before the bug bounty report, and it was misconfigured for 44 days after the bug bounty report. That is a wide window for someone with malicious intent to find the same thing.

It is also not clear that the bulletin was written with the assumption that the activity was a researcher. ServiceNow's June 9 bulletin instructs administrators to review logs for the IOC IP and to treat the activity as an incident, with no language indicating the source was friendly. The "likely researcher" framing appeared only in the June 10 advisory, after BleepingComputer had reported the story and the company's hand was forced ^[1].

No CVE. The CISA KEV Catalog Has Not Flagged It.

ServiceNow says it is "still evaluating whether it will publish a CVE" for the issue ^[1]. The CISA Known Exploited Vulnerabilities catalog, the federal government's authoritative list of vulnerabilities that have been observed exploited in the wild and that federal civilian agencies are required to remediate, does not currently include this ServiceNow issue ^[4].

That is unusual for an unauthenticated access flaw in a widely deployed enterprise platform where exploitation has been confirmed in production. CVEs are typically assigned for unauthenticated remote access flaws, especially when the vendor's own bulletin confirms exploitation. The two ServiceNow entries currently in KEV, CVE-2024-5217 and CVE-2024-4879, are from July 2024 and are not the same issue ^[4].

For federal agencies, the absence of a CVE and the absence of a KEV entry mean there is no binding operational directive forcing remediation, no patch-by date, and no requirement to report. The fix is whatever the customer does on their own. For a flaw that was live in production for 44 days after the vendor was told about it, that is a gap in the federal vulnerability management regime that the June 11 deadline on FISA Section 702 has nothing to do with, but that the next round of cyber-incident reporting rulemaking is going to have to address.

What You Can Do

If you are a ServiceNow customer:

Check whether you received a ServiceNow support case between June 9 and today. The company is using direct support cases to notify confirmed-affected customers. No case means ServiceNow's analysis says you were not touched, but verify with your instance admin anyway ^[1].
Search your instance access logs for requests to /api/now/related_list_edit/create from IP 51.159.98.241, and from any other source that does not match your normal integration traffic. Reddit's r/servicenow administrators have been sharing IOCs since the disclosure. The window to look at is May 1 through June 5, 2026 ^[1].
Treat any credential, token, or shared secret that ever appeared in a ServiceNow ticket as compromised. Rotate service account passwords, rotate API tokens, and rotate any integration credentials for systems ServiceNow talks to. The endpoint is gone, but anything an attacker read between late May and June 5 is still valid.
Audit your instance for the Australia platform release status, and for any custom configuration changes touching related-list endpoints on older releases. Those are the two populations the bulletin flags as most exposed ^[1].
Enable API access logging and forward ServiceNow logs to your SIEM if you have not already. A platform that runs your IT help desk and your security incident workflow is exactly where detection engineering matters most.
File a FOIA or a congressional inquiry if you are a federal agency and your instance was on the Australia release. The bulletin instructs you to assume exposure if you were on the affected release. Your inspector general, your agency's CIO, and your oversight committees will want to know what was queried.

If you are a federal policy person:

Add "vendor bug-bounty-to-patch latency" to the cyber-incident reporting rule. The 44-day gap between the April 22 report and the June 5 patch is a number. Future rulemaking should require vendors in federal supply chains to report bug-bounty disclosures on critical-severity unauthenticated access flaws within a defined window, and to disclose any delay that overlaps with observed exploitation.
Push CISA to assign a KEV entry for any unauthenticated access flaw where the vendor confirms production exploitation, regardless of whether the vendor has assigned a CVE. The current process leaves federal agencies to wait on a vendor's CVE-disclosure decision before KEV applies.

The Patch Was One Flag Flip. The Delay Was 44 Days.

The fix itself is trivial. A single configuration setting on a single API endpoint, flipped from false to true, in a config management system ServiceNow itself built for exactly this kind of change. The platform can push a config change to every hosted instance globally in an afternoon, and that is what the company did on June 5 ^[1].

What the platform cannot do is rewind 44 days. From April 22, when a researcher told ServiceNow about the issue, until June 5, when the patch shipped, the endpoint answered to anyone on the public internet who knew its name. ServiceNow has characterized the activity in that window as likely friendly research. The company is in a better position than anyone to make that call. The fact remains that a researcher could find it, and a researcher could query customer instance tables, and ServiceNow knew, and the patch waited for a Friday in early June.

For a platform that runs the help desk for the federal government, the asset inventory for the Fortune 500, and the change-management approvals for a few thousand enterprises, the bar is higher than "we got the flag flipped before someone exfiltrated the data." The bar is that the flag is never wrong, and when a researcher tells you it is wrong, the patch goes out the same week, not the same quarter.