ServiceNow Security Flaw Exploited to Access Customer Instance Data

ServiceNow has disclosed a security incident involving a vulnerability that allowed unauthenticated users to access information inside some customer instances.

The enterprise software provider said it detected anomalous activity connected to the flaw and found evidence that attackers successfully queried instance tables belonging to a subset of customers. ServiceNow privately notified the affected organizations and deployed a security update to hosted environments on June 5, 2026.

The vulnerability affected customers using the ServiceNow Australia platform release, as well as some organizations running earlier releases that had made certain configuration changes. It does not currently have a CVE identifier.

The update modified an endpoint configuration so that access is restricted to authenticated users.

“On June 5, 2026, ServiceNow applied a security update to hosted customer instances,” the company said in an advisory. “The update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended.”

A ServiceNow spokesperson characterized the incident as limited in scope.

“Our main priority was to reach out directly to the subset of customers this [incident] affected, it was not broad,” the spokesperson said.

The company has not publicly identified the attackers or disclosed the number of affected customers. It also has not detailed which tables or categories of information were accessed.

ServiceNow platforms can contain sensitive enterprise data, including employee records, IT support tickets, security incidents, asset inventories, customer information, workflow data and credentials stored through integrations. The potential impact on each organization will depend heavily on its instance configuration and the information exposed through the vulnerable endpoint.

Cory Michal, chief information security officer at SaaS and AI security company AppOmni, said the issue appears to have involved a publicly accessible ServiceNow API endpoint present in tenants with certain versions and configurations.

“Based on what we’ve seen, the issue involved an unauthenticated, internet-facing ServiceNow API endpoint that existed on tenants with specific versions and configurations. In practical terms, anyone who knew the endpoint URL and how to structure the request could access data from the affected ServiceNow tenant without authenticating first.

“The attribution question is less clear. ServiceNow has stated that researchers submitted the vulnerability through its bug bounty program in April, and that additional submissions were made to some ServiceNow customer bug bounty programs in June. That said, at least one system publicly associated with exploitation of this vulnerability also appears to have targeted tenants of other SaaS platforms with similar unauthenticated-access weaknesses. So while researcher activity clearly occurred, I would be cautious about saying all observed activity was benign research until the investigation is complete.”

The incident illustrates the danger of authorization failures in enterprise SaaS platforms. Authentication determines whether a user has proven an identity. Authorization governs what that user, or an unauthenticated visitor, can access. A configuration mistake or application flaw at either layer can expose data without requiring stolen passwords or a compromised employee account.

How ServiceNow Customers Should Investigate

Hosted ServiceNow customers should verify that the June 5 security update has been applied. Self-hosted customers should review the company’s instructions in knowledge base article KB3067372 and deploy the relevant update or mitigation.

Installing the update is only one part of the response. Organizations should also examine historical activity to determine whether their instances were accessed before the endpoint was secured.

“Customers should take two parallel steps. First, confirm they are protected: Hosted customers should verify ServiceNow’s June 5 security update has been applied, and self-hosted customers should follow ServiceNow’s guidance in KB3067372 to ensure they have applied the appropriate update or mitigation. Second, search for evidence of exploitation: Review ServiceNow access and transaction logs for known IoC, unauthenticated requests to the affected API endpoint, and unusual table or field queries, ideally covering at least the last 90 days. If suspicious activity is found, determine which data was accessed and treat it as an incident investigation, not just a patching exercise,” Michal said.

Security teams should focus on unusual unauthenticated requests, table enumeration, unexpected field queries, large responses, repeated API calls and data-access patterns originating from unfamiliar infrastructure.

Any organization that identifies suspicious activity should determine which records were exposed, whether regulated or personally identifiable information was involved and whether the incident triggers contractual or regulatory notification requirements.

ServiceNow Incident Highlights Wider SaaS Security Risk

The ServiceNow vulnerability reflects a broader security challenge as enterprise SaaS platforms become increasingly customizable.

Modern SaaS environments are no longer simple hosted applications. They contain APIs, plugins, custom code, identity integrations, automated workflows, third-party connections and configuration-dependent access controls. A change in one component can unintentionally create a public path to sensitive data.

Michal recommended three primary defenses against vulnerabilities that vendors and customers do not yet know about.

“Organizations should focus on three controls. First, continuously harden and validate SaaS tenant configurations so unauthenticated internet-facing API endpoints, overly permissive access paths, and risky default settings are identified and remediated before they can be abused.

“Second, SaaS activity logs should be part of the normal detection and response program, with monitoring in place for unusual API access, unauthenticated activity, suspicious data queries, and abnormal export or enumeration behavior.

“Third, where the platform supports it, customers should enforce Zero Trust access policies for SaaS tenants, including restricting connectivity to trusted hosts, networks, devices, or identity contexts so that even if an unknown vulnerability exists, exposure from the open internet is reduced.

“The broader lesson is that enterprise SaaS platforms have become complex application environments with many APIs, extensibility layers, integrations, workflows, and configuration-dependent access paths. That complexity creates opportunities for subtle access-control failures, which is why customers need continuous SaaS posture management and detection, not just periodic reviews or reliance on vendor defaults.”

The incident is another reminder that cloud-hosted software does not eliminate an organization’s security responsibilities. Vendors are responsible for securing their platforms, but customers still need visibility into configurations, identities, APIs and activity logs to detect when trusted SaaS environments are being abused.