⚠️ OFFICIAL UPDATE from ServiceNow – ServiceNow has published KB3067321 confirming the security issue described in this article. The following is their official statement in full:
On June 5, 2026, ServiceNow applied a security update to hosted customer instances. The update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended. The security update changes an endpoint configuration to limit access to authenticated users.
ServiceNow has detected anomalous activity relating to the security issue. For a subset of customers, they observed evidence of successful queries of instance tables. Affected customers have been notified directly via case. If you have not received a case, ServiceNow did not observe such activity on your instance and states no action is currently required.
Scope: The issue affects customers on the Australia platform release, or those who made certain configuration changes to instances on releases prior to Australia.
CVE status: ServiceNow is currently evaluating whether to publish a CVE based on their internal policies. The KB will be updated when more information is available.
Original Story Continues Below
ServiceNow is quietly notifying customers that a suspicious IP address accessed multiple tenants, and the story behind it is messier than the notifications suggest.
The activity traces back to June 2nd and 3rd. A foreign IP – 51.159.98.241, now circulating in a Reddit post was hitting a Scripted REST endpoint at /api/now/related_list_edit/create. Transaction logs across multiple affected organizations show a consistent pattern: roughly five hits per tenant, with most of the requests attempting to invoke related_list_edit operations. ServiceNow patched the issue over the weekend.
What the vulnerability actually was
The root cause is a Scripted REST Resource that shipped with requires_authentication set to false. That single misconfigured flag meant the endpoint accepted requests without any valid session, token, or credential check. When the attacker’s requests came in unauthenticated, ServiceNow had no user account to log against, so the activity shows up in transaction logs attributed to the Guest user. That’s been a source of confusion for a lot of teams. The attacker didn’t use a Guest account. There was no account. The endpoint simply didn’t ask for one.
There’s a secondary configuration detail worth understanding here. ServiceNow Scripted REST Resources have two relevant checkboxes: one for requiring authentication, and a separate one for enforcing ACLs. The distinction matters. An endpoint can require a valid login but still skip row-level and field-level ACL checks and vice versa. In this case, depending on which checkbox was toggled and when, the exposure window and what could actually be read or written may differ between tenants. Some administrators believe the authentication checkbox was enabled on their instance but the ACL enforcement was not, which would still allow an authenticated-but-unauthorized user to pull data they shouldn’t see. Others saw no authentication requirement at all.
The REST resource in question also reportedly hadn’t been meaningfully updated since 2018 – a detail that explains why its security defaults were out of line with more recently written resources.
What the attacker was doing
From what’s been pieced together, the requests were probing or attempting to create records via the related list edit API. Some tenants saw script errors logged during the same window – thousands of them in at least one case, which suggests the attacker was either fuzzing the endpoint or triggering failures by sending malformed payloads. Whether any records were successfully created, read, or exfiltrated is still unclear for most organizations, largely because REST message logging wasn’t enabled on most instances.
That’s the uncomfortable gap right now. You can see that the requests hit your instance. You can see the timestamp and the IP. What you generally cannot see, without REST logging turned on beforehand. is the request body or the response payload.
ALSO READ: ServiceNow Buys Armis for $7.75B: The Deal That Redefines Cybersecurity
ServiceNow knew in April
This is the part that will cause problems for organizations in regulated environments.
One security team independently discovered and reported the vulnerability to ServiceNow. During the escalation process, a ServiceNow support engineer shared an internal Problem Record (PRB) – with screenshots now in the reporter’s possession showing that ServiceNow had documented this vulnerability internally on April 7th. For roughly two months, the company classified it as a non-urgent issue and was planning to remediate it in a future release cycle. It took a customer forcing the conversation, with a screen share proving the exposure was real and not self-introduced, to accelerate that timeline.
The first two support agents who handled the initial report tried to close the case.
For organizations under SOC 2, HIPAA, FedRAMP, or similar frameworks, that April 7th internal knowledge date matters. If your data was accessed between April and the June patch, the question of when ServiceNow became aware and what they did with that awareness is directly relevant to your incident documentation and potentially to your vendor risk posture.
What to check now
If you haven’t already searched your transaction logs for 51.159.98.241, do that first. Filter for that IP against the /api/now/related_list_edit path. Five hits is a common count for affected tenants, though some saw more.
Beyond the immediate IOC, the broader audit worth running is pulling up your Scripted REST API table and reviewing every resource where requires_authentication is unchecked – especially anything not touched since before 2022. This configuration pattern isn’t exclusive to the specific resource that was exploited. Other endpoints may have the same posture.
If your instance doesn’t have REST message logging enabled, document that gap explicitly before your security team asks. You’ll need to explain what you can and cannot determine about payload content, and “we didn’t have logging on” is a much better answer when you’ve already written it down than when someone asks the question two weeks into an investigation.
One other note for teams not on the Australia release: don’t assume you’re safe because you’re on a different version. The vulnerable configuration is a flag value, not version-specific code. The question is whether that REST resource exists on your instance and how it’s configured, not which release you’re running.
