ServiceNow's Exploited Endpoint Was Not Broken. Its Auth Flag Was False.

4 SEP 2026 — ServiceNow has disclosed that attackers queried customer instance data through an unauthenticated API endpoint, on 2 and 3 June. The endpoint was not broken. Its authentication flag was set to false, so every unauthenticated request ran as the Guest user exactly as configured. That makes this a default rather than a defect.

What happened

The endpoint was a Scripted REST API at /api/now/related_list_edit/create. Its requires_authentication flag was false, so unauthenticated HTTP requests executed under the unprivileged Guest context and could read from instance tables.

Anomalous sweeps and data harvesting hit that endpoint on 2 and 3 June, reported as coming principally from a single address, 51.159.98.241. Attackers also attempted to write to sys_group_has_role, the table that maps groups to roles. On this platform, that is a privilege escalation attempt.

ServiceNow applied an emergency hotfix to hosted instances on 5 June. The support bulletin, KB3067321, went out on 9 June behind a customer login. Community accounts say the underlying issue was known internally from early April, with a fix deferred to a later platform release.

A flag is not a bug

The distinction changes who is responsible and what a customer should check next. A memory-corruption flaw is an unintended mistake in the code. A boolean that grants anonymous access is a setting somebody chose, inherited, or never reviewed.

Every component behaved as configured. A request arrived without credentials, so the platform assigned it the Guest role, and the query returned whatever Guest was permitted to see. Nothing in that chain malfunctioned. The control was doing exactly the job it had been given, and that job was to let anonymous callers in.

Hence the absence of a CVE and of a patch in the usual sense. There was no coding error to correct. Somebody changed a default instead.

The exposure follows from what Guest can read

Guest is unprivileged, and the instinct is to treat that as containment. On a platform where customers build their own tables, Guest access is not contained. The blast radius depends on each customer's own access controls rather than on the platform's.

A ServiceNow instance holds incident tickets, asset inventories, change records, employee data and whatever else the customer decided to model. Which of those a Guest can read depends on the access controls that customer wrote, and the population of customers who have carefully audited Guest read access against every custom table is not the whole population.

Exposure therefore varied by tenant, and nobody outside a given tenant can bound it. The attempt on sys_group_has_role is the more alarming detail, because it means the attackers were not content with what Guest could see and went looking for a way to become something else.

The disclosure path did the work twice

ServiceNow moved quickly on the fix. Exploitation ran on 2 and 3 June; a hotfix followed on 5 June, two days later, and few vendors do better.

The bulletin is where it goes wrong. Publishing on 9 June puts four days between the fix and the notice. Putting it behind a customer login means the people who most need to check their instance logs have to know the bulletin exists before they can read it. Threat intelligence teams outside the customer base cannot see it at all, which is how an actively exploited misconfiguration stays out of the public record for months.

The April claim, if it holds, is the more serious charge. Knowing about an unauthenticated endpoint and scheduling the fix for a future release is defensible engineering right up to the moment somebody finds it. It stops being defensible in retrospect. The claim comes from community accounts rather than from ServiceNow, and the company has not addressed it.

Software-as-a-service moves the audit you cannot do

An on-premises platform lets a security team enumerate its own endpoints, see which accept anonymous requests, and decide. That work is tedious, but it is possible.

On a hosted platform it is not. Both the endpoint list and the defaults applied to it belong to the vendor, so a customer learns about a flag like this one only when the vendor decides to say so. Here that was four days after the fix and seven days after the sweeps.

We reported in August on a single unrevoked token reaching three tools deep, and the shape is the same. In a hosted stack, the thing most likely to hurt you carries no CVE number, because it is a configuration nobody outside the vendor can see.

What a customer can actually do

Start with the logs rather than the patch; the patch has already been applied for you. Instance logs for 2 and 3 June record whether anything was read, and the single reported source address gives you something concrete to search for.

Then audit Guest. Every table in an instance has read access controls, and the ones written years ago for a since-retired integration are where anonymous read tends to survive. That audit is worth doing whether or not this endpoint touched you, because the next default will be different and the exposure will follow the same access rules.

The procurement question is the durable one. Ask a hosted vendor how it notifies customers of a misconfiguration, whether that notice is public, and how long it takes. One vendor has now answered in practice. Four days after its own fix, not publicly, and a week after the traffic that prompted it.