ServiceNow has released security updates for a critical vulnerability in its AI platform that could have allowed an unauthenticated attacker to execute code on vulnerable instances under certain conditions.
The flaw, tracked as CVE-2026-6875, affects the server-side sandbox used by the ServiceNow AI platform and has been classified as a remote code execution (RCE) vulnerability. According to the company, hosted customers have already received the necessary security updates, while patches have also been made available for self-hosted deployments and partners.
ServiceNow says it is not aware of any evidence that the vulnerability has been exploited in the wild.
A vulnerability inside the sandbox
The issue centers on the JavaScript sandbox used by ServiceNow to safely process user-controlled scripts.
Security researchers discovered that, under specific conditions, an unauthenticated attacker could escape those sandbox restrictions and execute arbitrary code within the ServiceNow platform. Successful exploitation could ultimately provide control over the affected instance and potentially impact connected infrastructure.
Technical details published by the researchers show that the attack abused ServiceNow’s GlideRecord query framework together with weaknesses in the platform’s script inclusion mechanism. By manipulating how JavaScript functions were loaded inside the sandbox, the researchers demonstrated a method of escaping the restricted execution environment and obtaining unrestricted server-side code execution.
According to the researchers, successful exploitation could allow an attacker to access platform data, create administrative users, and execute commands through configured MID Servers, extending the impact beyond the ServiceNow instance itself.
ServiceNow responds
ServiceNow says it deployed protections to its cloud platform shortly after receiving the report and has since released permanent fixes for supported product families.
The company recommends that all customers install the latest available updates if they have not already done so.
Patched releases include:
- Australia Patch 2
- Zurich Patch 7b
- Zurich Patch 9
- Yokohama Patch 12 Hot Fix 1b
- Yokohama Patch 13
- Brazil Early Access
- Brazil General Availability
Hosted ServiceNow customers received the security update automatically, while organizations operating self-hosted deployments are responsible for applying the available patches.
Guarded Script becomes part of the fix
Alongside the security update, ServiceNow is introducing a new security mechanism called Guarded Script, designed to reduce the attack surface for server-side sandbox execution.
Rather than allowing complex JavaScript inside sandboxed contexts, Guarded Script limits execution to simple expressions. Features such as variable declarations, loops, conditional statements, assignments, function definitions, and multi-statement scripts are no longer permitted within the restricted execution environment.
Existing instances automatically identify incompatible scripts, allowing administrators to review and migrate more complex logic into Script Includes where appropriate.
According to ServiceNow, enforcement for unauthenticated traffic begins immediately after upgrading. Authenticated workloads transition gradually on cloud-hosted instances over several weeks to reduce operational disruption.
Technical Analysis: How Researchers Escaped ServiceNow’s Sandbox
The research behind CVE-2026-6875 provides a detailed look at how a JavaScript sandbox can fail even when multiple security controls are present.
The vulnerability was discovered while researchers were auditing pre-authentication script execution paths inside the ServiceNow platform. Rather than targeting a traditional memory corruption bug, the attack focused on how user-controlled JavaScript was evaluated inside ServiceNow’s server-side scripting environment.
Step 1: User Input Reaches GlideRecord
ServiceNow applications frequently use the GlideRecord API to query internal tables.
A simplified example looks like this:
var gr = new GlideRecord('sys_user');gr.addQuery('active', 'true');gr.addQuery('email', '>', 'walter');gr.query();
Researchers observed that user-controlled input often flows directly into addQuery() calls, even before authentication, increasing the potential impact of parsing or evaluation flaws.
Step 2: JavaScript Evaluation
During testing, researchers discovered that GlideRecord accepted expressions beginning with the javascript: prefix.
For example:
javascript:'wal' + 'ter'
Instead of treating this as plain text, ServiceNow evaluated the expression before executing the query.
That behavior became the foundation for the rest of the attack chain.
Step 3: The Sandbox Prevented Full Execution
Initially, the injected JavaScript executed inside GlideSystemSandbox, a heavily restricted runtime designed specifically for untrusted scripts.
Within that environment:
- Dangerous Java classes were unavailable.
- Access to platform tables was heavily restricted.
eval()andnew Function()were blocked.- Function declarations were prohibited.
Those restrictions prevented straightforward remote code execution.
Step 4: Escaping the Sandbox
The breakthrough came from examining how Script Includes were processed.
Researchers found that functions loaded through gs.include() execute in a different JavaScript context that is not subject to the same sandbox restrictions.
By manipulating globally available objects during the include process, they were able to influence code executing outside the restricted environment and ultimately escape the sandbox.
Rather than relying on a traditional memory corruption vulnerability, the attack chained together several legitimate platform features in an unexpected way.
Impact After Sandbox Escape
Once outside the sandbox, the researchers demonstrated that they could:
- Read data from ServiceNow tables
- Create administrator accounts
- Execute privileged platform operations
- Run commands through configured MID Servers connected to internal enterprise networks
That combination effectively resulted in full platform compromise.
Why ServiceNow Introduced Guarded Script
As part of the remediation, ServiceNow introduced Guarded Script, which significantly reduces the amount of JavaScript permitted inside sandboxed execution.
The new implementation blocks features commonly used in complex scripts, including:
- Variable declarations (
var,let,const) - Function declarations
- Conditional statements (
if,switch) - Loops (
for,while) - Assignment operators
- Multiple statements within a single script
Instead, only simple expressions are permitted inside sandboxed contexts, reducing the opportunities for attackers to build multi-stage payloads.
Comes Weeks after another ServiceNow security incident
The latest disclosure arrives only months after ServiceNow addressed a separate security issue involving unauthorized API access.
Earlier this year, researchers revealed that attackers had abused exposed APIs to access customer information before the issue was fully disclosed. That incident raised questions about API security and disclosure timelines, although it is unrelated to CVE-2026-6875.
Read our previous coverage:
https://thecybersecguru.com/news/servicenow-api-vulnerability-breach/
While the two incidents involve different attack paths, they underscore the importance of maintaining visibility into both platform security updates and third-party integrations.
No exploitation reported
Unlike several enterprise platform vulnerabilities disclosed this year, ServiceNow says it has not identified evidence that CVE-2026-6875 has been exploited against customer environments.
That distinction is important.
Many high-profile vulnerabilities become public only after active attacks are detected. In this case, ServiceNow states that the issue was addressed proactively following responsible disclosure by security researchers.
The researchers also noted that ServiceNow deployed initial cloud mitigations within approximately 24 hours of receiving the report before later releasing comprehensive fixes across supported versions.
What administrators should do
Organizations using self-hosted ServiceNow deployments should verify that their environments have been updated to a patched release.
Administrators should also:
- Confirm the instance is running a fixed version.
- Review any scripts flagged as incompatible by Guarded Script.
- Move complex sandboxed logic into Script Includes where required.
- Monitor administrative activity following upgrades.
- Continue following ServiceNow’s security advisories for future platform updates.
Hosted customers should verify that their instances have received the latest platform updates and review any compatibility notifications generated after the rollout.
Final thoughts
Remote code execution vulnerabilities affecting enterprise SaaS platforms are relatively uncommon, particularly those that can be triggered without authentication.
Although ServiceNow says it has no evidence of active exploitation, CVE-2026-6875 demonstrates how weaknesses in scripting engines and sandbox implementations can have platform-wide consequences. The introduction of Guarded Script also signals a broader shift toward reducing the amount of executable logic permitted inside high-risk execution contexts.
For organizations that rely on ServiceNow for IT operations and workflow automation, keeping instances current remains the most effective defense while platform security controls continue to evolve.
