ServiceNow CVE-2026-6875: A Pre-Auth Sandbox Escape Into Your Whole Workflow Platform

ServiceNow sits underneath the parts of a company that never make the threat model: IT tickets, HR onboarding, vendor risk, change management, the CMDB that every other tool trusts as source of truth. It is also, for many enterprises, the single most credential-rich system on the perimeter, because it integrates with everything. On July 13, 2026 ServiceNow finished shipping patches to self-hosted customers for CVE-2026-6875, a CVSS 9.5 unauthenticated sandbox escape that turns a pre-auth request into remote code execution inside the platform. By the following weekend it was being exploited in the wild — and the payloads seen in attacks did not match the proof-of-concept that had just been published.

That last detail is the whole story. This is not a post about a patch you should apply (you should — details below). It is about what happens when the route to a bug is not fixed by fixing one instance of the route, and why a vulnerability class with more than one exploitation path defeats every defense that was built around the first one someone published.

The bug: a javascript: prefix the query layer trusted

ServiceNow's platform runs untrusted JavaScript — including strings that arrive before authentication — inside a two-layer sandbox. The outer layer gives a script something close to platform-administrator reach but walls it off from the host operating system. The inner layer, the filter or script sandbox, is meant to be the hard boundary for user-supplied input: it blocks eval, dynamic Function construction, and access to Java classes.

The escape, discovered and reported by Searchlight Cyber, lives in how that boundary is reached. Pre-authentication application paths passed user-controlled input into ServiceNow's GlideRecord query API, and addQuery() accepts a javascript: prefix — which causes the platform to evaluate the JavaScript expression before using the result as a query argument. So a request reaches the query engine, the query engine runs your code. The documented pre-auth entry point is the endpoint /assessment_thanks.do, as BleepingComputer reported.

Getting into the script sandbox is not the same as getting out of it. The published research escalates through gs.include(), which loads script libraries in a less-restricted execution context. By manipulating global JavaScript objects and function-constructor behaviour that included scripts rely on, an attacker gets attacker-controlled code compiled and executed outside the strict sandbox — transitioning from "restricted filter expression" to "privileged ServiceNow scripting context." From there the isolation is over.

From sandbox escape to full instance compromise

CVSS 9.5 is not marketing. Once outside the inner sandbox, an attacker operates with the outer layer's near-admin reach. Concretely, the disclosed impact is:

• Read any table. The CMDB, incident records, HR cases, stored secrets in system properties — ServiceNow's data model is one big set of tables, and table access is total.
• Create administrator accounts. Persistence that survives the session and looks like a legitimate user until someone audits sys_user grants.
• Execute commands on connected MID Servers. This is the pivot that matters. A MID Server is the agent ServiceNow places inside your network to reach on-prem systems it orchestrates — Active Directory, vCenter, network gear. Command execution on a MID Server bridges a cloud SaaS compromise straight into the internal estate, using credentials the MID Server already holds.

So the blast radius is not "a ticketing system got popped." It is: read everything ServiceNow knows, mint yourself an admin, and step through the MID Server into the network ServiceNow was built to manage.

Why the ServiceNow CVE-2026-6875 PoC signature won't save you

Here is the part that should change how you think about it. When exploitation started over the weekend of July 18–19, threat-intelligence firm Defused observed that the in-the-wild payloads reached the same code-execution primitive by a different route than the published PoC — a second sandbox-escape gadget chain that bypasses defenses tuned to the first one. Help Net Security and TechTimes both reported the multi-route exploitation.

This is the failure mode of signature-based validation stated as cleanly as it ever gets. A sandbox escape is not a single string; it is a property of how the sandbox's escape hatches compose. gs.include() is one path out. The function-constructor trick is another lever. Any WAF rule, IDS signature, or "we tested the public exploit and blocked it" assurance written against the first gadget chain is blind to the second — and there is no reason to believe two is the ceiling. The class of bug (untrusted input reaching a sandbox with reachable escape primitives) generates exploits faster than defenders generate signatures for them.

"We ran the public PoC against our instance and our WAF blocked it — we're covered."

You blocked one serialization of the bug. The instance that got popped Saturday was hit by a chain your rule never saw, reaching the same gs.include()-class primitive from a different direction. The signature matched a payload. The vulnerability is a property.

The patch gap that let attackers walk in

The timeline is its own lesson in why "patched" is a fuzzy word for multi-tenant SaaS with a self-hosted tier. Searchlight Cyber reported the flaw to ServiceNow in early April 2026. ServiceNow patched its hosted instances in April — quietly, as cloud vendors do. Self-hosted customers, who run ServiceNow inside their own datacenters (regulated industries, government, defense), only received patches through June, with public disclosure and the technical write-up landing July 13. Exploitation followed within days.

That is the recurring shape of SaaS-with-on-prem CVEs: the vendor's own tenants are safe weeks before the customers who run the software themselves, and the public disclosure that finally warns the self-hosted fleet is also the starting gun for attackers. ServiceNow's public position as exploitation began was that it was "not currently aware of exploitation against ServiceNow instances" — while independent researchers were watching it happen. It is not the first time ServiceNow's query and template layers have been turned into RCE; the CVE-2024-4879 Jelly-injection chain was mass-exploited across exposed instances in 2024. The lesson from that round — that internet-facing ServiceNow is a high-value, actively-hunted target — did not expire.

