A patch that arrived quietly
ServiceNow has told some of its enterprise customers that a software bug on its platform allowed anyone on the internet to read data stored inside their instances, with no password required. The company patched affected instances on June 5, 2026, closing a hole that, according to the disclosure, let unauthenticated users gain greater access to ServiceNow hosted data than the platform was ever designed to permit. For a vendor that runs IT, HR, security and customer workflows for thousands of large organizations, the category of exposed data is the uncomfortable part: support tickets, configuration items, and in some cases the keys and credentials that live inside them.
The technical root cause is mundane and therefore all the more worrying. Security researchers traced the problem to a REST endpoint, reported as /api/now/related_list_edit/create, that was configured with requires_authentication set to false. In plain terms, a permission gate that should have demanded a login was simply switched off. That single misconfiguration turned an internal data path into a public one, and it is exactly the sort of default that automated scanners and bug bounty hunters probe for first.
What the timeline reveals
The sequence of dates matters more than any single one. ServiceNow says it received a confidential bug bounty submission describing a similar issue on April 22, 2026. The fix did not ship until June 5, after activity targeting customer instances had reportedly already begun. Anomalous requests were observed against customer instances in early June, and an IP address, 51.159.98.241, has been flagged as a potential indicator of access. The patch landed first, the public bulletin followed on June 9, and customer notifications went out into June 10.
That roughly six week gap between report and remediation is the kind of window defenders lose sleep over. We have argued before that vulnerability disclosure programs only pay off when the intake pipeline moves at the speed of the threat, not the speed of the release train. A confidential report sitting in a queue while a misconfigured endpoint stays live in production is the worst of both worlds: the vendor knows, the attackers may know, and the customers do not.
Is it a breach or is it research?
ServiceNow is careful with its language. Spokesperson Courtney Johnson said that evidence of the observed activity came from security researchers and customer research teams, not bad actors, and that no data was used or retained. The company frames the incident as the product of people hunting for vulnerabilities they could submit for a bug bounty, and says the range of impacted customers was not broad, concentrated on the Australia platform release and on older releases with specific configuration changes.
We would caution against taking too much comfort from that framing. The platform cannot distinguish a researcher from an adversary at the moment of access, and a flaw that is trivially reachable by a curious researcher is equally reachable by anyone else who finds it. When the precondition for safety is that only well intentioned people noticed, the control has already failed. The honest reading is that the data was exposed and the company is fortunate the observed traffic appears to have come from disclosure minded parties.
The disclosure design problem
There is a second failure layered on top of the first, and it is about communication rather than code. ServiceNow posted its security bulletin four days after applying the patch, and that bulletin requires a customer support portal login to read. For a multi tenant platform where a configuration flaw is fixed centrally, that gated, delayed advisory leaves customers unable to assess their own exposure on their own timeline. Security teams reported piecing the story together from social media threads before they could find an official account.
This is a governance choice as much as a security one. Customers who carry regulatory notification duties cannot wait for a login walled bulletin to tell them whether their instance was in scope and what data might have been reachable. The lesson for any SaaS provider watching this unfold is that the speed and openness of disclosure is now part of the product, and treating it as an afterthought converts a contained incident into a trust problem.
A familiar pattern across the SaaS estate
This incident is not an outlier so much as the latest entry in a growing genre. Over the past two years the most consequential enterprise breaches have rarely involved exotic exploit chains. They have involved permissions that were never set, tokens that were never rotated, and endpoints that were never meant to face the public but quietly did. The ServiceNow flaw belongs squarely in that lineage, where the failure is one of configuration management rather than cryptography or memory safety, and where the blast radius is large precisely because the platform is multi tenant and trusted.
The structural reason this keeps happening is that modern SaaS platforms are vast surfaces of configurable behavior, and configurability is the enemy of provable safety. Every toggle that lets a customer tailor the product is a toggle that can be set wrong, by the vendor or by the buyer, and there are thousands of them. We would argue the industry needs to treat authentication defaults the way it treats encryption defaults: secure unless a deliberate, logged, reviewed decision makes them otherwise. Until that becomes the norm, each quarter will bring another bulletin about an endpoint that forgot to ask for a password.
What CISOs should do this week
If your organization runs ServiceNow, the immediate work is verification rather than panic. Confirm that your instances received the June 5 remediation, review access logs for anomalous unauthenticated requests in the late May to early June window, and check specifically for traffic associated with the flagged indicator. Pay particular attention to instances on the Australia release and to any older instances where teams have made custom configuration changes, since those are where ServiceNow says the exposure concentrated.
The broader takeaway extends well past one vendor. Unauthenticated API endpoints are becoming the soft underbelly of the enterprise SaaS estate, because a single boolean set the wrong way can undo every other control. CISOs should be asking their platform providers a blunt question: how many of your REST endpoints can be reached without authentication, and who reviews that list. In a world where business runs on configurable platforms, the configuration is the attack surface, and this incident is a reminder that the most dangerous setting is the one nobody remembered to check.
