Public PoC Released for Critical ServiceNow Sandbox RCE Vulnerability

Security researchers have published technical exploit details for CVE-2026-6875, a critical ServiceNow AI Platform vulnerability that can allow unauthenticated remote code execution. ServiceNow has already updated its hosted environments and released security fixes for self-hosted customers and partners.

The vulnerability received a CVSS v4.0 score of 9.5. According to the ServiceNow security advisory KB3137947, an unauthenticated attacker could execute code within the platform under certain circumstances. Customers that manage their own instances should confirm that they have installed a fixed release.

Researchers at Searchlight Cyber’s Assetnote team demonstrated how an attacker could move from a pre-authentication query to code execution outside ServiceNow’s restricted scripting sandbox. Their ServiceNow sandbox research includes enough technical detail to make rapid patching a priority.

What Is CVE-2026-6875?

CVE-2026-6875 is a code injection and sandbox escape vulnerability in the ServiceNow AI Platform. The issue affects server-side JavaScript processing associated with user-controlled query expressions.

The National Vulnerability Database entry classifies the weakness as CWE-94, or improper control over the generation of code. Its network-accessible attack path requires no privileges or user interaction, although ServiceNow rates the attack complexity as high.

Successful exploitation could give an attacker broad access to a compromised ServiceNow instance. Researchers said the resulting scripting context could read data from platform tables, create administrator accounts and interact with connected MID Servers.

Vulnerability detail	Information
CVE identifier	CVE-2026-6875
Affected product	ServiceNow AI Platform
Vulnerability type	Code injection and sandbox escape
Maximum impact	Unauthenticated remote code execution
CVSS v4.0 score	9.5, Critical
Privileges required	None
User interaction	None
Known exploitation	Not confirmed by ServiceNow

How the ServiceNow Sandbox Escape Works

The attack begins with ServiceNow’s GlideRecord API, which applications use to query data stored in platform tables. Assetnote found pre-authentication application paths where user-controlled values reached GlideRecord query functions.

Some ServiceNow query values can contain a javascript: expression. The platform evaluates the expression before using its result in a database query. ServiceNow placed these expressions inside a restricted script sandbox designed to prevent access to sensitive methods, Java classes and unrestricted code execution.

The sandbox blocks capabilities such as direct eval calls, dynamic function construction and arbitrary function declarations. It also restricts database access for unauthenticated users. Those controls initially prevent a query expression from causing a meaningful compromise.

Script Includes Provided an Escape Route

The researchers found that the permitted gs.include() method could load ServiceNow Script Includes. These reusable server-side libraries were evaluated through a context that did not apply all the restrictions imposed on the original query expression.

By modifying global JavaScript properties used by an included script, the researchers redirected normal object and function behavior. Their technique caused attacker-controlled JavaScript to be compiled during the Script Include process and then executed outside the more restrictive sandbox.

The published Assetnote technical analysis shows how the researchers combined function constructors, altered object properties and a selected Script Include to achieve unsandboxed execution. The same report says the team disclosed the vulnerability to ServiceNow on April 1, 2026.

Why MID Servers Increase the Potential Impact

Unsandboxed access to ServiceNow’s Rhino JavaScript environment can expose powerful internal APIs. According to the researchers, an attacker could retrieve records from platform tables and create administrative users.

The attack could also reach configured ServiceNow MID Servers. Organizations commonly place these servers inside private networks so ServiceNow can communicate with internal applications, databases, discovery targets and infrastructure management systems.

A compromised instance could therefore become an entry point into connected corporate environments. The available impact depends on each MID Server’s permissions, network access and configured credentials, but the potential reach makes the vulnerability especially serious for large enterprises.

• Access data stored in ServiceNow tables
• Create or modify privileged accounts
• Change workflows and platform configurations
• Use configured MID Server capabilities
• Reach internal resources accessible to a MID Server
• Disrupt ServiceNow-dependent business processes

ServiceNow Patched Hosted Instances

ServiceNow said it deployed a security update to hosted instances. The company also provided patches to self-hosted customers and partners, who must verify their own deployment status.

The vendor’s CVE-2026-6875 advisory lists fixes across the Brazil, Australia, Zurich and Yokohama release families. Administrators should use the release that applies to their current branch instead of treating the listed versions as a sequence of updates.

The CVE-2026-6875 record says ServiceNow was not aware of exploitation against customer instances when the disclosure was published. However, the availability of detailed exploit research gives attackers more information for developing automated probes.

ServiceNow release family	Fixed release listed by ServiceNow
Brazil	Brazil EA or Brazil GA
Australia	Australia Patch 2
Zurich	Zurich Patch 7b or Zurich Patch 9
Yokohama	Yokohama Patch 12 Hot Fix 1b or Yokohama Patch 13

Guarded Script Adds Stronger Restrictions

ServiceNow also introduced Guarded Script protections to reduce the amount of JavaScript syntax permitted in sandboxed expressions. The change limits untrusted scripts to a single, simple expression.

The company’s Guarded Script documentation explains that variables, assignments, loops, control-flow statements, function declarations and multiple statements are no longer supported in guarded contexts.

Custom applications that relied on complex sandboxed scripts may require changes after the protection is enabled. Administrators should review incompatible scripts and move legitimate complex logic into properly controlled Script Includes.

• Variable declarations such as var, let and const are restricted.
• Control-flow statements such as if, switch, for and while are restricted.
• Function declarations are not accepted.
• Assignment operators are not supported.
• Only one simple expression is permitted per guarded script.

What ServiceNow Administrators Should Do

Self-hosted customers and partners should compare their installed release with the fixed versions immediately. Hosted customers should still confirm their instance status through ServiceNow support and review whether custom applications require changes under Guarded Script.

Security teams should investigate unexpected administrator creation, unusual table access, changes to Script Includes and suspicious activity involving MID Servers. They should also review logs and integration credentials covering the period before their instance received the mitigation.

The following actions can reduce immediate risk:

1. Confirm that every ServiceNow AI Platform instance runs a fixed release.
2. Review the Guarded Script guidance and resolve incompatible custom scripts.
3. Audit administrator accounts created or modified during the exposure period.
4. Review Script Includes, access-control rules and workflow changes.
5. Inspect MID Server activity for unexpected commands or outbound connections.
6. Rotate credentials if logs indicate unauthorized access to integrations or internal services.
7. Limit MID Server privileges and network access to required systems only.

FAQ