ServiceNow Data Breach Exposes Customer Tenants to Unrestricted API Access

The ServiceNow data breach claim involves suspicious customer tenant activity tied to a possible unrestricted API access issue in ServiceNow environments. The data breach concern centers on customer reports that a ServiceNow API endpoint, /api/now/related_list_edit/create, may have allowed unauthenticated or improperly restricted access to tenant functions connected to related list editing. ServiceNow has not publicly confirmed that customer data was exposed, and no verified record count, file size, ransom demand, or stolen dataset has been released.

The claim is not a traditional ransomware listing or leak-for-sale post. It is a customer-driven breach concern involving suspicious IP activity, ServiceNow notifications, transaction logs, possible API access without expected authentication, and a customer allegation that ServiceNow had an internal PRB for the vulnerability before affected customers received clear answers. That makes the case different from a normal stolen-database claim, but not less serious for companies that depend on ServiceNow to manage internal workflows, employee support, change records, security operations, service requests, and infrastructure data.

ServiceNow tenants can contain sensitive operational records even when they do not hold public customer account databases. A single tenant may include internal support tickets, asset inventories, configuration items, incident notes, change approvals, access requests, user details, automation scripts, and security investigation records. If an API endpoint allowed unauthorized access to those records or allowed attackers to create related records, the exposure could help with phishing, service desk impersonation, internal reconnaissance, and follow-on attacks against customer organizations.

What the ServiceNow Data Breach Claim Says

Customers began comparing suspicious activity after at least one ServiceNow administrator described receiving a notification about a suspicious IP address in a tenant. The message reportedly suggested the IP address may have accessed multiple customer tenants. Other customers then described similar activity, including alerts around June 2 and June 3, hits to /api/now/related_list_edit/create, and uncertainty about what the requests did once they reached the endpoint.

One customer said their transaction logs showed five hits from the IP address 51.159.98.241. They said three requests were blocked by SSO, while two calls reached /api/now/related_list_edit/create. The same customer described thousands of failed script errors tied to the same call. That does not prove data theft, but it gives administrators a concrete path, IP address, and log pattern to investigate.

The customer discussion also raised the possibility that some organizations can confirm endpoint activity but not the full request or response. If REST logging was not enabled, a tenant may show that the endpoint was hit without showing the submitted payload or returned data. That gap is important for breach assessment because it can leave customers unable to determine whether suspicious requests failed, created records, returned data, or reached protected tables before another control blocked access.

Customer Claim Points to an Internal PRB Since April 7

The strongest allegation came from a customer who said their security team found the issue as a vulnerability and reported it to ServiceNow. The customer said the first two support agents suggested closing the case and told them not to worry. After escalation and a screen share, the customer said they proved the vulnerability was not introduced by their own configuration and was instead tied to the Australia release.

The same customer claimed ServiceNow showed them an internal PRB indicating that ServiceNow had been aware of the vulnerability since April 7 and had not classified it as a threat. They also claimed ServiceNow was targeting a fix in Brazil before their report changed how the issue was handled. Botcrawl has not independently verified the internal PRB, the alleged screenshots, or the full support timeline, but the claim is specific enough that ServiceNow customers should treat it as a serious disclosure and response question.

If the PRB timeline is accurate, the ServiceNow data breach claim becomes a vendor-handling issue as well as a technical one. Customers need to know when ServiceNow first identified the vulnerability, how it assessed customer impact, when it determined whether tenant data could be accessed, and why affected customers were not given clearer technical guidance before suspicious activity alerts began circulating.

Scope and Composition of Potentially Exposed Tenant Data

No confirmed dataset has been published, and ServiceNow has not publicly confirmed tenant data exposure through /api/now/related_list_edit/create. The possible exposure depends on the affected instance, the endpoint behavior, the release version, the patch level, the resource configuration, table ACLs, script behavior, and what data each customer stores inside ServiceNow.

ServiceNow is commonly used for IT service management, security operations, HR workflows, asset management, customer service, change management, access requests, and custom internal applications. Depending on the customer, a tenant may contain:

