ServiceNow Pre-Auth RCE Could Run Commands on Connected Proxy Servers

ServiceNow has patched CVE-2026-6875, a critical remote code execution flaw in its AI Platform that required no account. Searchlight Cyber found a path from a public request parameter into ServiceNow’s query engine, then out of a restricted script sandbox. The researchers said the resulting access could expose instance data, create administrators and run commands on connected proxy servers.

ServiceNow assigned the issue a 9.5 CVSS score. Its security advisory says hosted instances received a security update and that fixes are available for self-hosted customers and partners. The vendor’s CVE record said it was not aware of exploitation against ServiceNow instances when the advisory was published on July 13.

A query parameter reached the script engine

The vulnerable path began in /assessment_thanks.do, an unauthenticated page that passed sysparm_assessable_type into a GlideRecord query. GlideRecord is ServiceNow’s API for reading platform tables. Its filter syntax also supports values prefixed with javascript:, a feature that causes the platform to evaluate an expression before applying the query.

Searchlight’s technical account shows that the parameter could supply one of those expressions. ServiceNow did place filter expressions in a restricted sandbox. From that context, an unauthenticated user could not normally read sensitive tables or call the platform’s more powerful JavaScript functions.

The escape came from the way ServiceNow loaded reusable script includes. Those libraries were evaluated in a context without the extra filter restrictions. Searchlight found that it could alter global JavaScript objects before loading a suitable include. The include then invoked attacker-controlled values outside the restricted context and returned an executable function.

This was a chain, not a single missing access check. Query evaluation provided the first script execution. Global object manipulation and the script-include behavior provided the step into the broader Rhino runtime.

The proxy-server reach raises the impact

Searchlight reported that unsandboxed execution could read data from platform tables and create administrator accounts. The same access could run shell commands on proxy servers configured in the instance. Those servers commonly sit on internal networks so ServiceNow can reach systems that are not exposed to the internet.

That internal foothold changes the investigation. An exposed ServiceNow instance may have access to identity records, incident data, customer information and automation credentials. A connected proxy can extend that reach toward systems that trust the platform. Responders should treat the configured integrations as part of the affected environment until evidence shows otherwise.

The public record does not establish active exploitation. The NVD entry repeats ServiceNow’s statement that it was not aware of exploitation and lists high attack complexity in the CVSS vector. Searchlight published enough technical detail to explain the chain, so an absence of reported incidents is not a reason to leave an exposed instance unpatched.

Hosted updates do not close every ticket

Searchlight reported the vulnerability to ServiceNow on April 1. According to the research team, ServiceNow deployed initial mitigations to cloud instances within 24 hours and followed with patches for the underlying issues. The vendor also introduced Guarded Script, which sharply limits the JavaScript syntax accepted in sandboxed expressions.

ServiceNow’s affected-version data includes releases before Australia Patch 2, Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13, Zurich Patch 7b, Zurich Patch 9 and the listed Brazil releases. Customers should use the vendor advisory and their instance records to identify the required target release. A banner or family name alone is weak evidence because the fixed level varies across release lines.

Hosted customers still need confirmation that their instance received the update. Self-hosted and partner-managed environments need a patch record tied to the actual instance. Security teams should also identify internet-facing nodes, clones and nonproduction systems that may follow a different maintenance schedule.

Investigation should follow the execution path

Begin with requests to /assessment_thanks.do. Preserve the request parameter values and look for javascript: expressions in sysparm_assessable_type. Searchlight’s proof of concept contains a recognizable sequence of global-object changes and script-include calls, but defenders should avoid relying on one published string. Equivalent payloads can use different includes or formatting.

Then examine the outcomes the exploit was designed to produce. Review administrator creation, privileged account changes, unusual reads of sensitive tables and modifications to scripts or business rules. On connected proxy servers, inspect ServiceNow-initiated command execution, child processes, outbound connections and credential use during the exposure window.

The investigation window should begin before public disclosure if the instance was reachable and unpatched. Searchlight disclosed the endpoint and mechanics on July 14, but patch timing and exposure history provide better boundaries than publication date.

The AI label can distract from the immediate work. This flaw did not depend on prompt injection or model behavior. It affected the script and integration machinery around an AI-branded platform. Patch the instance, preserve the relevant web and platform logs, and include connected proxy servers in the scope decision.

Close the review only after every reachable instance is on its required fixed release, requests to the affected page are scoped, unexplained privileged changes are resolved, and connected proxy servers show no unaccounted ServiceNow-initiated command execution.