ServiceNow Patches Auth Bug After Attackers Pivot Deeper Into Hosted Instances
An unauthenticated flaw let intruders escalate access inside customer tenants before ServiceNow shipped a hosted-side fix.

ServiceNow has confirmed that unknown attackers abused a vulnerability in its platform to reach further into customer instances than they had any business being.
The company pushed a fix to hosted tenants on June 5, 2026, according to an advisory currently gated behind the customer portal. The patch addressed a flaw that, per ServiceNow's own description, allowed an unauthenticated user to obtain deeper unauthorized access on susceptible instances.
Translation: this was an auth problem, not an authz problem. The intruder did not need valid credentials at the front door. Once past it, they were able to reach resources that should have required a logged-in, scoped identity.
ServiceNow has not publicly assigned a CVE at the time of writing, nor has it specified which component — UI Builder, the Now Assist surfaces, the REST Table API, or one of the older SOAP endpoints — was the entry point. The advisory's customer-only posture is consistent with how ServiceNow has handled past platform-side issues: patch the multi-tenant fleet first, brief enterprise customers under NDA, publish sparingly.
That is defensible operationally. It is also frustrating for defenders trying to thread-hunt against a specific request signature.
A few things worth flagging while we wait for technical detail.
This is the second time in roughly two years that ServiceNow has had to ship an emergency fix for a pre-auth issue reachable on internet-exposed instances. CVE-2024-4879, the Jelly template injection bug in the Now Platform, was mass-exploited last year against tenants that lagged on patching. The pattern — unauthenticated reachability into a tenant that holds CMDB data, IT tickets, HR records, and frequently SSO secrets — is exactly the blast radius attackers want.
Would MFA have helped? Honestly, no. Pre-auth bugs route around the login flow entirely, which is why customers cannot rely on conditional access policies as a compensating control here. The mitigation surface is network-layer: IP allowlisting on the instance, WAF rules in front of /api/now/, and aggressive review of sys_audit and transaction logs for anomalous anonymous sessions.
For self-hosted ServiceNow deployments — rarer than the hosted fleet, but they exist in regulated verticals — administrators should assume the hosted patch will be mirrored in a Now Platform patch release and watch the for the corresponding KB.
Indicators of compromise have not been published. If your SOC has retention on ServiceNow audit logs going back to late May, pull anonymous or guest-context API calls that returned 200s against sensitive tables. That is where the story, if there is one in your environment, will be.
We will update this piece when ServiceNow releases CVE details or a researcher publishes a writeup.