• Incident records. Internal support tickets, outage details, troubleshooting notes, affected users, affected systems, and escalation history.
• Change and problem records. Planned infrastructure changes, failed deployments, approval chains, business impact notes, and remediation timelines.
• Configuration items and asset records. System names, application names, ownership data, device records, service mappings, and infrastructure relationships.
• User and employee details. Names, email addresses, phone numbers, departments, locations, roles, managers, and support history.
• Security operations records. Vulnerability tickets, investigation notes, detection workflows, remediation tasks, and security exception records.
• Service catalog requests. Access requests, software requests, onboarding tasks, offboarding tasks, and internal approvals.
• Integration and workflow metadata. Automation logic, scripts, table relationships, system references, and process details that can help map internal operations.

Those categories are not confirmed exposed data. They describe the risk surface customers should evaluate if their instances received suspicious requests. A ServiceNow tenant is often a map of how an organization works. Even partial access to operational records can help an attacker understand internal systems, identify employees, imitate support processes, or craft messages that appear to come from a real help desk or business unit.

Unrestricted API Access and the related_list_edit Endpoint

The endpoint repeatedly named by customers is /api/now/related_list_edit/create. Customers connected that path to suspicious activity, failed script errors, possible record creation attempts, and a discussion about unrestricted API access. One participant said the root cause appeared to be a Scripted REST Resource that shipped with requires_authentication = false. Another said a later change marked requires_authentication as true.

Authentication is a basic control for API access. If a ServiceNow resource that should require authentication can be reached without it, the impact depends on what happens after the request reaches the application. Some requests may still fail because of ACLs, scripts, table restrictions, or missing parameters. Others may expose metadata, trigger script behavior, attempt record creation, or return partial data depending on the implementation.

Related list editing is also not a meaningless feature. Related lists connect records inside ServiceNow, such as incidents tied to configuration items, changes tied to tasks, problems tied to incidents, or users tied to requests. If an endpoint connected to related list editing is exposed, customers need to know whether unauthorized requests could create relationships, query records, trigger errors, or interact with tables in ways that were not intended for unauthenticated users.

Some customers also discussed activity appearing under Guest. That should be investigated carefully. A Guest label in logs may reflect a request without an authenticated user context rather than a normal user account. Treating it as ordinary Guest-user activity could cause responders to miss the more important question, which is whether the endpoint accepted requests without the authentication checks customers expected.

Risks to Customers and Internal Operations

If tenant records were accessed, the main risk is not only identity theft. ServiceNow data can give attackers business context. A support ticket may reveal a real employee, the system they use, the software they are trying to access, the error they encountered, the approval chain involved, and the internal team responsible for fixing it. That information is useful for phishing because the attacker can reference details that make a fake message look normal.

Exposed change records and configuration items can be useful for reconnaissance. Attackers can learn application names, server relationships, business services, owners, support groups, and internal terminology. In a follow-on attack, that information can help them choose targets, impersonate administrators, or craft requests that match the way the organization already works.

If the endpoint allowed record creation or modification, the risk changes. Unauthorized records could trigger workflows, create service desk noise, generate tasks, or leave confusing artifacts that slow down incident response. The public customer discussion does not prove successful record creation, but the endpoint name and failed script errors give customers a specific area to review.

ServiceNow customers in regulated sectors may face additional pressure because uncertainty itself can become an incident-response problem. A bank, hospital, government agency, telecom provider, or energy company may need to document whether regulated data was stored in affected tables, whether suspicious requests touched those tables, and whether ServiceNow can provide platform-side evidence when local logging is incomplete.

Possible Initial Access Vector

The available customer claims point to a platform-side access-control issue, not stolen passwords, phishing, malware, ransomware, or a compromised administrator account. The suspected vector is an exposed or improperly restricted Scripted REST Resource connected to related list editing. If that account is accurate, normal user password resets would not address the root cause because the activity would not depend on a stolen customer credential.

Customers should still review user activity, but the investigation should focus on the endpoint, authentication setting, ACL enforcement, patch level, request timestamps, source IP addresses, script errors, and records created or modified around the suspicious activity window. A request blocked by SSO should be treated differently from a request that reached an unauthenticated API resource. The logs need to show where each request stopped.

