ServiceNow Security Incident Puts Customer Logs on the Clock

The ServiceNow security incident exposed customer instance data after attackers exploited an unauthenticated access flaw in a vulnerable API endpoint, according to BleepingComputer. ServiceNow told affected customers it applied a security update to hosted customer instances on June 5, 2026.

The company has not publicly listed the exact records accessed. For affected customers, the immediate work is inside their own instances: logs, tickets, records, credentials and tokens shared through support workflows.

The Notice Sent Customers to Their Own Logs

BleepingComputer reported on June 9, 2026, that ServiceNow warned impacted customers through a support bulletin and direct support cases after detecting anomalous activity tied to the issue. The bulletin said the update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended.

ServiceNow also confirmed attackers exploited the flaw to query customer instance tables, according to the report. The company opened support cases with affected customers, and the advisory said customers without a support case were not believed to be affected by the incident.

The company did not disclose which data was accessed. That leaves each notified customer with a narrower but harder job: determine what its own instance held, what the queries touched, and whether any exposed records contained credentials or other secrets.

The Suspected Endpoint Is a Related List Path

ServiceNow has not publicly disclosed full technical details of the flaw. Administrators discussing the incident said the issue appeared to involve a REST endpoint at /api/now/related_list_edit/create, while one commenter claimed the endpoint had been configured with requires_authentication=false. BleepingComputer reported that the security update changed the API endpoint configuration to limit access to authenticated users only.

ServiceNow’s own REST API security documentation says REST APIs use basic authentication or OAuth by default and that each endpoint request requires an Authorization header with sufficient credentials. The same documentation says REST API role requirements are specified in access control lists associated with the API or endpoint.

Tickets and Tables Can Hold the Sensitive Stuff

The report said ServiceNow did not identify the specific data accessed during the attacks. It also noted that customer instances commonly store sensitive enterprise information across operational records.

• IT support tickets
• Employee records
• Internal documentation
• Asset inventories
• Security incident reports
• Workflow data
• Configuration details for corporate systems and services

That list matters because support and workflow records often carry operational details that other systems try to keep out of plain view. GitGuardian’s ticket scanning for exposed secrets guide says IT staff frequently embed system credentials, configuration details and service account information in tickets, change requests and knowledge articles.

ServiceNow’s own data safeguards white paper says asset data can include security event data, vulnerability information and stored credentials for discovery and orchestration. It also describes the CMDB inside a customer instance as a single source of customer infrastructure and asset data.

So the incident response is not finished when the vendor patch lands. A customer that received a case still has to inspect the records it stored in the affected instance and decide which credentials, tokens or internal details need follow-up.

The Public Record Stops at the Support Login

ServiceNow’s support bulletin was behind the company’s customer support login portal, according to BleepingComputer. Its public documentation page for available Australia patches and hotfixes says users must log into support.servicenow.com to view security patch and security hotfix release notes.

BleepingComputer said it contacted ServiceNow before publication to ask how long the activity had been ongoing, what caused the issue and whether customer data had been stolen. The article said ServiceNow did not respond before publication.

• How long the anomalous activity had been ongoing
• What caused the endpoint issue
• Which tables or records were queried
• Whether ServiceNow will publish a CVE

The bulletin said the issue primarily affected customers on the Australia platform release or customers on older releases who made certain configuration changes. ServiceNow also said it was still evaluating whether to publish a CVE for the issue.

The First Response Is Evidence Preservation

Administrators were advised to review ServiceNow logs for requests to /api/now/related_list_edit, particularly from 51.159.98.241. ServiceNow’s REST documentation says inbound API transactions can be viewed in Transaction logs.

The customer-side response should preserve evidence before records age out or get overwritten. BleepingComputer reported that impacted organizations should review exposed tickets and records for sensitive information, rotate credentials or tokens shared through support workflows, and ensure API logging is enabled.

1. Search transaction logs for requests to /api/now/related_list_edit.
2. Check for activity tied to 51.159.98.241.
3. Review exposed tickets and records for credentials, tokens, authentication secrets and internal documentation.
4. Rotate credentials or tokens that appeared in support workflows.
5. Confirm API logging is enabled for follow-up review.

ServiceNow’s Own Docs Point to Access Controls

ServiceNow’s customer instance data safeguards white paper says customers determine who has access rights to their instance and the data stored in it. It also says customers can review logs directly in their Now Platform instance or export them through a MID server to a security information and event management tool.

The same white paper says events inside a specific customer’s instance are accessible to that customer through instance logs. That is the evidence path the advisory points administrators toward.

• REST API ACLs: ServiceNow documentation ties endpoint access to access control lists and role requirements.
• Instance logs: ServiceNow says customer-specific events are available through instance logs.
• Vault controls: ServiceNow’s Vault controls in the Australia release include features for surfacing sensitive data access and identifying potential threats and data leaks.

For customers that received a case, the patch closes only the entry point described in the advisory. The remaining record is in the instance logs and in the contents of the tables that were available when the queries ran.

Frequently Asked Questions

What happened in the ServiceNow security incident?

ServiceNow told affected customers it applied a security update on June 5, 2026, for a flaw that could let an unauthenticated user gain greater access to instances than intended. BleepingComputer reported that attackers exploited the flaw to query customer instance tables.

Who is affected by the ServiceNow incident?

The advisory said the issue primarily affected customers on the Australia platform release or customers on older releases who made certain configuration changes. ServiceNow opened support cases with affected customers.

What endpoint are administrators checking?

Administrators are checking requests to /api/now/related_list_edit, and discussion around the incident pointed to /api/now/related_list_edit/create. BleepingComputer also reported that admins shared the IP address 51.159.98.241 as an indicator to review.

What data may have been exposed?

ServiceNow did not disclose the exact data accessed. Customer instances can contain support tickets, employee records, internal documentation, asset inventories, security incident reports, workflow data and configuration details.

Has ServiceNow published a CVE?

ServiceNow had not published a CVE in the report. The company said it was evaluating whether to publish one based on its internal policies and procedures.