ServiceNow CVE-2026-6875: Pre-Auth RCE Explained

CVE-2026-6875 is a critical ServiceNow AI Platform vulnerability that can let an unauthenticated user escape a scripting sandbox and execute code under certain conditions. ServiceNow deployed updates to hosted instances and supplied patches to self-hosted customers and partners. Reports of attempted exploitation appeared after a technical analysis was released. The available evidence does not justify describing every observed attempt as criminal activity: the captured payload was identical to public research material, and ServiceNow has not confirmed compromise of the instances it hosts.

That uncertainty is not a reason to wait. The NVD record for CVE-2026-6875 describes unauthenticated code execution with complete confidentiality, integrity, and availability impact. The official ServiceNow article KB3137947 is the source for appropriate fixes. Organizations should confirm the installed release and patch state first, then conduct controlled threat hunting for earlier access.

What is known and unknown

ServiceNow published its advisory on 13 July, and Searchlight Cyber released a detailed analysis on 14 July. The researchers described a chain from an untrusted parameter used in a GlideRecord query, through JavaScript execution inside a restricted sandbox, to bypassing the additional constraints. In their environment, the resulting access allowed actions such as reading tables, creating administrators, and interacting with configured MID Servers.

On 18 July, Defused reported observed exploitation. It later corrected its account: the sample did not use a different variant but matched the published proof of concept. ServiceNow told SecurityWeek it was aware of the report, had not seen evidence involving vendor-hosted instances, and continued to recommend patching. There is no public confirmation of a named threat campaign, data theft, or mass compromise.

Statement	Status on 21 July 2026
the flaw can enable pre-auth RCE under certain conditions	confirmed by the CVE, vendor and researchers
patches are available	confirmed by ServiceNow
a technical path is public	confirmed
an exploitation sample was observed online	reported by a threat-intelligence company
a criminal used the sample	unconfirmed
ServiceNow-hosted instances were compromised	vendor says it found no such evidence
the flaw is in CISA KEV	not at publication time

Why a sandbox escape has severe impact

ServiceNow has its own data layer, ACL controls, GlideRecord query API, and scripting engine. User input reaches filtering logic in many locations. Executing some JavaScript does not automatically mean full compromise because the platform applies an additional sandbox to untrusted filters. CVE-2026-6875 becomes critical because it combines pre-authentication access, script execution, and a path into a context with much broader capabilities.

A sandbox is a security boundary. When the environment exposes functions or libraries that can be composed unexpectedly, individually permitted operations may form an escape chain. This resembles deserialization gadget chains: each part can have a legitimate purpose while the combination acts beyond intended policy. Secure-by-design analysis must therefore include interpreters, includes, reflection, and the boundary between sandbox and host, not merely the HTTP endpoint.

We do not reproduce a working payload here. Defenders gain more value from exposure inventory, patching, monitoring, and evidence analysis. Public technical detail reduces the time needed by researchers and scanners alike, so patch priority rises after disclosure even when attribution of early attempts remains uncertain.

SaaS instances and self-hosted environments

ServiceNow says it deployed the update to hosted instances. Customers should still verify a specific release and patch level rather than relying only on the SaaS operating model. Instances can have different maintenance windows, partners, and extensions. Preserve the version evidence and relevant support communication.

Self-hosted customers must apply the relevant fix. The CVE record identifies affected Australia, Yokohama, Zurich, and Brazil branches with corresponding patch levels. Because the list includes release and hotfix variants, the KB and vendor support should be treated as the source of truth rather than a simplified table in an external article.

In both models, the customer owns roles, data, integrations, accounts, and response. Even when the platform receives an automatic update, a previously stolen token, unknown administrator, or modified integration rule does not disappear. Closing the entry path and removing incident impact are distinct operations.

Why MID Server can expand the blast radius

MID Server bridges a ServiceNow instance and internal resources. It can run discovery, automation, integrations, and orchestration. Depending on configuration, it reaches servers, devices, clouds, and management systems. Searchlight’s research indicates that their level of access could run commands on configured MID Servers.

This does not mean every installation leads automatically to a whole domain compromise. Impact depends on service-account roles, segmentation, destination allowlists, script capabilities, and credential storage. Treat MID as a privileged workload with least privilege, distinct identities, and tightly constrained egress.

