On June 9, 2026, ServiceNow disclosed that attackers had exploited an unauthenticated access flaw in a REST API endpoint — reported by multiple outlets as /api/now/related_list_edit/create — that hosted customer instances had shipped with a configuration flag set to requires_authentication=false. That single setting meant anyone on the open internet could query tables inside a customer's ServiceNow instance without a username, password, session cookie, or API token. No exploit chain, no privilege escalation, no clever bypass. Just a door that was never locked in the first place.
The timeline is the part that should unsettle security leaders more than the flaw itself. ServiceNow received a confidential bug bounty submission describing the issue on April 22, 2026. Anomalous activity consistent with malicious exploitation reportedly began June 2. Two more bug bounty reports from customers or researchers landed June 3 and June 4. ServiceNow pushed a configuration change to hosted customer instances on June 5, then notified customers directly where its investigation found evidence of successful table queries against their data. Public disclosure followed on June 9. Strip out the corporate-incident-response language and what's left is this: a private, responsible disclosure of an unauthenticated data-exposure bug sat for roughly six weeks before it was fixed, and the fix arrived only after the same class of bug started getting exploited in the wild.
The bug wasn't a bug, it was a setting
Most of the security incidents that dominate headlines have a CVE number attached — a specific software defect with a patch, a version number, and a scanner signature. This one doesn't work that way. There was no vulnerable code to patch in the traditional sense. The endpoint functioned exactly as it was configured to function; the configuration itself was the vulnerability. requires_authentication=false is a boolean, not a buffer overflow. It's the kind of flag that gets set during development, testing, or a rushed feature rollout, and then survives into production because nothing about a boolean silently flipped to false triggers an alert the way a memory-corruption bug does.
This matters because it breaks the mental model most vulnerability management programs run on. Your team can have a mature CVE-tracking process, weekly patch cadences, and a vulnerability scanner pointed at every asset you own, and none of it would have caught this. The affected asset wasn't yours — it was ServiceNow's multi-tenant platform, and the vulnerable state lived in a configuration table on ServiceNow's side, not in code your team ever touched or could scan. Call it misconfig-by-update: a change goes out platform-wide, a flag that should default to secure defaults to permissive instead, and every customer on that shared infrastructure inherits the exposure simultaneously, with zero warning and zero opportunity to catch it themselves.
Why six weeks is the number that matters
Bug bounty programs exist precisely so vendors hear about flaws like this before criminals do. That only works if the gap between disclosure and remediation is short enough that the window of exposure stays theoretical rather than actual. Six weeks between a private report describing an unauthenticated data-exposure bug and a fix is a long time for a flaw of this severity — long enough, per the disclosed timeline, for exploitation activity to begin before the patch landed. Some reporting on the incident notes ServiceNow's own investigation attributed at least some of the observed June activity to security researchers or customers testing the issue themselves rather than confirmed malicious actors, which is a meaningful nuance. But that doesn't change the structural problem: for six weeks, any sufficiently curious party — researcher, customer, or genuine attacker — could query the same unauthenticated endpoint, and ServiceNow had no way to distinguish between them until it started seeing anomalous query patterns.
There's no universally agreed SLA for "unauthenticated, no-auth-required, data-exposure bug reported through a bug bounty program," but the industry norm for critical severity findings tends to run in days, not weeks — Google and Microsoft's own bounty guidance, for instance, generally targets 90 days for full public disclosure but expects far faster action on anything actively exploitable with no authentication barrier at all. An unauthenticated endpoint that returns customer table data isn't a theoretical severity-4 finding sitting in a backlog; it's the kind of report that should trigger an emergency change process the same day it's triaged. Enterprise customers should be asking their SaaS vendors, in contract language rather than a sales call, what the committed SLA actually is for critical unauthenticated-access findings, and what the notification commitment looks like if that SLA slips.
Why this is a distinctly SaaS-era risk
A misconfigured firewall rule on your own network is bad, but it's bounded — it's your infrastructure, your blast radius, and your team that finds and fixes it. A misconfigured API flag on a shared SaaS platform is a different animal entirely, because the exposure isn't bounded by your organization's perimeter at all. ServiceNow instances are provisioned on shared platform infrastructure, and a configuration change to a core API endpoint doesn't get scoped per-customer — it goes out globally, which means a single mistake on the vendor's side becomes a simultaneous, cross-customer exposure event. Every enterprise running ServiceNow — and there are tens of thousands of them, spanning healthcare systems, banks, governments, and large employers — inherited the same exposed endpoint at the same moment, without any of them changing a single setting on their own end.
This is the trade-off that comes bundled with every "we don't manage the infrastructure anymore" SaaS decision, and it rarely gets priced into the conversation. When your core operational platform runs on someone else's shared, multi-tenant infrastructure, you gain operational simplicity and lose direct visibility into — and control over — the security posture of the systems holding your data. You can't scan for this. You can't patch it. You can't even see the configuration state that determines whether your data is exposed. Your only signal is the vendor's own detection and disclosure process, which is exactly what played out here: customers found out they were affected because ServiceNow told them, not because their own monitoring caught anything, since the traffic hitting an authenticated-looking endpoint with valid-looking requests doesn't trip the alarms built to catch credential theft or brute-force login attempts.
What was actually exposed
The honest answer is: it depends entirely on what each customer put into ServiceNow, which is itself the uncomfortable part. ServiceNow started as an IT service management tool and has expanded into HR case management, security incident response, asset and configuration management, and general workflow automation — meaning a typical enterprise instance can hold internal support tickets referencing sensitive business context, employee records tied to HR cases, hardware and software asset inventories, vendor and contract data, and operational documentation describing internal processes and system architecture. None of that is inherently as sensitive as a database of credit card numbers, but in aggregate it's a detailed operational map of an organization — the kind of contextual intelligence that makes follow-on social engineering, business email compromise, or targeted phishing dramatically more effective. An attacker who pulls internal helpdesk tickets learns who handles what, which systems are flagged as problematic, and how the organization talks about its own security incidents internally. That's not a headline-grabbing data type, but it's exactly the kind of material that turns a generic phishing email into a convincing one.
Practical takeaways for ServiceNow and large SaaS platform customers
- Audit what actually lives in your instance. Most organizations don't have a clear inventory of what's stored across every ServiceNow module in active use. Pull a data classification pass specifically for ServiceNow tables and minimize what doesn't need to be there — treat it the same way you'd treat an audit of a database holding regulated data.
- Push vendors for a concrete disclosure and patch SLA in writing. Ask specifically what the committed timeline is between a critical, unauthenticated-access bug bounty report and a production fix, and what the customer notification commitment looks like if that timeline is missed. A vague "we take security seriously" answer in a sales call isn't a control; a numbered SLA in a contract is.
- Monitor vendor security advisories proactively, not reactively. Subscribe to ServiceNow's (and every major SaaS vendor's) trust and security bulletin feed directly, rather than relying solely on a breach notification email that may arrive weeks after the exposure window opened.
- Build a distinct incident response playbook for vendor-side platform misconfigurations. This is structurally different from "our systems were breached" — there's no internal log to pull, no internal system to isolate, and the remediation timeline is entirely outside your control. Your playbook should define who owns vendor communication, how you assess exposure using only the vendor's disclosure, and what you tell affected internal stakeholders when you can't yet answer "what exactly was taken."
- Ask what monitoring exists on the vendor side for unauthenticated or anomalous API query patterns, and whether that monitoring would have caught exploitation faster than six weeks in a future incident. If the answer is unclear, that's useful information for your next vendor risk review.
The uncomfortable truth in this incident isn't that ServiceNow made a mistake — every large platform will, eventually, ship a misconfiguration with real consequences. It's that the mistake was invisible to every customer running on the affected infrastructure until the vendor chose to tell them, and that the gap between a responsible disclosure landing in a bug bounty inbox and a fix reaching production ran to six weeks on a bug with no authentication barrier at all. Vulnerability management built around CVEs and patch Tuesdays doesn't have a lane for "the vendor changed a setting and now your data is exposed." Until that gap gets closed — through faster vendor SLAs, better proactive advisory monitoring, and incident response plans that actually account for platform-side failures — enterprises running their operations on shared SaaS infrastructure are trusting a boolean they'll never see, set by a team they don't manage, on a schedule nobody outside the vendor controls.