ServiceNow has disclosed a serious security issue that allowed attackers to access more information than intended from a limited number of hosted customer environments. The vulnerability was especially concerning because it could be exploited under certain conditions without requiring a valid username or password.
The company has already deployed a security update to affected hosted instances and contacted customers believed to have been impacted. However, organisations using ServiceNow should still review their logs and configurations rather than assuming the platform-level fix alone has resolved every possible consequence of the incident.
What Happened to the Affected ServiceNow Instances?
The vulnerability involved weaknesses in the access controls protecting a ServiceNow endpoint. Under specific circumstances, an unauthenticated attacker could interact with that endpoint and obtain a higher level of access to customer instance data than the platform was supposed to allow.
ServiceNow confirmed that unknown threat actors successfully exploited the flaw against a subset of hosted customer environments. The attackers were able to query tables inside affected instances, potentially exposing information stored within those environments.
This was not merely a theoretical weakness discovered before anyone could use it. Evidence of real-world exploitation was identified, making the incident more urgent for organisations running affected configurations.
No Login Credentials Were Required
One of the most serious aspects of the vulnerability was that an attacker did not necessarily need a legitimate ServiceNow account.
Normally, instance tables and platform functions should only be accessible after a user has been authenticated and granted the appropriate permissions. In this case, weaknesses in the endpoint's access-control configuration could allow an unauthenticated request to reach functionality that should have been protected.
That significantly lowers the barrier for exploitation. Instead of first stealing an employee's password or compromising a privileged account, an attacker could potentially begin interacting with an exposed instance directly.
The attack sequence described in the advisory was relatively straightforward:
Why ServiceNow Data Can Be Highly Sensitive
ServiceNow is commonly used for much more than basic helpdesk ticketing.
Depending on the organisation, a ServiceNow instance may contain:
Some organisations also connect ServiceNow with identity platforms, endpoint-management systems, monitoring tools, cloud services and other enterprise applications.
This means unauthorised access to an instance may expose valuable information about how the organisation operates. Even when passwords or highly sensitive personal records are not directly available, operational data can help attackers understand internal systems, identify important assets and plan further attacks.
The advisory notes that ServiceNow is widely used across IT service management, asset management, security operations and business workflows, increasing the potential business impact of unauthorised access.
Attackers Successfully Queried Instance Tables
ServiceNow detected anomalous activity linked to the vulnerability and determined that attackers had successfully queried tables belonging to a subset of customer instances.
In ServiceNow, tables are used to store the records supporting different platform functions. These may include incidents, users, assets, configuration items, service requests and workflow data.
The exact exposure would therefore depend heavily on the affected organisation's configuration. A relatively simple instance may hold limited operational information, while a heavily customised enterprise deployment could contain a much broader collection of business and technical records.
ServiceNow described the impact as limited, but any confirmed unauthorised query should be taken seriously. Organisations need to determine not only whether an attacker accessed the instance, but also which tables were queried, what records were returned and whether the information could support further intrusion attempts.
The Vulnerability Does Not Currently Have a CVE Identifier
At the time of the advisory, the vulnerability had not been assigned a publicly documented CVE identifier.
This can make it harder for security teams to track the issue through conventional vulnerability-management platforms. Many organisations rely on CVE numbers to identify affected systems, correlate threat intelligence and confirm remediation status.
Without a CVE, administrators may need to depend more heavily on direct ServiceNow communications, platform notifications and internal configuration reviews.
The limited amount of publicly available technical information also creates challenges. Organisations may find it difficult to determine exactly how an attacker would identify a vulnerable instance or which log patterns provide the clearest evidence of exploitation.
Which ServiceNow Environments Were Affected?
The issue affected hosted customer instances running the Australia platform release, as well as some instances on earlier releases where particular configuration changes had been introduced.
This means the platform version alone may not be enough to determine exposure. An instance running an older release could still have been affected if its endpoint configuration had been changed in a way that recreated the vulnerable condition.
ServiceNow applied security updates to affected hosted environments and directly notified customers identified as impacted.
Administrators should therefore verify both the instance release and any historical configuration changes that may have affected endpoint permissions.
ServiceNow Deployed a Security Update in June
ServiceNow implemented a security update on 5 June 2026.
The update changed the affected endpoint configuration so that only authenticated users could access the vulnerable functionality. This closes the unauthenticated access path that attackers had abused.
Because ServiceNow hosts and manages its cloud instances, the company was able to deploy the correction directly to affected environments. That reduces the burden on customers compared with an on-premises vulnerability that requires each organisation to install a patch manually.
However, applying the fix does not automatically answer whether data was accessed before the update. Customers must still review the period preceding the correction for indicators of suspicious activity.
Check Whether ServiceNow Contacted Your Organisation
Organisations should review messages from ServiceNow to determine whether their instance was identified as affected.
Relevant notifications may have been sent to:
It is also worth checking ServiceNow support portals and administrative dashboards rather than relying exclusively on email.
If no notification was received, administrators should still confirm the instance status through official support channels, particularly when the environment runs the Australia release or contains significant custom endpoint configurations.
The advisory specifically recommends confirming that the June security update has been applied and reviewing ServiceNow communications for notification of potential impact.
Audit ServiceNow Logs for Suspicious Table Queries
A detailed audit of instance activity is one of the most important follow-up steps.
Security teams should look for:
The investigation should focus on the period before the security update was deployed, while also checking for suspicious activity after the update in case attackers had obtained information or credentials that could support continued access.
Organisations should correlate ServiceNow logs with firewall, proxy, identity and security-monitoring records wherever possible. A suspicious request seen inside ServiceNow may become more meaningful when matched with an unusual external IP address or abnormal activity elsewhere in the environment.
The recommended mitigation guidance specifically calls for reviewing logs for unauthorised table queries, unusual API activity and suspicious authentication events.
Review Custom Configurations and Endpoint Permissions
ServiceNow environments are often customised extensively. Organisations may create new tables, APIs, integrations, scripted endpoints and access-control rules to support their internal processes.
Customisation creates business value, but it can also introduce security inconsistencies.
Administrators should review:
Special attention should be given to environments running the Australia release and earlier instances that underwent endpoint-related configuration changes.
A configuration that was considered acceptable under an older platform version may behave differently after an upgrade or custom modification.
Reset Credentials When Suspicious Activity Is Found
If evidence suggests that an attacker accessed sensitive instance data, the organisation should consider resetting credentials associated with the affected environment.
This may include:
The need for a reset depends on what information was exposed. If the attacker accessed tables containing integration details, secrets or account information, credential rotation should be treated as a priority.
A broader compromise assessment may also be necessary to determine whether information obtained from ServiceNow was used to access another platform.
The advisory recommends resetting credentials and conducting a compromise assessment whenever suspicious or unauthorised activity is detected.
Do Not Treat the Hosted Fix as the End of the Investigation
ServiceNow's update prevents further exploitation through the corrected endpoint, but customers remain responsible for evaluating the possible impact on their own data.
A complete response should address three separate questions:
Answering only the first question is not enough.
Even when the platform is now secure, previously exposed information may continue to create risk. For example, attackers could use knowledge of internal assets, employee accounts or workflow processes to create convincing phishing messages or target other systems.
Security Teams Should Understand What Their ServiceNow Instance Contains
Incidents like this demonstrate why organisations need clear visibility into the information stored in cloud business platforms.
Many teams know that ServiceNow manages tickets, but fewer maintain a complete understanding of the sensitive data distributed across custom tables, integrations and workflow records.
Organisations should classify the information held in the platform and define retention rules for data that no longer needs to remain available.
Reducing unnecessary data storage can limit the impact of future security incidents. An attacker cannot steal historical records that have been securely removed under an approved retention policy.
Final Thoughts
The ServiceNow incident highlights how a weakness in a single endpoint can expose information from a much broader enterprise platform.
Because the flaw could be exploited without authentication and was used successfully against some customer instances, organisations should not rely solely on the fact that ServiceNow has already deployed a fix.
Administrators should confirm the security update, review official notifications, audit instance logs and inspect custom endpoint configurations. Where suspicious access is found, credentials should be rotated and a wider compromise assessment should be performed.
ServiceNow remains an important platform for managing IT operations and business workflows, but that importance also makes it a valuable target. The more operational data an organisation stores in the platform, the more carefully its access controls, logging and customisations need to be managed.
Comments