ServiceNow's API Breach: What Leaders Need to See

April 7th Independent security team: "Hey ServiceNow, you have a serious API vulnerability in place. A REST endpoint shipped with authentication disabled. You better check it out." ServiceNow support engineers: "Nah, it'll be fine. It's a non-urgent issue. We're gonna fix it in the next cycles."

June 2-3rd: The attacker started sending requests from the IP address 51.159.98.241

June 9th Everyone: "ServiceNow got breached via that exact API vulnerability."

I guess it wasn't fine.

Reddit thread: https://shorturl.at/tiVlJ

ServiceNow disclosed the incident on June 9th. An attacker found the exposed (unauthenticated) REST endpoint and hit multiple customer tenants from a single IP address over two days. The problem got patched, but did ServiceNow really need to wait for things to escalate to fix the problem?

The API endpoint without authentication has remained untouched since 2018. This wasn't a sophisticated attack that was hard to defend against. It was a consequence of companies failing to prioritize API security, governance, and visibility.

In this specific case, there was no continuous monitoring across the API estate. That's an API governance failure. If ServiceNow had a leadership dashboard with real-time security scoring, this would have been flagged (and resolved) months ago.

The Technical facts

The vulnerable endpoint was /api/now/related_list_edit/create, a Scripted REST Resource that shipped with requires_authentication set to false. Flipping that one checkbox determines whether a valid session, token, or credential is required before the endpoint responds.

It's simple to do. But it's also simple not to do, especially when it's a "nice-to-have" instead of an enforced "must-have." API governance failures in a nutshell.

With authentication off, the endpoint accepted requests from anyone who knew the URL. When the attacker's requests arrived from IP address 51.159.98.241 on June 2nd and 3rd, ServiceNow had no user account to log against. Transaction records across multiple affected tenants show approximately five hits each, logged under the Guest user attribution, not because a guest account was used, but because no account was required. The platform logged what it could.

What it could not log, for most customers, was the content of the requests or responses. REST message logging was not enabled on most instances, so while administrators could confirm the IP and timestamp, they could not determine the payloads or the API responses. You know when a burglar came into your house and from where, but you have no idea what they did while they were there.

A secondary configuration detail further complicates the picture. ServiceNow Scripted REST Resources have two distinct checkboxes:

• Authentication
• Enforcing ACLs

An endpoint can require a valid login but still skip row-level and field-level access checks. Again, a problem that could have been easily solved prevented if the REST resource had been updated in the past eight years.

Why no one was looking

The operational problem with API estates that grow over the years is that new endpoints are added while old ones stop being reviewed. Security defaults set (or overlooked) in 2018 are not revisited because there is no systematic process to surface them. The endpoint stays in the catalog, sits quietly in production, and nothing flags it as anomalous because nothing is monitoring.

This is not a criticism specific to ServiceNow's engineering culture. Treblle's analysis of over one billion production API requests per month finds that unauthenticated endpoints are a consistent presence across organizations of all sizes and industries, especially in legacy endpoints built for internal use and never updated as the API estate scaled.

From a leadership perspective, the question is whether you have any way to know, right now, whether an endpoint with authentication disabled exists somewhere in your API estate. For most organizations running without dedicated API observability, the honest answer is no.

API Governance: The Leadership Problem

API governance is most often discussed as a development-time concern: design standards, review gates, and documentation requirements. The ServiceNow incident exposes the runtime gap. The misconfiguration entered the system before 2018, but the exposure window is a runtime issue. It stays open for as long as no one checks.

The challenge is that the tools most security teams use are either design-time-focused or operate only occasionally.

Security scanners run periodically. Penetration tests happen once or twice a year. Developer reviews focus on new code, not the REST resource last updated in the pre-pandemic era.

What gets left out is a continuous read on the security posture of every endpoint in production. Without that read, a single unchecked checkbox from 2018 can remain exploitable across an enterprise with thousands of security professionals, active compliance programs, and a SOC 2 audit on the calendar. You can't fix what you don't observe. Continuously.

API governance at a leadership level means having continuous visibility into the security posture of every API endpoint in production, not point-in-time audits of selected endpoints conducted when the team has capacity.

What a Leadership Dashboard Would Have Shown

Treblle captures 40+ data points per API request and evaluates each endpoint against 20+ security criteria, including authentication configuration. An endpoint with no authentication requirement receives a failing score on that criterion, which propagates to an overall endpoint security rating visible in the governance dashboard. This is updated as traffic flows through the endpoint, not on a quarterly schedule.

For the /api/now/related_list_edit/create endpoint, the specific failure would appear as a critical finding in Treblle's API catalog: authentication not required, last seen active, risk score flagged. Front and center on the dashboard, alongside every other endpoint in the estate.

The traffic anomaly on June 2nd and 3rd would register as a separate signal. Treblle's anomaly detection captures patterned traffic from new sources against low-traffic endpoints. The activity from 51.159.98.241 would be logged with the full request and response content, which is precisely the data most ServiceNow administrators didn't have when they started their post-incident investigations.

The governance picture that leadership would see with Treblle in place:

• The endpoint appears in the API catalog with a failing authentication score, visible weeks or months before June 2nd
• The traffic spike on June 2-3 triggers an anomaly alert tied to a previously flagged endpoint
• The investigation has request body and response payload content to work from, rather than an IP address and a timestamp

For organizations subject to SOC 2, HIPAA, or FedRAMP requirements, the Treblle audit trail also addresses the compliance documentation challenge. The exposure window is not "we were notified by our vendor on June 9th." It is documented from the first request.

With Treblle vs. Without Treblle

The table below maps the ServiceNow incident timeline against the response and prevention capabilities, with and without API observability in place.

What Changes When Leadership Has the Picture

ServiceNow serves roughly 8,100 enterprise customers globally. The breach affected a subset, but that subset spans organizations storing employee records, IT infrastructure details, security incident histories, and, in many cases, credentials and API tokens shared in support tickets during troubleshooting.

The broader issue the incident surfaces is not unique to ServiceNow. APIs accumulate. Teams change. Configuration defaults set years ago are inherited by infrastructure that nobody clearly owns anymore. Without a platform tracking authentication posture across the full API catalog, the review process cannot keep pace with the rate at which APIs are created, modified, and left running.

Treblle provides that visibility layer. A governance dashboard that shows authentication coverage as a percentage and lists every endpoint where that coverage fails turns a periodic manual audit into a continuous check. A CISO does not need to wait for a vendor support case to find out whether their systems carry the same misconfiguration. They can check and understand the dashboard themselves.

Prevention is the best cure. An organization that saw this endpoint flagged on Treblle's governance dashboard in April 2026 would have been patching a known API misconfiguration. The organizations that received a ServiceNow support case on June 9th were beginning a forensic investigation with incomplete logs and an undefined exposure window.

Those are not the same conversation, and the difference between them is whether leadership had the picture in advance.

You can enable your C-level team to view authentication coverage, endpoint security scores, and traffic anomaly detection via a leadership-level dashboard. Treblle's platform enables that by connecting to your production APIs and immediately surfacing findings.