Shared responsibility looks different when the vendor's side of the deal quietly fails.
Shared responsibility looks different when the vendor's side of the deal quietly fails.
On June 5, ServiceNow patched a bug that had let unauthenticated users pull data from customer instances over the open internet. No phishing campaign and no stolen credentials. An internet-facing REST endpoint shipped with authentication switched off, and anyone who found it could query a customer's instance directly. Customers learned about it through a knowledge base article locked behind ServiceNow's support portal, then through Reddit threads where admins compared logs and traded indicators. TechCrunch and BleepingComputer picked the story up from there. If you run ServiceNow, this one deserves your attention.
What happened with the ServiceNow API exposure?
Administrators discussing the incident traced the issue to a REST endpoint at /api/now/related_list_edit/create that was configured with requires_authentication set to false, according to BleepingComputer. That one setting meant requests didn't need a password or token to reach instance data. ServiceNow's bulletin says the issue "could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended," and the company confirmed evidence of successful queries against instance tables for a subset of customers. In a public advisory published June 10, ServiceNow said it believes the activity was likely tied to security researchers or customer-led bug bounty testing rather than a malicious actor. That's plausible. It's also unverifiable from the outside, and hope isn't a control.
Who's affected by the ServiceNow security incident?
ServiceNow says the issue pertains to customers on the Australia platform release, plus customers on earlier releases who made certain configuration changes. The boundary looks softer in practice. TechCrunch reports that several admins outside Australia found evidence of external access to their instances. ServiceNow has opened support cases with every customer it believes was affected. If you haven't received one, the company's position is that you weren't impacted. Verify that yourself anyway. The vulnerable endpoint was reachable on any unpatched instance, and your own logs will tell you more than a vendor's probability estimate will.
What data could someone reach inside a ServiceNow instance?
ServiceNow hasn't disclosed what was accessed or taken. The exposure surface is the worrying part. Instances commonly hold support tickets, employee records, asset inventories and configuration details for corporate systems, as BleepingComputer notes. Support tickets deserve particular attention because people paste secrets into them. Passwords and API tokens shared during troubleshooting live on in ticket history, which is why support platforms keep ending up in attackers' crosshairs. The Salesloft Drift attacks followed the same logic against Salesforce customers last year.
Why does the ServiceNow disclosure timeline matter?
ServiceNow's own advisory acknowledges it received a confidential bug bounty submission describing a similar issue on April 22. The Hacker News reports a Reddit claim that the company had tracked the problem internally since early April and classified it as non-urgent, with remediation planned for a future release. The patch landed June 5, after anomalous activity had already begun. The first customer notice sat behind a login wall. None of that is unusual for a large vendor, and that's the problem. The window between a vendor knowing and a customer knowing is where your risk lives, and you don't get to set its length.
What should security teams do about the ServiceNow bug right now?
Start with your logs. Review requests to /api/now/related_list_edit, and look specifically for traffic from 51.159.98.241, the IP address admins shared as an indicator of potential compromise. Rotate any credentials or tokens that passed through support workflows, and confirm API logging is enabled going forward. Then ask the harder question. Could you say, today, which records in your ServiceNow instance would actually hurt if a stranger read them? Most teams can't, and that's the gap this incident exposes.
How do you prepare for the next SaaS vendor's bad default?
You can't control a vendor's endpoint configuration. You can control how well you know the data sitting behind it. That knowledge is what turns a vendor advisory from a crisis into a checklist. MIND's context-aware platform gives security teams that knowledge ahead of the incident, classifying sensitive data across SaaS apps by what it contains and how it moves. MIND isn't just classifying files. It's minding the places sensitive data quietly accumulates, including the ticket queues and workflow records nobody thinks of as a data store. When the next advisory lands, that's the difference between answering "what was exposed" in minutes and digging for weeks.
If this week had you searching ServiceNow logs without knowing what you were protecting, that's the gap worth closing. See what MIND looks like in your environment. Let's mind what matters.
