What happened
Between June 2 and June 3, 2026, ServiceNow detected anomalous unauthenticated traffic sweeping a single REST endpoint across its hosted customer instances — concentrated on the platform's newly general-availability Australia release, with some older releases exposed too depending on their configuration history. The traffic traced to one IP address, 51.159.98[.]241. ServiceNow shipped an emergency patch on June 5, three days after the sweep began.
What the requests reached was real tenant data: IT support tickets, asset inventories, security incident records, and internal configuration details, plus whatever a given customer's own support cases happened to contain — which for some tenants meant embedded credentials and API tokens. Reporting on the incident describes roughly five unauthorized hits per affected tenant, which reads less like a mass scrape and more like a methodical, low-volume sweep across a platform serving thousands of enterprise customers from the same shared codebase.
The part of this incident that outlasted the patch wasn't technical. ServiceNow's bulletin, KB3067321, went out June 9 — four days after the fix shipped — and it was gated behind a customer support-portal login rather than published as a public security advisory. Most organizations running ServiceNow learned that their own hosted instance had already been targeted from security-research write-ups and news coverage, not from ServiceNow directly. A second, related patch covering two more endpoints with the same authentication gap followed on June 10 with even less visibility. No CVE had been assigned as of this writing.
How it worked
ServiceNow lets customers and ISVs build custom REST endpoints on the platform — Scripted REST Resources — and each one carries its own requires_authentication setting. On at least one shipped endpoint, /api/now/related_list_edit/create, that flag defaulted to false. Every functionally similar endpoint on the platform expects a caller to authenticate first; this one didn't. A request that reached it executed in the unprivileged Guest user context — a detail that matters less than it sounds like it should, because the endpoint's underlying query logic still resolved against real tenant tables a Guest session has no ordinary reason to touch.
The attacker's queries weren't aimed only at reading data. They targeted sys_group_has_role — the table that binds roles to user groups — attempting to append administrative roles to default or demo group structures already present on affected instances. That's a durability move, not a smash-and-grab: a successfully appended role sits in the data layer, not the vulnerable endpoint, so it would have survived the June 5 patch entirely. Closing the authentication gap stops new unauthenticated requests; it does nothing to a privilege grant that already landed before the fix shipped, which is why remediation guidance for this incident includes an ACL and role audit, not just confirming the patch applied.
Laid out as a chain, three of the four steps are the platform working exactly as designed — only the first is the actual defect:
- A Scripted REST Resource ships with requires_authentication set to false — the inverse of the platform's own default posture for equivalent endpoints.
- A request with no Authorization header reaches the endpoint, executes in the Guest context, and the endpoint's query logic runs against real tenant tables anyway — nothing downstream re-checks whether the caller should be there.
- The attacker uses the opening to attempt a write, not just a read — appending an administrative role via sys_group_has_role, a change that persists independently of the entry point once it lands.
- ServiceNow hosts thousands of enterprise tenants on the same platform release, so a misconfiguration in shared platform code isn't one customer's exposure — it's every tenant running that release, simultaneously, until ServiceNow itself ships the fix.
Why this matters beyond one company
A single boolean defaulting the wrong way is an easy thing to wave off as a one-off. What makes it worth dwelling on is where it shipped: not in one customer's own configuration, but in platform code ServiceNow controls and every hosted tenant inherits. A misconfigured IAM role — the kind of thing that sank Capital One — is a mistake one organization makes about its own environment. A misconfigured default in a shared SaaS platform is a mistake the vendor makes on behalf of every customer running that release at once, and no customer's own security team had a chance to catch it first, because no customer's own security team owns that code.
The disclosure choice compounds it. An advisory gated behind a login wall protects the vendor's messaging, not the customer's decision-making — a security team can't triage an incident, start a breach-notification clock, or decide whether to audit their own instance's ACLs against a bulletin they don't know exists. Enterprises under GDPR's 72-hour notification requirement don't get an extension because their SaaS vendor published quietly. The pattern here is a close cousin of what let the Capital One breach run four months before anyone noticed: not an absence of information, but information that didn't reach the people who needed to act on it in time to matter.
An unauthenticated endpoint sitting next to authenticated ones — the shadow-API pattern Apophis's authentication recon is built to surface as a Confirmed finding
Apophis's API penetration testing mode enumerates an application's full REST surface and, as a standing step in its authentication-recon phase, checks every discovered endpoint for whether it actually enforces authentication — not just whether the application has an auth scheme somewhere, but whether each individual endpoint applies it consistently with its neighbors. That's exactly the gap this incident turned on: one endpoint quietly missing a check every functionally similar endpoint on the same platform enforced. It's a directly testable condition, not a hypothetical attack chain — send the request without credentials, read what comes back. Apophis classifies this class under the OWASP API Security Top 10's Broken Authentication category (API2), one of the standard checks it runs against any REST surface it's pointed at, and it does so on every engagement rather than once a year, which matters for a class of bug a single bad deploy can reintroduce at any time.