ServiceNow’s public release notes for Australia Patch 2 Hotfix 1 identify it as a hotfix release, but the public notes do not plainly name /api/now/related_list_edit/create as the endpoint involved in the customer reports. Customers should not assume they are unaffected based only on broad patch language. They should confirm directly with ServiceNow whether their release, upgrade path, or tenant configuration was included in the affected population.

Mitigation Steps for ServiceNow

ServiceNow should provide customers with direct technical details that let them determine impact without guessing from incomplete local logs. A clear advisory should identify the affected endpoint, vulnerable configuration, impacted releases, fixed releases, exploitation window, known indicators, and whether any requests successfully returned or changed data.

• Identify the affected Scripted REST Resource and confirm whether /api/now/related_list_edit/create is the vulnerable endpoint.
• Confirm which releases and patch levels were affected, including whether the issue is limited to Australia or present in other release families.
• State whether the endpoint allowed record creation, data retrieval, metadata exposure, or only failed requests.
• Provide tenant-specific indicators, including source IP addresses, timestamps, paths, request status, and response behavior.
• Explain the internal PRB timeline, including when the issue was first tracked and when customer-impact assessment began.
• Give customers written guidance suitable for legal, audit, regulatory, and incident-response teams.

Mitigation Steps for ServiceNow Customers

Customers should preserve evidence before logs rotate or troubleshooting changes the environment. The first priority is to determine whether the suspicious endpoint was hit, when it was hit, what IP address was involved, and whether any related records were created, modified, or returned during the same window.

• Search transaction logs for 51.159.98.241 and other IP addresses provided in ServiceNow notices.
• Search for requests to /api/now/related_list_edit/create across transaction logs, node logs, script error logs, and REST logs where available.
• Review June 2, June 3, and any tenant-specific timestamps included in ServiceNow notifications.
• Check Scripted REST Resources for entries where requires_authentication is false, especially resources tied to related list editing.
• Confirm whether the instance is running Australia Patch 2 Hotfix 1 or a later fixed release, and ask ServiceNow whether that patch addresses this exact endpoint.
• Review record creation, update history, audit logs, and unusual workflow activity around suspicious request timestamps.
• Preserve screenshots, exported logs, support case messages, ServiceNow notifications, and any written vendor statements.
• Escalate with ServiceNow for written confirmation of whether the tenant was affected and whether any data was accessed.

Recommended Actions for Employees and Customers

Organizations that rely on ServiceNow should assume attackers may attempt phishing using internal support context if tenant records were exposed. Employees should be warned to treat unusual service desk messages, access approval requests, password reset messages, MFA reset prompts, and vendor support emails with extra scrutiny, especially if the message references real internal systems or support details.

• Verify unusual help desk or access requests through a trusted internal channel.
• Do not approve MFA resets, password resets, or software access requests only because the message references a real ticket or internal system.
• Report emails or calls that mention ServiceNow tickets, internal application names, asset names, or employee details in an unusual context.
• Monitor accounts for suspicious login attempts, service desk impersonation, and unexpected changes to access rights.
• Scan workstations involved in suspicious service desk activity with trusted security tools such as Malwarebytes when malware or phishing interaction is suspected.

Current Status of the ServiceNow Data Breach Claim

The ServiceNow data breach claim remains unconfirmed as a data exposure event, but the customer reports are specific enough to justify immediate investigation. Customers have identified a repeated endpoint, a reported source IP address, suspicious tenant notifications, possible unrestricted API access, failed script errors, and a claim that ServiceNow had an internal PRB for the vulnerability before customers received clear public guidance.

There is no confirmed stolen database, no verified file dump, no public record count, no known ransom demand, and no public ServiceNow statement confirming that tenant data was exposed through /api/now/related_list_edit/create. Until ServiceNow confirms the incident or affected customers publish verifiable tenant-impact details, the safest treatment is a serious ServiceNow data breach claim involving possible API exposure, not a confirmed breach of all customer tenants.

For organizations using ServiceNow to manage employee support, internal changes, security operations, asset inventories, or customer workflows, the practical response is the same: preserve logs, confirm patch status, inspect the endpoint activity, identify affected tables, and request written tenant-specific answers from ServiceNow. If tenant records were exposed, the damage would likely come from internal context, workflow details, service desk impersonation, and operational mapping rather than a simple list of usernames and emails.