On June 5, 2026, ServiceNow quietly applied a security update to hosted customer instances. The bulletin, when it eventually appeared on June 9 — four days later and behind a customer portal login — described the issue as a flaw that could allow “an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended.”
That phrasing understates what actually happened. An unauthenticated REST endpoint in ServiceNow’s API allowed external attackers to query customer instance tables — the databases that store IT tickets, employee records, integration credentials, and workflow data — without presenting any credentials. The vulnerability had been actively exploited by the time the patch arrived.
What the Vulnerability Was
The vulnerable endpoint was a REST API path at /api/now/related_list_edit/create. This endpoint was configured with requires_authentication=false, a non-default configuration that in certain platform releases and migration paths left the endpoint accessible without authentication.
A successful request to this endpoint allowed an unauthenticated attacker to query and return data from instance database tables. ServiceNow instances commonly contain: IT support and service desk tickets (with internal system references and employee PII), HR workflow data, security incident and change management records, asset inventories (including software licenses and configurations), integration credentials and API tokens stored in connection records, and workflow automation data that may include business-process logic and external system dependencies.
The integration credential exposure is the most dangerous element. ServiceNow is used as an orchestration hub in many enterprise environments — it connects to Active Directory, SIEM platforms, CMDBs, HR systems, and cloud providers. Credentials stored in its Connection and Credential Aliases are frequently high-privilege service accounts. If those records were within scope of the exploited endpoint, affected organisations may face lateral movement risk beyond the ServiceNow platform itself.
Who Was Exposed
The issue primarily affected customers running the Australia platform release, and customers on older releases who had made certain configuration changes that triggered the vulnerable endpoint state. ServiceNow hosts a large portion of its enterprise customer base on shared infrastructure, which means the blast radius was not limited to self-hosted deployments.
Security researchers who examined transaction logs across affected organisations identified a consistent exploitation pattern: approximately five API requests per tenant from a single IP address (51.159.98.241), with exploitation attempts traced to June 2-3, 2026. The IP has subsequently been associated with multiple threat intelligence feeds.
ServiceNow confirmed that the attackers “successfully queried instance tables” for a subset of customers. The company did not disclose what specific data was accessed or how many customers were affected.
The Disclosure Timeline Problem
The four-day gap between the June 5 patch and the June 9 advisory is drawing as much criticism as the vulnerability itself. Under GDPR, organisations have 72 hours from awareness of a personal data breach to notify their supervisory authority. Under HIPAA’s Business Associate Agreement obligations, breach notification triggers apply to covered entities within defined windows. The question of when customer organisations “became aware” of a breach is complicated when their vendor applies a silent security patch and publishes a gated advisory four days later.
Several enterprise security teams have flagged that they first learned of the incident through threat intelligence feeds rather than ServiceNow notification. That matters for regulatory purposes: if an organisation’s data was accessed on June 2, the clock for GDPR notification may have started then — not on June 9 when the advisory was published.
This is a broader pattern in enterprise SaaS security. Platform vendors frequently patch silently for operational reasons (avoiding customer panic, protecting patch-to-exploit timing) and disclose retrospectively. That creates a structural gap for customer security teams who need to assess and report on incidents under regulatory frameworks that measure time from awareness.
What to Check Now
1. Determine if your instance was on the affected release. Contact ServiceNow support to confirm whether your instance was running the Australia platform release or a configuration state that triggered the vulnerable endpoint. Ask specifically whether anomalous access was observed against your instance.
2. Review your ServiceNow access logs for June 2-5. Look for requests to /api/now/related_list_edit/create from external IP addresses, particularly from 51.159.98.241 or other non-organisational source IPs. ServiceNow provides query logging in the System Logs > Transactions view.
3. Audit connection credentials stored in your instance. Review Connection and Credential Aliases for active service account credentials. For each high-privilege credential, assess whether it appears in table records that may have been accessible via the vulnerable endpoint. Rotate any credentials that cannot be scoped out of risk.
4. Check integration service accounts for anomalous activity. If connection credentials were exposed, look for activity from associated service accounts in your Active Directory, SIEM, HR system, and other integrated platforms from June 2 onwards.
5. Assess your regulatory notification obligations. If ServiceNow confirms your instance was affected and personal data (employee records, HR workflows, customer-facing ticket data) was within the accessible scope, you may have GDPR notification obligations. Engage your DPO and legal counsel promptly — the 72-hour clock is unforgiving.
The Broader Lesson: SaaS Integration Credential Risk
The ServiceNow incident illustrates a structural risk in how enterprises deploy SaaS platforms at the centre of their IT orchestration. ServiceNow, and platforms like it, accumulate credentials precisely because they’re designed to automate workflows that require privileged access to many systems. That design pattern — centralised orchestration with centralised credentials — creates a high-value target.
From a cloud security architecture perspective, the defensive posture should include periodic auditing of all credentials stored in workflow and ITSM platforms, enforcement of least-privilege service accounts for all integrations (no domain admin credentials in connection records), use of short-lived token-based authentication wherever platforms support it, and network-level controls that restrict which IPs can reach SaaS APIs.
None of those controls would have prevented this specific vulnerability — it was in the platform, not the configuration. But they significantly limit what an attacker can do after they exploit it.
The fundamental question raised by this incident: if your ServiceNow instance were to be queryable by unauthenticated external actors for 72 hours, what would they find? If the honest answer is “quite a lot,” that’s the security posture to address.