ServiceNow's CVSS 9.5 Sandbox Escape Is Now Exploited

A critical ServiceNow vulnerability moved from theoretical to active over the weekend. CVE-2026-6875, a sandbox escape in the ServiceNow AI Platform carrying a CVSS score of 9.5, lets an unauthenticated attacker break out of the platform's scripting sandbox and execute code on the instance. Threat intelligence firm Defused observed the first exploitation attempts on Friday, July 18, 2026, five days after ServiceNow published its advisory and shipped patches for self-hosted deployments. ServiceNow's platform runs workflows for roughly 85% of the Fortune 500, which makes the exposed population small in count and very large in consequence.

• No credentials are required. The flaw is reachable pre-authentication, so an attacker needs nothing but network access to a vulnerable instance.
• Self-hosted customers carried the risk longest. ServiceNow patched its own hosted fleet in April; on-premise and self-managed instances only got fixes on July 13, 2026.
• A second exploit path already exists. Defused reported a distinct sandbox-escape gadget chain that bypasses detection tuned to the published proof of concept, so signature-based blocking is not sufficient.
• Patch, then hunt. Because exploitation predates most detection rules, applying the update does not answer whether an instance was already reached.

What is actually broken?

ServiceNow is a workflow platform, and a large part of its value is that customers script it. Business rules, approvals, integrations and now AI agent actions all run customer-supplied logic on ServiceNow infrastructure. That logic is meant to run inside a sandbox, a restricted execution context that stops a script from touching the underlying system.

RelatedKemp LoadMaster Pre-Auth RCE Is Now Under Active Attack

CVE-2026-6875 is a failure of that boundary. Researcher Adam Kues of Assetnote, part of Searchlight Cyber, reported it to ServiceNow on April 1, 2026. The defect allows code to escape the sandbox and execute in the platform context, and critically it is reachable through an endpoint that responds before authentication runs. That combination, pre-authentication reachability plus sandbox escape, is what produces a 9.5 rather than a mid-range score. An attacker does not need a stolen credential, a phished session, or an insider. They need to be able to reach the instance.

Why did self-hosted customers carry more risk?

Because ServiceNow could fix its own fleet unilaterally and could not fix anyone else's. The company remediated ServiceNow-hosted instances in April, shortly after the report. Customers running the platform themselves, which tends to mean regulated industries, government and organizations with data residency requirements, received their patch when the advisory went public on July 13.

That gap is a structural feature of hybrid SaaS, not a lapse specific to this vendor. Coordinated disclosure holds details back so the vendor can fix things, and a vendor with a managed fleet gets the benefit of that fix immediately. Self-managed customers get it at publication, at the same moment attackers learn the bug exists. Five days later, exploitation started. ServiceNow says it has not observed evidence of compromise in instances it hosts, a statement that says nothing about the self-managed population.

What should defenders do today?

Patch first, on the assumption that exposure preceded detection. Confirm the instance version against the July 13 advisory rather than trusting a change ticket, because self-managed upgrade cycles routinely slip past a maintenance window.

Then treat detection as a second, separate problem. Defused reported a distinct gadget chain reaching the same sandbox escape, which means a rule written against the public proof of concept can be true and still miss live traffic. Blocking one request shape is not the same as closing the class of bug. Look for anomalous process execution and outbound connections originating from the instance rather than for a specific payload string.

RelatedA CVSS 10 UniFi flaw exposes 100,000 gateways to takeover

Finally, scope the blast radius honestly. A ServiceNow instance typically holds credentials and API tokens for the systems it orchestrates, which is the entire point of a workflow platform. Code execution on the instance is rarely the attacker's objective. It is the pivot toward identity providers, cloud accounts and ticketing data that describes exactly how the rest of the estate is built.

1. Apr 1, 2026Reported to ServiceNow Adam Kues, Assetnote / Searchlight Cyber
2. April 2026ServiceNow-hosted instances remediated No public advisory yet
3. Jul 13, 2026Advisory published, self-hosted patches ship CVE-2026-6875 assigned CVSS 9.5
4. Jul 18, 2026First exploitation attempts observed Defused telemetry, five days after disclosure
5. Jul 19 to 20, 2026Second gadget chain confirmed in the wild Bypasses detection tuned to the public PoC
6. NextProbable CISA KEV listing Would put federal agencies on a fixed remediation clock

Our take

The number worth remembering here is not 9.5. It is five, as in the five days between a public advisory and the first exploitation attempt. That interval has been compressing for years, and it has now compressed past the point where a monthly patch cycle is a coherent defense for internet-reachable enterprise software.

The uncomfortable part is that the self-hosted customers who were slowest to get a fix are frequently the ones who chose self-hosting for security reasons. Keeping the platform inside your own perimeter is a real control, and it also means the vendor cannot patch you, cannot see your logs, and cannot tell you whether you were hit. That trade was always the deal. This vulnerability is a clean illustration of which half of it bites.

Original analysis by GenZTech. Reporting based on the ServiceNow advisory of July 13, 2026 and independent exploitation telemetry published July 20, 2026.