ServiceNow Breach: Customer Data Exposed Through Unauthenticated API Access

In early June 2026, ServiceNow notified impacted customers about malicious activity involving unauthorized access to customer instance data, now documented under KB3067321. In this blog post, we will outline what is known about the ServiceNow breach, affected instances, reported API exposure, and recommended response steps.

What Happened in the ServiceNow Breach?

ServiceNow notified affected customers, on June 5, after detecting malicious activity involving unauthorized access to customer instance data. Reportedly, the issue allowed attackers to query data through a ServiceNow API endpoint without normal authentication controls.

The company opened support cases for customers believed to be impacted. Customers who did not receive a related support case may not have been identified as affected, but organizations should still verify their status through ServiceNow support rather than relying only on public summaries.

Which ServiceNow Instances Were Potentially Affected?

The affected scope appears to involve:

• Customers on the Australia platform release
• Customers on earlier releases who made specific configuration changes

This suggests the issue depended on both release state and configuration. However, the exact affected-versus-unaffected criteria remain behind the gated ServiceNow support bulletin (KB3067321), so customers should confirm their status directly through official support channels.

What API Endpoint Was Reported?

The endpoint most often mentioned in public reporting and administrator discussions is:

• /api/now/related_list_edit/create

ServiceNow has not publicly released a full technical write-up confirming every implementation detail. For that reason, the endpoint should be described as reportedly associated with the malicious activity, not as a fully vendor-confirmed root cause.

The risk remains serious. When an API route becomes reachable without proper authentication, attackers can test requests, enumerate available records, and gather sensitive operational data at scale.

What Caused the Unauthorized Access?

Discussions point to an authentication or authorization control failure. Some administrators and third-party summaries linked the issue to a Scripted REST Resource that may have allowed unauthenticated access.

One reported configuration detail is:

• requires_authentication = false

ServiceNow’s own documentation explains that API authentication helps verify identity before API access, while REST API access policies can restrict inbound API access based on authentication type and other criteria. Those controls are important because authentication gaps can expose sensitive records even when the affected endpoint was not designed for broad data access.

Is There Evidence of Exploitation?

Yes. ServiceNow connected the issue to malicious or anomalous activity and notified impacted customers.

However, several details remain unconfirmed publicly:

• The number of affected customer instances
• The exact data accessed in each environment
• Whether attackers exfiltrated data at scale
• Whether stolen data has appeared in criminal marketplaces
• Whether ServiceNow will assign or publish a CVE for this issue

ServiceNow Breach Timeline

Based on public information, the timeline is:

1. June 2-3, 2026: Suspicious activity may trace back to this period.
2. June 5, 2026: ServiceNow applied a security update to hosted customer instances.
3. June 9, 2026: The incident is connected to the gated ServiceNow support article KB3067321.
4. June 9-10, 2026: Community and security-industry discussions focused on the reported endpoint, possible authentication configuration issue, and customer investigation steps.

This timeline matters because SaaS providers may remediate hosted platforms before customers fully understand whether their own data was accessed before the fix.

What Data Could Have Been Exposed?

ServiceNow has not publicly listed every affected data type. The real impact depends on each customer’s instance configuration and the information stored in records, attachments, and workflows.

Security teams should review whether exposed records may have included:

• IT service tickets with internal URLs, system names, or troubleshooting notes
• Security incident records with investigation steps, detections, or response playbooks
• HR or workflow records containing personal or business-sensitive information
• Attachments with screenshots, logs, exports, or configuration data
• Integration details, API tokens, credentials, or secrets pasted into tickets

Even read-only access can create major risk. Attackers can use operational data to map environments, identify privileged systems, understand internal processes, and prepare follow-on attacks.

What Should Defenders Do Now?

Confirm Impact Through ServiceNow Support

Start by checking whether ServiceNow opened a support case for your organization. Then ask ServiceNow to confirm whether your instance matched the affected release or configuration conditions.

Do not rely only on public reporting. The KB3067321 bulletin and customer-specific support communications remain the most important sources for impact confirmation.

Validate the Security Update

For hosted customers, ServiceNow reportedly applied the security update on June 5, 2026. Security teams should still confirm that remediation reached their instance and document the update in internal change records.

Ask ServiceNow whether any additional review is required for your environment, especially if your team made custom API, ACL, or Scripted REST Resource changes.

Review Logs for Suspicious API Activity

Search ServiceNow logs for activity involving:

• /api/now/related_list_edit/create

Also review related paths under:

• /api/now/related_list_edit

Public reporting and third-party analysis mentioned suspicious activity tied to this endpoint family. A Reddit discussion also referenced the IP address 51.159.98[.]241, but defenders should treat that as one indicator rather than the full scope of activity.

Look for:

• Requests from unauthenticated or Guest contexts
• Unusual request spikes
• Repeated calls against the reported endpoint
• Access from unfamiliar source IPs
• Activity outside expected business hours
• Enumeration-like behavior across records or tables

Review Sensitive Records and Attachments

Prioritize the records that would help an attacker understand your environment. This includes ITSM tickets, security incidents, workflow records, attachments, and integration notes.

The review should answer two questions:

1. What could attackers have learned if they queried this data?
2. Did any exposed record contain credentials, tokens, internal URLs, or privileged operational details?

Rotate Secrets That May Have Appeared in ServiceNow

If your teams have ever stored or pasted secrets in ServiceNow records, rotate them. This includes API keys, integration tokens, temporary passwords, webhook secrets, cloud credentials, and credentials captured in screenshots or logs.

Do not limit the review to open tickets. Historical records and attachments may contain sensitive data long after the original issue was closed.

Audit API and ACL Controls

Review custom Scripted REST APIs, REST access policies, ACL behavior, and Guest-access assumptions. ServiceNow’s documentation on API authentication and REST API access policies can help teams validate whether inbound API access follows expected controls.

Pay particular attention to older customizations. Legacy endpoints often remain reachable long after the original business need has changed.

How SOCRadar Can Help

The ServiceNow breach shows why SaaS visibility needs to extend beyond patch status. A vendor fix can close the immediate exposure, but security teams still need to know whether sensitive data, credentials, or internal details appeared outside the organization.

SOCRadar can support this response in three ways:

• Attack Surface Management helps teams track exposed assets, misconfigurations, and risky external-facing services.
• Vulnerability Intelligence helps teams follow emerging vulnerability details, exploitation signals, and remediation guidance.
• Dark Web Monitoring helps detect whether exposed credentials, company data, or sensitive records appear in criminal channels.

This helps organizations move from “Was the update applied?” to “Did this exposure create follow-on risk?”

Conclusion

The ServiceNow breach involved malicious activity tied to unauthorized access against some customer instances. KB3067321 appears to be the gated ServiceNow support bulletin or security update reference connected to the event.

Public reporting points to unauthenticated API access, a reportedly abused endpoint under /api/now/related_list_edit/create, and affected conditions involving the Australia release or certain older-release configurations. Some technical details remain unconfirmed because ServiceNow has not published the full bulletin publicly.

Defenders should confirm impact through ServiceNow support, validate the June 5 security update, review logs, assess sensitive records, rotate exposed secrets, and audit API access controls. In SaaS environments, “query-only” access can still give attackers the context they need for broader compromise.