ServiceNow disclosed a June security issue that could allow an unauthenticated user, in certain circumstances, to gain unwanted access to information in ServiceNow instances.
The company applied a security update to hosted customer instances on June 5, 2026, though customers still need to know what happened inside their own tenants.
In a statement shared with TechInformed, ServiceNow said: “ServiceNow recently applied a security update to hosted customers. The update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended. We notified affected customers directly with next steps and guidance.”
The company’s customer notification said the hosted-customer update was applied on June 5, 2026 PST. That update closed one part of the problem. Customers still need to determine which tables were queried, which fields were exposed and whether sensitive records, tokens or credentials were present in the returned data.
Bug bounty reports map the timeline
ServiceNow’s advisory said customers shared submissions to their bug bounty programs, where ethical hackers report software vulnerabilities in their systems, early June. Those submissions concerned an issue similar to a confidential report sent to ServiceNow’s own bug bounty program on April 22. The company opened an investigation and identified unattributed activity affecting a subset of customer instances.
Based on ServiceNow’s investigation so far, the activity appears to have begun on June 2. ServiceNow said it notified customers where activity was observed and opened dedicated support cases for impacted customers. The company has not disclosed the number of affected customers, the endpoint involved or the categories of information queried.
ServiceNow said a subset of customer instances were “queried successfully” and that its investigation remains ongoing. It also said it has reason to believe the activity can be attributed to security researchers or customers conducting their own research.
ServiceNow also said it was in contact with the researchers, who said the activity was solely for bug bounty submissions and that no data was used or retained.
Security experts challenge early attribution
Cory Michal, CISO at SaaS and AI security company AppOmni, urged caution. In a statement shared with TechInformed, Michal said the issue involved an “unauthenticated, internet-facing ServiceNow API endpoint” present 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,” Michal said.
His attribution warning was narrower. Researcher activity clearly occurred, he said, but at least one system publicly associated with exploitation of the vulnerability also appears to have targeted tenants of other SaaS platforms with similar unauthenticated-access weaknesses.
That overlap, in Michal’s view, makes it premature for organizations to treat all observed activity as benign before their own investigation is complete.
Splitting the response into patching and forensics
The customer work now splits in two. Hosted customers should verify that ServiceNow’s June 5 security update has been applied. Self-hosted customers should follow ServiceNow’s KB3067372 guidance, which the public advisory lists for self-hosted deployments.
The second track is forensic. Michal said customers should review ServiceNow access and transaction logs for indicators of compromise, 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, he said, customers should determine which data was accessed and treat the event as “not just a patching exercise.”
Navigating the shared responsibility model
ServiceNow describes its platform as serving business functions from IT to HR, customer service, finance and procurement. Those workflows can contain employee data, customer records, security tickets, asset information, operational notes and integration details depending on how each customer uses the platform.
ServiceNow’s own shared responsibility model makes that division explicit. The company says customers, as data controllers, determine access rights to their instance and the data it contains. Customers also configure controls and make decisions about data classification.
The evidence gap in zero-trust architecture
The same logic appears in NIST’s SP 800-207 guidance on zero trust. NIST says zero trust moves defenses away from static network perimeters and toward users, assets and resources.
It also says authentication and authorization are performed before a session to an enterprise resource is established and that enterprises should collect information about assets, network infrastructure and communications to improve security posture.
For ServiceNow customers, that guidance translates into a practical evidence gap. A patch confirms the access path has been addressed. It does not prove whether a tenant was queried before the update or whether the returned data created exposure elsewhere. ServiceNow’s advisory leaves some details open: the endpoint, the customer count, the queried data categories and whether a CVE will be assigned. Until those details are clearer, the incident remains a test of SaaS response discipline.