Remediation

Treat any internet-reachable self-hosted ServiceNow instance as presumed-targeted. Work top to bottom.

1. Am I affected?

Check your instance family and patch level under System Diagnostics → Stats (or the instance's glide.war / build tag). You are vulnerable if you are running any of:

Release family	Vulnerable if below	Fixed version
Brazil	pre-EA/GA	Brazil EA, Brazil GA
Australia	before Patch 2	Australia Patch 2
Zurich	before Patch 7b / Patch 9	Zurich Patch 7b, Zurich Patch 9
Yokohama	before Patch 12 Hot Fix 1b / Patch 13	Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13

Hosted (ServiceNow-managed) instances were remediated by the vendor in April 2026. The exposure that matters now is self-hosted. Confirm exposure of the pre-auth surface: /assessment_thanks.do and any unauthenticated .do path reachable from the internet should not be.

2. Patch — exact fixed versions

Apply the fix listed for your family per ServiceNow advisory KB3137947: Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13. Do not defer because you ran the public PoC and it failed — a second in-the-wild chain already bypasses that assumption.

3. Can't patch this week? Compensating controls

• Enable Guarded Script, the ServiceNow mitigation that restricts the type of code allowed to run in sandbox contexts. It narrows the escape surface even where you cannot yet apply the version patch.
• Block the pre-auth sink at the edge. Deny unauthenticated access to /assessment_thanks.do and audit which .do endpoints your reverse proxy exposes without a session. Do not rely on a WAF rule that matches the published PoC string — write the rule against the endpoint, not the payload.
• Constrain MID Servers. Rotate MID Server service-account credentials to least privilege now, before an escape becomes a pivot. A MID Server that can reach Domain Admin is a pre-authorized lateral-movement path.
• Restrict management exposure. If the instance does not need to be internet-facing, put it behind VPN/ZTNA immediately.

4. Hunt for compromise

The pre-patch and post-patch exploitation window means detection matters even after you patch. Map to MITRE ATT&CK and hunt:

• Initial access — T1190 (Exploit Public-Facing Application): requests to /assessment_thanks.do and other pre-auth .do paths carrying javascript:-prefixed parameters or GlideRecord/addQuery/gs.include tokens in query strings or POST bodies. Review the node access logs and transaction logs (syslog_transaction), not just the WAF.
• Execution — T1059.007 (JavaScript): unexpected script execution outside authenticated business-rule/scheduled-job context; anomalous sys_script / sys_script_include activity.
• Persistence — T1136 (Create Account): new sys_user records with admin (or security_admin) roles created outside your provisioning workflow; new API tokens or OAuth clients.
• Lateral movement / credential access — T1210 and T1552 (Unsecured Credentials): unusual command execution or outbound connections originating from MID Server hosts; MID Server credential use against systems it does not normally touch.
• Collection — T1213 (Data from Information Repositories): bulk table exports, large sys_attachment reads, or off-hours queries against sensitive tables (CMDB, sys_user, credential/vault stores).

Because the in-the-wild chain differs from the PoC, hunt for the outcome (unexpected admin, MID Server anomaly, bulk table read) as much as the inbound signature.

5. Eradicate and verify

• Remove any admin/service accounts, API tokens, and OAuth registrations you cannot tie to a change record.
• Rotate everything the instance held: MID Server credentials, integration service accounts, stored connection secrets in system properties, and any credential the CMDB or a discovery job could read. Assume table contents were exfiltrated if you find evidence of exploitation.
• Confirm clean after patching — re-run detection against the patched instance, verify Guarded Script is enforced, and validate that no residual pre-auth .do exposure remains.

Where a generative pentest changes this scenario

The defining feature of CVE-2026-6875 is that a published PoC gave a false sense of coverage: the exploit that mattered took a different route to the same primitive. Signature-matching a single payload cannot validate a sandbox with multiple reachable escape hatches. Proving whether your instance is exploitable requires writing an exploit against your configuration — which .do endpoints you expose, which release and patch level, whether Guarded Script is on, what a MID Server can reach if the escape succeeds.

That is what Zero Hunt's 10-agent AI swarm does. Its Exploit and Web agents generate a per-target exploit chain with a local LLM — code written for the environment in front of them, not pulled from ExploitDB — so validation covers the class of escape rather than the one gadget chain a researcher happened to publish. Every candidate skill is backtested in the AI Gym (142+ self-evolving skills, benchmarked across Vulhub, NYU CTF Bench and Vulhub-Bench) before it runs against production, and each finding is ECDSA-signed with chain-of-custody so "we validated the ServiceNow exposure" is an evidence artifact, not an assertion.

The MID Server pivot is where the second pillar earns its place. If an escape does bridge into the internal network, the traffic it generates — a MID Server host suddenly executing commands and moving laterally, sustained queries against sensitive tables — is exactly the behaviour Zero Hunt's on-appliance deep-learning traffic model (four inference heads, 2.7+ Gbit/s, no cloud) is built to flag while it is happening, not in the next morning's SIEM digest. For a bug whose in-the-wild form outran its own PoC, the defense that holds is the one that tests the property and watches the behaviour — see the platform or get in touch.