An internal network segmentation test should determine whether a compromised MID could reach domain controllers, hypervisors, backup systems, or other administrative zones. Safe validation uses laboratory accounts and harmless canaries rather than destructive commands.

A four-hour response plan

1. Inventory instances

Identify production, test, development, demo, disaster-recovery, and partner environments. Include vanity domains, public addresses, release family, patch level, hosting model, owner, and associated MID Servers. Asset inventory is more valuable than scanning only the primary domain.

2. Confirm the fix

Compare each instance against KB3137947. Preserve SaaS version evidence and deployment messages. For self-hosted systems, retrieve the package from a trusted channel, verify integrity, create a backup, and follow vendor instructions. Do not run an aggressive public PoC against production.

3. Reduce exposure

If the patch cannot be installed immediately, ask ServiceNow for a supported mitigation. Restrict public access where the business permits, use WAF policy only as a temporary layer, and monitor requests to unauthenticated endpoints. A WAF signature does not replace a patch because encoding and query variants may bypass it.

4. Hunt for evidence

Preserve application, reverse proxy, WAF, identity, administrative-change, integration, and MID logs. Look for new administrators, ACL modifications, unfamiliar integrations, unusual table queries, MID execution, and bulk exports. Correlate time, account, source address, and request identifier. If retention is short, export data to a protected repository first.

Distinguishing research scanning from compromise

A single PoC-like request does not prove success. It may come from an authorized organizational scanner, an ASM provider, a researcher, or an attacker. Compromise evidence requires an effect: an unusual process, account change, data access, MID operation, or request chain consistent with successful execution.

Use three evidence levels:

attempt — a request matches the technique without confirmed effect;
probable success — the response and subsequent behavior indicate execution;
confirmed incident — a platform artifact, account, process, data event, or operation resulted from unauthorized action.

This classification avoids both dismissal and an unsupported breach announcement. A cyber threat intelligence process should retain the confidence and source behind each assessment.

What to investigate after finding evidence

Preserve evidence first and avoid changes that destroy the timeline. Export audit logs, users and roles, configuration history, integration activity, OAuth tokens, scripts, jobs, and MID data. Revoke suspicious sessions and tokens while keeping identifiers required for correlation.

The potential access determines credential rotation scope. If the platform stored internal-system credentials or could call MID, changing only a ServiceNow administrator password is insufficient. Review vault entries, discovery accounts, API keys, integration certificates, and cloud secrets.

After remediation, validate again: patch level, absence of unknown accounts, integrity of critical rules, and a controlled test showing that the vulnerable path is closed. The first 72 hours of incident response should name the person authorized to isolate MID and notify customers or regulators.

Long-term ServiceNow hardening

Limit public endpoints and functions to required use cases.
Require phishing-resistant MFA for administrators and support.
Separate script authoring, publication, and audit roles.
Give MID distinct accounts for different zones and tasks.
Restrict MID egress and destinations with allowlists.
Export critical change logs to an independent system.
Detect administrator creation, bulk reads, and new integrations.
Maintain a test instance for safe patch validation.
Run a tabletop exercise covering SaaS and automation compromise.

Role and integration verification belongs in a broader penetration-test preparation review. A workflow platform often connects IT, HR, finance, and operations, allowing one defect to cross multiple business-process boundaries.

FAQ

Is CVE-2026-6875 actively exploited?

There is a public report of an observed attempt. After correction, the payload is known to match published research material. It is unknown whether an attacker, researcher, or scanner sent it. ServiceNow has not confirmed compromise of the instances it hosts. Risk remains high because the issue is a pre-auth RCE with public technical details.

Are SaaS instances safe now?

The vendor says updates were deployed to hosted instances, but customers should verify their release and support communication. A patch closes the flaw; it does not rule out access before the update.

Is a WAF sufficient?

No. It can filter some attempts but is not a durable repair for interpreter and sandbox logic. A supported patch and log review remain the priority.

The main conclusion

CVE-2026-6875 combines three severe properties: access before login, escape from a security boundary, and potential reach into privileged automation. Teams do not need to wait for a confirmed criminal campaign before updating. They do need precise evidence language: an exploitation attempt is not yet a confirmed breach.

Is ServiceNow or MID Server part of a critical environment? BreachRoad can perform defensive exposure validation, threat hunting, and segmentation review without running a destructive PoC. Contact us to define the scope.