CVE-2026-6875: ServiceNow AI Platform Sandbox Escape, RCE Risk, and Safe Exposure Review

CVE-2026-6875 is a critical remote code execution vulnerability in the ServiceNow AI Platform. An unauthenticated attacker can, under specific conditions, reach a server-side scripting path, escape an additional low-trust script sandbox, and execute code with substantially broader platform capabilities.

The official CVE record assigns the issue a CVSS 4.0 base score of 9.5. Its vector describes a network-accessible attack that requires no privileges and no user interaction, while rating attack complexity as high. The record also indicates high impact to confidentiality, integrity, and availability in both the vulnerable system and subsequent systems. CISA’s ADP enrichment associates the vulnerability with CWE-94, Improper Control of Generation of Code. (NVD)

ServiceNow published its advisory on July 13, 2026. The vendor said it had deployed a security update to hosted instances and provided relevant patches to self-hosted customers and partners. The initial advisory stated that ServiceNow was not aware of exploitation against ServiceNow instances at that time. (NVD)

That risk statement later required additional context. On July 20, the Canadian Centre for Cyber Security updated its advisory to say that open-source reporting indicated CVE-2026-6875 was being exploited in the wild. Defused reported observing malicious requests against the same pre-authentication endpoint documented by Searchlight Cyber, although the attackers reportedly used a different sandbox-escape gadget to reach the code-execution primitive. ServiceNow subsequently said it had not observed evidence that the reported activity was associated with instances hosted by ServiceNow. (Help Net Security)

Those statements are not necessarily contradictory. ServiceNow can lack evidence of compromise in its hosted fleet while third parties observe attempted exploitation against self-hosted, partner-operated, lab, or otherwise exposed instances. Defenders should therefore avoid reducing the entire question to “exploited” or “not exploited.” The operational questions are more specific:

• Which ServiceNow instances does the organization own or depend on?
• Which release family, patch, and hot fix is each instance running?
• Was the relevant update applied before public technical disclosure?
• Was the instance reachable from an untrusted network during the vulnerable period?
• Did suspicious requests reach it?
• Did any request produce platform changes, credential access, abnormal automation, or MID Server activity?

The answer to CVE-2026-6875 is not to send a public exploit to production and see whether it works. The safe response is to establish patch evidence, review exposure, preserve logs, hunt for suspicious activity, assess connected infrastructure, and perform controlled post-remediation validation.

CVE-2026-6875 at a Glance

Item	Confirmed information
CVE	CVE-2026-6875
Product	ServiceNow AI Platform
Vulnerability class	Code injection and sandbox escape leading to remote code execution
CWE	CWE-94, Improper Control of Generation of Code
CVSS 4.0	9.5 Critical
Network reachable	Yes
Authentication required	No
User interaction required	No
Attack complexity	High
Publicly documented entry point	/assessment_thanks.do
Publicly documented parameter	sysparm_assessable_type
Potential platform impact	Unauthorized server-side code execution and broad access within the ServiceNow instance
Potential connected-system impact	Researchers reported the ability to execute commands through configured proxy or MID Server infrastructure
Reported to ServiceNow	April 1, 2026
Public CVE disclosure	July 13, 2026
Research publication	July 14, 2026
Reported in-the-wild activity	Third-party reports published July 20, 2026
Primary remediation	Apply the applicable ServiceNow patch or upgrade to a fixed family release

The endpoint and parameter are useful detection pivots, but they are not a complete vulnerability definition. The vulnerable behavior arises from the way untrusted query values can enter a JavaScript evaluation path and then interact with a more privileged script-loading context. Blocking one URL string, one function name, or one published gadget does not remove the underlying condition.

This distinction became immediately important when Defused reported that observed payloads reached the same pre-authentication sink but used a different sandbox-escape route from the one described in Searchlight Cyber’s public proof of concept. That observation suggests defenders should treat exact exploit-string signatures as supplemental indicators, not as durable protection. (Help Net Security)

Disclosure and Exploitation Timeline

April 1, 2026

Searchlight Cyber researcher Adam Kues reported the vulnerability to ServiceNow. The research team says ServiceNow deployed strong mitigations to cloud instances within approximately 24 hours. According to the researchers, the immediate response prevented modification of key JavaScript functions, while deeper patches addressing the underlying issues followed during the subsequent weeks. (Searchlight Cyber)

April through June 2026

ServiceNow continued preparing and distributing updates. Public reporting differs slightly on the exact delivery timeline for every customer category, but the consistent facts are that hosted instances received vendor-side action and relevant updates were made available to self-hosted customers and partners. Help Net Security later clarified that patches were provided to customers throughout June, rather than only at public disclosure. (Help Net Security)

This distinction matters in investigations. A self-hosted organization should not assume that publication on July 13 was necessarily the first moment a fix could have been available to it. The organization should obtain its own support notifications, patch records, maintenance tickets, and platform build history.

July 13, 2026

ServiceNow publicly disclosed CVE-2026-6875 and published its advisory. The CVE record stated that the vendor had addressed the remote code execution issue, deployed a security update to hosted instances, and supplied relevant updates to self-hosted customers and partners. It recommended prompt application of the appropriate update or an upgrade to a patched release. (NVD)

July 14, 2026

Searchlight Cyber published a detailed technical account of the vulnerability. The research explained the GlideRecord query behavior, the pre-authentication sink, the additional script sandbox, the Script Include mechanism, and the gadget chain used to cross the sandbox boundary. (Searchlight Cyber)

The technical publication changed the defender’s operating environment. Before publication, exploitation knowledge was concentrated among the researchers and vendor. After publication, offensive teams could analyze the root cause, search for alternative gadgets, and build detection or exploit tooling.

July 18 through July 20, 2026

Defused reported observing in-the-wild exploitation attempts beginning around Friday, July 18. The reported requests targeted the same /assessment_thanks.do sink but used a different gadget path from the public research. On July 20, the Canadian Centre for Cyber Security updated its advisory to acknowledge open-source reports of exploitation. (Canadian Centre for Cyber Security)

ServiceNow told security media that it was investigating the reporting and had not observed evidence that the activity involved ServiceNow-hosted instances. The vendor continued to urge both hosted and self-hosted customers to apply relevant patches if they had not already done so. (Help Net Security)

The practical meaning of the timeline

A vulnerability status is a time-bound statement. “No known exploitation” on July 13 does not cancel exploitation evidence published on July 20. Conversely, a third party observing hostile requests does not prove every request succeeded, that every ServiceNow deployment was vulnerable, or that ServiceNow’s hosted environment was compromised.

Incident responders should preserve all three levels of evidence:

1. Attempt evidence — a suspicious request reached an exposed endpoint.
2. Execution evidence — the request caused abnormal server-side evaluation or platform behavior.
3. Impact evidence — records, roles, credentials, workflows, MID Servers, or connected systems were accessed or changed.

A WAF alert can establish the first level. It cannot, by itself, establish the second or third.

Affected and Fixed ServiceNow Releases

The official CVE record describes the affected product as ServiceNow AI Platform and identifies vulnerable versions relative to fixed family releases. The listed boundaries are:

• Versions before Australia Patch 2
• Versions before Yokohama Patch 12 Hot Fix 1b
• Versions before Yokohama Patch 13
• Versions before Zurich Patch 7b
• Versions before Zurich Patch 9
• Versions before Brazil EA
• Versions before Brazil GA

The Canadian Centre for Cyber Security reproduces the same family-level guidance. (NVD)

These entries should not be interpreted as one linear semantic-version sequence. ServiceNow customers may be on different family and maintenance branches. “Zurich Patch 7b” and “Zurich Patch 9,” for example, can represent different valid remediation paths depending on the customer’s current build and support guidance.

Release family	ServiceNow-listed fixed line	Defender action
Australia	Australia Patch 2	Confirm the instance is at Patch 2 or a later applicable build
Yokohama	Patch 12 Hot Fix 1b or Patch 13	Identify the exact branch and confirm the supported fixed target
Zurich	Patch 7b or Patch 9	Confirm which maintenance line applies to the instance
Brazil	Brazil EA or Brazil GA	Confirm the applicable Brazil release path with ServiceNow
Older or unusual branches	Not safely inferred from public naming alone	Open a ServiceNow support case and obtain explicit remediation guidance

Do not determine exposure solely from a page title, footer date, HTTP header, favicon, or an unauthenticated banner. Those signals may be cached, customized, hidden by a proxy, or unrelated to the actual build.

Reliable patch evidence should include several of the following:

• The instance’s recorded family, patch, and hot-fix build
• A ServiceNow support notification or case
• A completed change-management record
• Upgrade or patch deployment logs
• Post-upgrade health checks
• Confirmation that all application nodes were updated
• Confirmation that disaster-recovery and standby systems were updated
• Confirmation that dormant clones or test environments were removed or patched
• Confirmation that rollback images do not restore a vulnerable build

For ServiceNow-hosted instances, the vendor’s cloud-side action is an important control, but customers should still verify their instance state. Hosted customers may have clones, integration nodes, partner-managed components, or related environments outside the simplest hosted-instance assumption.

Self-hosted and partner-operated deployments require especially careful review. The organization is responsible for confirming that the correct package was obtained, installed, and retained across every active node and recovery path.

Why ServiceNow Is a High-Impact Control Plane

ServiceNow is not only a ticketing website. The ServiceNow AI Platform is the foundation for products and workflows spanning IT, customer relationship management, employee experience, risk, security operations, and application development. ServiceNow describes the platform as a unified layer for AI, data, workflows, and security. (ServiceNow)

That concentration creates operational value, but it also increases the impact of platform-level code execution. A typical ServiceNow environment may contain or control:

• Incident, problem, and change records
• Asset and configuration-management data
• Employee and customer records
• Security incident and vulnerability workflows
• API credentials and integration configurations
• Approval chains
• Notifications and outbound messages
• Custom applications
• Script Includes and business rules
• AI Agents and Virtual Agent workflows
• Connections to identity providers
• Connections to monitoring, security, cloud, and endpoint systems
• MID Servers with access to internal networks

The exact content varies by organization. CVE-2026-6875 does not prove that every affected instance exposes every category. It means successful platform-level code execution can occur in a context where those capabilities may exist.

GlideRecord and server-side scripting

Searchlight Cyber’s analysis focused partly on GlideRecord, ServiceNow’s API for working with platform tables. Developers and administrators can build queries through JavaScript or Java APIs rather than writing SQL directly. A simplified server-side query might create a GlideRecord for a table, add conditions, execute the query, and iterate through matching records. (Searchlight Cyber)

The security-sensitive behavior is that ServiceNow query filters can support JavaScript evaluation. This is a legitimate platform feature in trusted contexts. The problem appears when attacker-controlled values reach an evaluation path from an unauthenticated request.

Dynamic evaluation is not automatically a vulnerability. It becomes dangerous when the platform fails to preserve the intended trust boundary around the evaluation context.

Two relevant security layers

The research describes two broad levels of restriction.

The first is the general ServiceNow server-side scripting environment. It limits access to Java classes and underlying resources, helping protect tenant boundaries and the host environment. Even within those restrictions, however, ordinary server-side platform scripting can have extensive access to ServiceNow tables, configuration, and connected automation.

The second is an additional script sandbox used for lower-trust sources such as query filters. This layer is intended to impose much tighter limits. The researchers found that the sandbox restricted the gs object, limited exposed Java classes, constrained table access, and prohibited obvious dynamic-code mechanisms such as eval, the Function constructor, and normal function declarations. (Searchlight Cyber)

That second layer was the boundary CVE-2026-6875 ultimately crossed.

Script Includes and capability transfer

ServiceNow Script Includes provide reusable server-side code. The research found that gs.include() remained available in the restricted context. Loading a Script Include required the platform to evaluate library code in a context that did not have the same restrictions as the caller’s low-trust expression.

A privileged library does not have to be vulnerable merely because an untrusted caller can invoke it. A secure capability model can expose a small, immutable, carefully reviewed interface.

The dangerous condition appears when three properties combine:

1. The low-trust caller can influence global state or objects used by the library.
2. The privileged loader evaluates library code outside the low-trust sandbox.
3. The loaded code calls mutable global functions, constructors, or prototypes whose behavior can be redirected.

This creates a form of cross-context capability confusion. The sandbox may correctly block a direct call to a dangerous constructor, but a higher-trust include can indirectly call an attacker-influenced reference to that constructor.

The MID Server connection

ServiceNow MID Servers are Java applications installed inside customer networks. ServiceNow documentation describes a MID Server as a mediator between the instance and the network. Applications can use it to communicate with internal systems, collect discovery data, and move data through the firewall to the ServiceNow instance. (ServiceNow)

MID Servers can also support privileged commands. ServiceNow documents mechanisms for running SSH commands with elevated privileges when discovery or management tasks require them. The platform also provides a MID Server command audit log for Discovery commands. (ServiceNow)

Searchlight Cyber reported that its successful sandbox escape could access platform data, create administrator users, and execute shell commands on configured proxy servers. That does not mean every MID Server can run arbitrary commands against every internal host. The result depends on installed capabilities, credentials, allowlists, sudo configuration, network routing, and application use. It does mean MID Server review is part of the CVE-2026-6875 response, not an optional afterthought. (Searchlight Cyber)

How the Sandbox Escape Worked

The following explanation deliberately omits the complete ServiceNow exploit payload and the exact production-ready gadget sequence. The relevant defensive lesson is the trust-boundary failure, not a copy-and-paste attack.

Stage 1 — Unauthenticated input reaches a query

The public research identified /assessment_thanks.do as a pre-authentication endpoint. The sysparm_assessable_type request parameter was passed into a GlideRecord query against the asmt_metric_type table. (Searchlight Cyber)

In simplified form, the data flow was comparable to:

var record = new GlideRecord("asmt_metric_type");
record.addQuery("sys_id", untrustedRequestValue);
record.query();

That simplified example is not, by itself, proof of a vulnerability. A structured query API may safely treat the input as a literal value. The critical behavior was that a specially formed query value could cause JavaScript evaluation.

Stage 2 — The value is interpreted as JavaScript

ServiceNow filter syntax supports values prefixed with javascript: in legitimate administrative and application contexts. Searchlight Cyber found that the same behavior could be reached through the pre-authentication query sink. (Searchlight Cyber)

The initial code did not execute with unrestricted platform privileges. It ran inside the stricter GlideSystemSandbox context. This explains why a simple test expression did not immediately produce the same capabilities as an ordinary administrator script.

Stage 3 — Direct dangerous operations remain blocked

A well-designed sandbox blocks obvious primitives:

• Dynamic evaluation
• Construction of new functions
• Access to dangerous Java classes
• Arbitrary table reads
• Function declarations
• Direct file or process access

The researchers observed many of these restrictions. That is important because CVE-2026-6875 was not simply “ServiceNow forgot to disable eval.”

The failure appeared at the boundary between the restricted evaluator and another feature.

Stage 4 — Script Includes cross into a different context

gs.include() loads server-side reusable code. The research found that included code was evaluated through a new execution context that did not carry the same sandbox constraints. This was necessary for legitimate Script Includes to define classes and functions that the restricted parser would otherwise reject. (Searchlight Cyber)

The security assumption was presumably that trusted include code remained trusted even when invoked by a restricted caller.

That assumption fails if the restricted caller can modify objects or references that the trusted include uses.

Stage 5 — Mutable global state becomes a gadget

ServiceNow’s server-side JavaScript environment uses shared objects, class helpers, prototype operations, and constructor references. The public research found a way to influence a global helper used when a Script Include created a class.

The low-trust expression could not directly instantiate an unrestricted Function constructor. It could, however, cause a privileged include to invoke a modified global reference during class construction. The trusted code effectively performed the dangerous operation on behalf of the restricted caller.

This is analogous to a confused deputy:

• The sandboxed code lacks permission.
• A privileged mechanism has permission.
• The sandboxed code can control an argument, callback, object property, or global reference consumed by the privileged mechanism.
• The privileged mechanism performs the restricted action without preserving the original trust context.

Stage 6 — The code-execution primitive becomes broadly useful

Once the attacker crossed the additional script sandbox, the remaining environment provided much more powerful platform capabilities. Searchlight Cyber reported access to platform tables, the ability to create administrator users, and the ability to reach configured proxy servers. (Searchlight Cyber)

The distinction between “sandbox code execution” and “platform code execution” is essential. A sandbox may allow harmless arithmetic or restricted query construction. A sandbox escape turns that limited feature into a route toward the capabilities of the surrounding platform.

The Security Boundary That Failed

Expected boundary	Actual behavior identified by researchers	Resulting risk	Defensive design direction
Untrusted query values should remain data	Certain values entered a JavaScript evaluation path	Attacker-controlled expressions could execute
Filter scripts should remain in a restricted evaluator	Script Includes were loaded through a different execution context	Low-trust code could interact with higher-trust code
Trusted includes should behave deterministically	Included code depended on mutable global objects and helpers	The caller could redirect privileged behavior
Blocking direct eval should prevent dynamic code creation	A privileged gadget could indirectly reach an equivalent primitive	Direct denylisting did not secure the full call graph
Sandbox restrictions should contain impact	Escaped code gained broad ServiceNow scripting capabilities	Instance data, roles, workflows, and integrations could be affected
Internal connectors should be isolated from web compromise	Configured proxy or MID Server capabilities could be reached from the instance	Platform compromise could extend into internal networks

This failure pattern is broader than ServiceNow. Any dynamic application platform should treat cross-context loading, plugin systems, template engines, expression evaluators, and shared mutable globals as security boundaries.

A sandbox is not secure merely because dangerous names are blocked. It must also ensure that untrusted code cannot influence what trusted code later calls.

Why High Attack Complexity Does Not Make This a Routine Patch

The CVSS vector rates attack complexity as high. That rating should inform analysis, but it should not be converted into “low urgency.”

High complexity can mean that exploitation requires a precise chain of language behaviors, object manipulation, parser constraints, or platform-specific gadgets. It does not mean the attacker needs:

• A valid account
• An administrator role
• A victim to click a link
• An existing internal foothold
• Physical access
• A long interactive session after the exploit is built

The same vector states that the attack is network accessible, requires no privileges, and requires no user interaction. (NVD)

Once public research explains the vulnerable sink and code-execution primitive, other researchers and attackers can search for simpler or more reliable gadget chains. Defused’s report that real-world payloads used a different sandbox-escape route is a concrete reason not to equate the complexity of the first public exploit with the complexity of all future exploitation. (BleepingComputer)

The operational priority should be driven by the combination of:

• Unauthenticated reachability
• Platform-level impact
• Internet exposure
• Public technical detail
• Reported exploitation activity
• Connected internal infrastructure
• Availability of an official fix

CVE-2026-6875 has all of those risk multipliers except that the exact level of exposure and connected-system impact remains organization-specific.

Potential Impact and Blast Radius

ServiceNow table access

Searchlight Cyber reported that escaped code could pull data from platform tables. ServiceNow tables may hold sensitive operational, identity, customer, employee, asset, security, and workflow information. The exact accessible records depend on the execution context and instance configuration, but an incident-response review should assume that high-value tables may have been exposed until evidence demonstrates otherwise. (Searchlight Cyber)

Potentially relevant categories include:

• User and group records
• Role assignments
• Configuration items
• Incident and security case data
• Change and approval records
• Knowledge articles
• Integration settings
• Credentials or references to credential stores
• AI Agent definitions
• Business rules and Script Includes

This list is a hunting guide, not a claim that all fields are stored in plaintext or that every ServiceNow instance contains the same tables.

Identity and role manipulation

The researchers reported the ability to create administrator users. A successful attacker may also be able to alter existing accounts, add roles, change group membership, modify ACLs, create API users, or establish less obvious persistence through workflow and script configuration. (Searchlight Cyber)

ServiceNow documents that user-role changes are tracked in the Audit Roles table, sys_audit_role, and that the Identity and Access Audit feature can track changes to users, groups, roles, and ACLs. Those sources should be reviewed during incident response. (ServiceNow)

Investigators should not look only for a new account named “admin.” A careful attacker may:

• Add a powerful role to a legitimate low-profile account
• Modify a group that grants inherited privileges
• Create a service account with API access
• Change an ACL to expose a sensitive table
• Add a scheduled job or business rule
• Modify an integration user
• Grant privileges temporarily and remove them after use

Historical role and configuration auditing is therefore more useful than a current snapshot alone.

Workflow and automation abuse

ServiceNow workflows can perform trusted business actions. A compromise may allow an attacker to manipulate approvals, close alerts, suppress notifications, alter routing, create false tickets, or trigger downstream integrations.

The impact can be operational even without stealing data. For example, an attacker could modify a security workflow so that high-severity findings are automatically downgraded or assigned to an inactive queue. Another possibility is changing a change-management approval rule to authorize malicious infrastructure work.

These are scenario-based risks. Investigators need actual audit evidence before attributing a workflow change to CVE-2026-6875.

Integration credentials

ServiceNow environments often connect to identity systems, cloud platforms, monitoring products, endpoint tools, email services, vulnerability scanners, and internal applications. Platform compromise may expose tokens, passwords, certificates, integration user accounts, or API configuration.

Credential review should answer:

• Which secrets were stored directly in ServiceNow?
• Which credentials were retrievable by server-side scripts?
• Which external systems trusted the ServiceNow source identity?
• Which integrations used broad administrative permissions?
• Which tokens remained valid during the suspected compromise window?
• Can the organization prove that sensitive secrets were not accessed?

Where access cannot be ruled out, rotate the credential. Rotation should include downstream sessions, refresh tokens, certificates, webhook secrets, and service-account passwords rather than only the visible API key.

MID Server and internal network reach

A MID Server resides inside the customer network and mediates communication between the ServiceNow instance and internal resources. Depending on its configuration, it may perform discovery, orchestration, service mapping, credentialed access, SSH, WinRM, or other management tasks. (ServiceNow)

Searchlight Cyber reported command execution on configured proxy servers after escaping the sandbox. That makes the MID Server a priority evidence source. (Searchlight Cyber)

For each MID Server, determine:

• Hostname, IP address, and operating system
• Service account
• Installed capabilities
• Assigned credentials
• Allowed command set
• Privileged command configuration
• Sudo or administrative rights
• Reachable network segments
• Recent process execution
• Recent outbound connections
• Configuration changes
• Command audit history
• EDR status and telemetry retention

A ServiceNow patch does not retroactively remove persistence or malware from a MID Server that was already compromised.

AI and agent workflows

CVE-2026-6875 is a server-side sandbox escape, not a prompt-injection vulnerability. It should not be mislabeled as an LLM jailbreak.

The AI relevance comes from the platform context. ServiceNow AI Platform unifies AI, data, and workflow execution. A platform compromise may therefore affect AI Agent definitions, agent permissions, tool access, conversational workflows, or records used by AI-driven automation. (ServiceNow)

The defensive lesson is that AI security cannot be separated from application security, identity security, and platform hardening. A perfectly filtered prompt does not protect an agent whose execution platform has unauthenticated RCE.

What Is Known About In-the-Wild Exploitation

On July 20, multiple security outlets reported Defused’s observation of exploitation attempts. The reported payloads reached /assessment_thanks.do, matching the pre-authentication sink in Searchlight Cyber’s analysis. The sandbox-escape gadget, however, differed from the public proof of concept. (Help Net Security)

The Canadian Centre for Cyber Security updated its advisory on the same date and stated that open-source reporting indicated exploitation in the wild. (Canadian Centre for Cyber Security)

At the time of those reports:

• No authoritative public attribution to a named threat group had been established.
• ServiceNow said it had not found evidence connecting the reported activity to instances it hosted.
• Public reporting focused on the exploit request path and gadget variation, not a complete set of attacker infrastructure, malware hashes, persistence mechanisms, or victim identities.
• A malicious request did not automatically prove successful code execution.

Security teams should resist pressure to manufacture certainty. It is accurate to say there were credible reports of exploitation activity. It is not accurate to invent an APT name, ransomware family, victim count, success rate, or campaign scope.

The absence of public IP indicators is not a reason to stop hunting. Infrastructure indicators are often short-lived. Behavioral and application-level evidence can remain useful after IP addresses rotate.

Safe Exposure Review

A safe review answers whether the organization was exposed without attempting to exploit the production system.

Step 1 — Build the complete instance inventory

Start with contractual, administrative, DNS, certificate, proxy, SSO, CMDB, and cloud records. Do not assume the central platform team knows every instance.

Include:

• Production instances
• Development instances
• Test and quality-assurance instances
• Training instances
• Cloned production instances
• Disaster-recovery systems
• Partner-managed environments
• Acquisition or subsidiary environments
• Old custom domains
• Direct service-now.com instance names
• Reverse-proxy aliases
• Internet-facing portals
• Instances believed to be decommissioned

An abandoned clone can be more vulnerable than production because it may contain realistic data, retain old integrations, and miss normal patch cycles.

Create a record for each asset:

instance_id: sn-prod-us
owner: platform-security@example.invalid
hosting_model: ServiceNow-hosted
release_family: Zurich
patch_level: Patch 9
internet_entry_points:
  - sn.example.invalid
  - support.example.invalid
mid_servers:
  - mid-prod-01
data_classification: restricted
patch_evidence:
  change_ticket: CHG-DEMO-1042
  completed_at: 2026-07-15T04:15:00Z
log_sources:
  - servicenow_transaction
  - edge_waf
  - mid_edr

The values above are fictional. The purpose is to make the review reproducible and machine-readable.

Step 2 — Separate hosting models

Classify each instance as:

• ServiceNow-hosted
• Customer self-hosted
• Partner-hosted
• Unknown

This classification affects both patch responsibility and evidence collection.

For a ServiceNow-hosted instance, obtain confirmation of the applied mitigation or fixed build. For a self-hosted deployment, require internal deployment evidence. For a partner-hosted deployment, obtain a written attestation and supporting build information rather than relying on a generic statement that “ServiceNow patched the cloud.”

An unknown hosting model is a finding. Resolve it before closing the vulnerability.

Step 3 — Establish the exact build

Use authenticated administrative sources and Now Support. Record the family, patch, hot fix, and build date.

Avoid these weak checks:

• Searching HTML for “Zurich”
• Comparing a page copyright year
• Trusting a scanner’s CPE guess
• Treating a hidden version banner as proof of patching
• Sending the exploit and looking for an error
• Assuming a WAF changed the vulnerable application build

A scanner may identify a likely ServiceNow endpoint but still fail to determine the exact hot fix. Mark those results as “version unknown,” not “vulnerable” or “safe.”

Step 4 — Determine the exposure window

For each instance, identify:

• The earliest date it could have been vulnerable
• The date ServiceNow or the customer applied an interim mitigation
• The date the final applicable patch was installed
• Any rollback or restore event
• Any period when the instance was externally reachable
• The earliest retained edge and platform logs

For immediate hunting, prioritize:

• April 1 through the mitigation date
• July 13 through the patch date
• July 18 onward, when third-party monitoring reportedly began observing exploitation
• Any period following a rollback, clone refresh, or recovery exercise

The April date is not proof that attackers knew the vulnerability then. It is a conservative investigation boundary tied to vendor notification and the start of cloud mitigation work. (Searchlight Cyber)

Step 5 — Review network reachability

Document how unauthenticated traffic can reach the instance:

Internet
  -> CDN
  -> WAF
  -> reverse proxy
  -> ServiceNow instance

or:

Corporate VPN
  -> internal load balancer
  -> self-hosted ServiceNow nodes

Ask:

• Is the instance publicly reachable?
• Is access limited by IP allowlist?
• Can the direct instance hostname bypass the corporate proxy?
• Are alternate hostnames exposed?
• Are IPv6 and IPv4 controls equivalent?
• Does a mobile or partner portal use a different path?
• Do WAF logs contain full query strings?
• Does TLS terminate before the logging layer?
• Are URL-decoded parameters retained?
• Can the organization correlate edge requests with ServiceNow transaction logs?

A protected vanity domain does not help if the default instance hostname remains directly reachable.

Step 6 — Identify the public sink without triggering it

A normal request to an endpoint can establish that a route exists. It cannot prove the vulnerable evaluation path is present, and it cannot prove the instance is patched.

Do not send a javascript: expression or published sandbox-escape chain to production.

The safe questions are:

• Did historical traffic request /assessment_thanks.do?
• Did the query contain sysparm_assessable_type?
• Did the decoded value contain script-like syntax?
• Was the source expected?
• Did the request occur before the patch?
• What happened immediately afterward?

Testing the exploit is unnecessary when the platform build is known to be affected. Patch it.

Step 7 — Map connected systems

For each MID Server and integration, record:

Connection	Privilege	Network reach	Secret type	Logging	Rotation required
MID Server to Windows fleet	Local or domain-dependent	Server VLANs	Service account	EDR, WinRM, MID audit	Based on exposure
MID Server to Linux fleet	SSH and possible sudo	Application networks	SSH key or password	SSH, sudo, EDR	High priority if accessible
ServiceNow to identity provider	API-dependent	Identity tenant	OAuth client	IdP audit	Rotate if access cannot be excluded
ServiceNow to cloud platform	Role-dependent	Cloud APIs	Token or certificate	Cloud audit logs	Review permissions and rotate
ServiceNow to email service	Send or mailbox access	Email tenant	OAuth or SMTP secret	Email audit	Assess abuse and rotate
ServiceNow to security tools	Often broad	Security management plane	API token	Product audit	High-value review

Do not assume “read-only integration” from its name. Verify actual permissions.

Detection and Threat Hunting

Detection should combine edge HTTP evidence, ServiceNow transaction records, platform audits, identity changes, MID Server activity, and downstream telemetry.

Transaction logs

ServiceNow documents that Transaction Logs record browser activity for an instance and include request and response information such as creation time, user context, URL-related details, and HTTP response code. Administrators can access them through System Logs and Transactions. (ServiceNow)

The syslog_transaction table is therefore a primary source for reviewing requests to the vulnerable sink. ServiceNow’s Log Export Service can also export syslog_transaction and other log sources for external analysis. (ServiceNow)

Search for:

• /assessment_thanks.do
• sysparm_assessable_type
• javascript:
• URL-encoded representations of the colon and other script characters
• Unusually long parameter values
• JavaScript object or prototype keywords
• Repeated requests with small payload variations
• Requests from previously unseen autonomous-system numbers
• Unusual User-Agent strings
• Bursts across multiple instance hostnames

These are indicators of suspicious input, not proof of exploitation.

Normalize before matching

Attackers can encode a request in several ways:

• Percent encoding
• Double encoding
• Mixed character case
• Alternate separators
• Proxy-specific normalization differences
• Repeated parameters
• Fragmented logging fields

Detection should inspect both the raw request and a safely decoded representation. Preserve the original evidence before normalization.

Safe offline log parser

The following Python script reads a local text file and looks for suspicious request lines. It does not make network connections and does not send any request to ServiceNow.

#!/usr/bin/env python3
"""
Offline CVE-2026-6875 request triage.

This script:
- reads an existing local log file;
- URL-decodes each line up to two times;
- looks for the publicly documented endpoint and parameter;
- highlights script-like values;
- never contacts a target.

Expected input: one HTTP request or proxy log event per line.
"""

from __future__ import annotations

import argparse
import re
from pathlib import Path
from urllib.parse import unquote_plus


ENDPOINT = "/assessment_thanks.do"
PARAMETER = "sysparm_assessable_type"

SCRIPT_MARKERS = (
    "javascript:",
    "gs.include",
    "object.defineproperty",
    ".constructor",
    "abstractajaxprocessor",
    "glidecontroller",
    "function(",
    "prototype",
)


def decode_repeatedly(value: str, rounds: int = 2) -> str:
    result = value

    for _ in range(rounds):
        decoded = unquote_plus(result)

        if decoded == result:
            break

        result = decoded

    return result


def classify(line: str) -> list[str]:
    decoded = decode_repeatedly(line)
    lowered = decoded.lower()
    reasons: list[str] = []

    if ENDPOINT in lowered:
        reasons.append("target_endpoint")

    if PARAMETER in lowered:
        reasons.append("target_parameter")

    for marker in SCRIPT_MARKERS:
        if marker in lowered:
            reasons.append(f"script_marker:{marker}")

    if ENDPOINT in lowered and PARAMETER in lowered:
        parameter_match = re.search(
            rf"{re.escape(PARAMETER)}=([^&\s]+)",
            decoded,
            flags=re.IGNORECASE,
        )

        if parameter_match and len(parameter_match.group(1)) > 150:
            reasons.append("long_parameter_value")

    return reasons


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("logfile", type=Path)
    args = parser.parse_args()

    if not args.logfile.is_file():
        raise SystemExit(f"Log file not found: {args.logfile}")

    with args.logfile.open("r", encoding="utf-8", errors="replace") as handle:
        for line_number, line in enumerate(handle, start=1):
            reasons = classify(line)

            if reasons:
                print(
                    f"{args.logfile}:{line_number}:"
                    f"{','.join(reasons)}:{line.rstrip()}"
                )

    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Run it only against logs you are authorized to inspect:

python3 detect_servicenow_6875.py edge-access.log \
  > cve-2026-6875-candidates.txt

A matching line should be investigated, not automatically labeled compromised.

Generic SIEM logic

Field names vary across products. The following is platform-neutral pseudocode:

FROM http_events
WHERE lower(url_path) = "/assessment_thanks.do"
  AND decoded_query CONTAINS "sysparm_assessable_type"
  AND (
       decoded_query CONTAINS "javascript:"
       OR decoded_query CONTAINS "gs.include"
       OR decoded_query CONTAINS "defineproperty"
       OR decoded_query CONTAINS ".constructor"
       OR decoded_query CONTAINS "prototype"
  )
GROUP BY source_ip, host, user_agent, five_minute_window
RETURN first_seen, last_seen, request_count, raw_requests

A second analytic should look for the endpoint even when the known markers are absent:

FROM http_events
WHERE lower(url_path) = "/assessment_thanks.do"
  AND decoded_query CONTAINS "sysparm_assessable_type"
  AND (
       parameter_length > expected_baseline
       OR source_ip is rare
       OR request_rate is anomalous
       OR response_size differs from baseline
  )

This broader rule matters because observed exploitation reportedly used a different gadget chain.

Temporary reverse-proxy detection

A reverse proxy can tag suspicious requests for logging. The following NGINX example is intentionally a detection control. Blocking can create application compatibility problems and should be tested.

map $request_uri $sn_6875_candidate {
    default 0;

    ~*^/assessment_thanks\.do\?.*sysparm_assessable_type= 1;
}

log_format security_json escape=json
  '{"time":"$time_iso8601",'
  '"remote_addr":"$remote_addr",'
  '"host":"$host",'
  '"request":"$request",'
  '"status":$status,'
  '"candidate":"$sn_6875_candidate",'
  '"user_agent":"$http_user_agent"}';

access_log /var/log/nginx/servicenow-security.json security_json;

This rule will generate benign matches if the endpoint is used legitimately. Add decoded-query inspection at the WAF or SIEM layer rather than trying to place an entire exploit signature inside NGINX configuration.

If the organization chooses temporary blocking before patching, it should consider:

• Direct-hostname bypass
• Alternate proxies
• Encoded paths
• Query normalization
• Legitimate assessment workflows
• IPv6 exposure
• API and mobile traffic
• Fail-open behavior
• Change-control and rollback

The patch remains the durable fix.

Platform audit sources

ServiceNow tracks inserts and updates to audited records in sys_audit and relationship changes in sys_audit_relation. Some automated changes may appear as the system or guest user, making context and timing important. (ServiceNow)

Review high-risk changes involving:

• sys_user
• sys_user_role
• sys_user_has_role
• Groups and group membership
• ACL records
• Business rules
• Script Includes
• Scheduled jobs
• System properties
• Integration records
• Credential records
• OAuth applications
• MID Server records
• AI Agent definitions
• Virtual Agent configuration

ServiceNow also documents optional Identity and Access Audit capabilities for changes to users, groups, roles, and ACLs. Confirm that the relevant plugin and property were enabled before relying on historical data. (ServiceNow)

Role changes

The Audit Roles table records role additions and removals, affected users, and who made the change. Review role activity from the earliest plausible exposure date through the completion of the investigation. (ServiceNow)

Prioritize:

• admin
• security_admin
• Integration administration roles
• MID Server administration
• Script or application development roles
• Roles that grant table access
• Custom privileged roles
• Group changes that indirectly grant those roles

A role removed shortly after it was added remains significant.

MID Server evidence

ServiceNow documents a MID Server command audit log for commands run by the Discovery application. Collect that log, but do not assume it records every possible execution path or every custom integration. (ServiceNow)

Also collect host-level evidence:

• EDR process trees
• Windows Event Logs or Linux audit logs
• Shell history where reliable
• Sudo logs
• SSH server logs
• Service creation
• Scheduled tasks and cron jobs
• New files in temporary directories
• Network connections
• DNS lookups
• New user accounts
• Changes to the MID Server installation directory
• Changes to config.xml
• Changes to certificates or keystores

Searchlight Cyber’s report that proxy-server commands were possible raises the priority of unusual child processes spawned by MID Server or Java service contexts. (Searchlight Cyber)

Downstream systems

Review the audit logs of systems connected to ServiceNow. Look for activity attributed to ServiceNow integration identities that is inconsistent with normal workflow patterns.

Examples include:

• Identity-provider changes
• Cloud IAM modifications
• New API tokens
• Endpoint isolation actions
• Security-alert closures
• Source-control changes
• Monitoring suppression
• Email forwarding or outbound-message anomalies
• Password-reset activity
• Infrastructure orchestration
• Secrets-vault retrieval

The attacker may use an existing trusted integration rather than deploy malware.

Detection Signals and Interpretation

Signal	What it can establish	Common false-positive cause	Required follow-up
Request to /assessment_thanks.do	The endpoint was accessed	Legitimate assessment workflow	Inspect parameter, source, timing, and baseline
sysparm_assessable_type in query	The documented sink parameter was supplied	Normal application traffic	Decode and inspect the value
javascript: in decoded parameter	Script evaluation was likely attempted	Legitimate administrative query in an unexpected path	Confirm endpoint, user context, and application behavior
Prototype or constructor terms	Possible sandbox-gadget activity	Security testing or unusual legitimate script	Correlate with patch state and platform logs
HTTP 200 response	Server returned a successful HTTP status	Error or benign page can still return 200	Do not infer execution from status
HTTP 500 response	Request may have caused a server error	Ordinary application fault	Review transaction and system logs
New privileged role	Potential persistence or escalation	Approved administration	Validate change ticket and actor
New Script Include or business rule	Potential persistence	Legitimate development	Review code, creator, and deployment source
MID Server child process	Possible command execution	Normal discovery or orchestration	Compare command, parent process, destination, and schedule
Integration token use from new source	Potential credential abuse	Infrastructure change	Validate source, scope, and related ServiceNow activity
WAF block	An input matched a rule	Benign request or scanner	Preserve raw request and check for bypass attempts

Safe Local PoC — Modeling a Cross-Context Capability Leak

The following demonstration is not a ServiceNow exploit. It does not contain the real gadget chain, send HTTP requests, execute operating-system commands, access files, read environment variables, or connect to a network.

It models the design mistake behind many sandbox escapes: a low-trust expression evaluator imports a privileged library into the same callable scope.

The only “secret” is a hard-coded string named DEMO_ONLY_SECRET.

#!/usr/bin/env python3
"""
Safe toy model for a cross-context capability leak.

This is not ServiceNow code and cannot exploit CVE-2026-6875.
It demonstrates why merging privileged helpers into an untrusted
expression scope can break a sandbox boundary.
"""

from __future__ import annotations

import ast
from collections.abc import Callable
from types import MappingProxyType
from typing import Any


def add(left: int, right: int) -> int:
    return left + right


def format_value(value: Any) -> str:
    return f"value={value}"


def read_demo_secret() -> str:
    # Fictional, hard-coded data only.
    return "DEMO_ONLY_SECRET"


SAFE_FUNCTIONS: dict[str, Callable[..., Any]] = {
    "add": add,
    "format_value": format_value,
}

PRIVILEGED_INCLUDE: dict[str, Callable[..., Any]] = {
    "read_demo_secret": read_demo_secret,
}


class ExpressionError(ValueError):
    pass


def evaluate_node(
    node: ast.AST,
    functions: dict[str, Callable[..., Any]],
) -> Any:
    if isinstance(node, ast.Expression):
        return evaluate_node(node.body, functions)

    if isinstance(node, ast.Constant):
        if isinstance(node.value, (str, int)):
            return node.value

        raise ExpressionError("Unsupported constant")

    if isinstance(node, ast.Call):
        if not isinstance(node.func, ast.Name):
            raise ExpressionError("Only named functions are allowed")

        function_name = node.func.id

        if function_name not in functions:
            raise ExpressionError(
                f"Function is not allowed: {function_name}"
            )

        arguments = [
            evaluate_node(argument, functions)
            for argument in node.args
        ]

        return functions[function_name](*arguments)

    raise ExpressionError(
        f"Unsupported syntax: {type(node).__name__}"
    )


def run_expression(
    expression: str,
    functions: dict[str, Callable[..., Any]],
) -> Any:
    tree = ast.parse(expression, mode="eval")
    return evaluate_node(tree, functions)


def vulnerable_sandbox(
    expression: str,
    include_privileged_library: bool,
) -> Any:
    scope = dict(SAFE_FUNCTIONS)

    if include_privileged_library:
        # Security bug:
        # privileged capabilities are merged into low-trust scope.
        scope.update(PRIVILEGED_INCLUDE)

    return run_expression(expression, scope)


def fixed_sandbox(expression: str) -> Any:
    # The allowed scope is immutable and contains no privileged helper.
    immutable_scope = MappingProxyType(dict(SAFE_FUNCTIONS))
    return run_expression(expression, dict(immutable_scope))


def main() -> None:
    print(vulnerable_sandbox("add(20, 22)", False))

    print(
        vulnerable_sandbox(
            "read_demo_secret()",
            include_privileged_library=True,
        )
    )

    try:
        print(fixed_sandbox("read_demo_secret()"))
    except ExpressionError as error:
        print(f"Blocked by fixed sandbox: {error}")


if __name__ == "__main__":
    main()

Expected output:

42
DEMO_ONLY_SECRET
Blocked by fixed sandbox: Function is not allowed: read_demo_secret

What the toy example demonstrates

The expression parser itself is restrictive. It permits only constants and calls to explicitly named functions. It cannot import modules, access attributes, open files, or execute shell commands.

The vulnerable design defeats that restriction by adding a privileged function to the low-trust function map. Once the capability is present, the parser correctly executes it because the function is now “allowed.”

The fixed version preserves the boundary:

• The low-trust function map is explicit.
• Privileged functions are not merged into it.
• The allowed map is treated as immutable.
• The evaluator does not consult mutable global state.
• Privileged code must be called through a separately authorized interface.

CVE-2026-6875 involved a much more complex JavaScript and Script Include chain, but the architectural lesson is similar: a sandbox can block direct access and still fail when privileged code consumes attacker-controlled state.

Remediation Priorities

1. Apply the official patch or upgrade

Use ServiceNow’s advisory and support channels to select the correct fixed build. Publicly listed fixed lines include Australia Patch 2, the applicable Yokohama Patch 12 Hot Fix 1b or Patch 13 path, the applicable Zurich Patch 7b or Patch 9 path, and Brazil EA or GA. (NVD)

Do not delay because the public exploit appears complex. Reported in-the-wild payloads already differ from the first published gadget chain.

2. Confirm every instance

Create a per-instance remediation record. “The ServiceNow team patched it” is not sufficient evidence for a multi-instance organization.

Record:

• Instance name
• Owner
• Hosting model
• Pre-patch build
• Fixed build
• Patch completion time
• Change ticket
• Validation owner
• Log-review status
• MID Server-review status
• Credential-rotation decision

3. Preserve logs before they rotate

Export relevant data before normal retention removes it:

• WAF and proxy requests
• ServiceNow transaction logs
• System logs
• Audit tables
• Role audit
• Identity and Access Audit
• MID Server command logs
• EDR telemetry
• Firewall and DNS logs
• Downstream SaaS audit logs

ServiceNow documents log rotation and export facilities, but actual retention depends on instance configuration and external logging. (ServiceNow)

4. Restrict external access while patching

Where operationally possible:

• Require VPN or trusted access
• Apply IP allowlists
• Restrict direct instance hostnames
• Add edge detection for the vulnerable path
• Rate-limit abnormal unauthenticated traffic
• Ensure all aliases pass through the same control
• Verify IPv6 and partner access paths

These controls reduce exposure but do not fix the sandbox escape.

5. Review Guarded Script

ServiceNow introduced or expanded Guarded Script as part of the platform-hardening response. Searchlight Cyber reports that Guarded Script limits low-trust scripts to a single simple expression and excludes variable declarations, control flow, function declarations, assignment operators, and multiple statements. (Searchlight Cyber)

ServiceNow’s current documentation describes Guarded Script as a restricted evaluator with a limited set of supported ServiceNow and JavaScript APIs. It also provides an Incompatible Guarded Scripts list to help administrators find scripts that require rewriting or exemptions. (ServiceNow)

Review:

• Whether Guarded Script is enabled at the expected enforcement phase
• Incompatible script records
• Automatically created exemptions
• Manually approved exemptions
• Business justification for each exemption
• Whether complex logic can be moved into a reviewed Script Include
• Whether the called Script Include exposes only narrow capabilities
• Whether custom scripts rely on mutable global state

An exemption is a security decision, not merely a compatibility workaround.

6. Harden MID Servers

ServiceNow recommends placing MID Servers on secured systems behind corporate firewalls. (ServiceNow)

Apply these controls:

• Run the service with the least privilege possible.
• Separate MID Servers by environment and trust zone.
• Restrict reachable subnets.
• Restrict outbound destinations.
• Use dedicated credentials.
• Limit privileged commands.
• Prefer command-level sudo rules over broad script execution.
• Enable EDR.
• Centralize process, command, and network logs.
• Review config.xml access.
• Protect certificates and keystores.
• Remove unused capabilities.
• Decommission unused MID Servers.

ServiceNow notes that command-level sudo can produce more informative audit records than executing an entire wrapper script. That improves both prevention and investigation. (ServiceNow)

7. Rotate credentials based on evidence and uncertainty

Rotate credentials immediately when:

• Logs show access to credential records.
• A suspicious request correlates with abnormal platform behavior.
• A MID Server executed unexplained commands.
• An integration identity was used outside its normal pattern.
• Audit coverage is insufficient to exclude access.
• The affected instance stored high-value reusable secrets.

Prioritize:

• Administrative service accounts
• OAuth client secrets
• Refresh tokens
• SSH keys
• MID Server credentials
• Cloud API credentials
• Security-product API tokens
• Identity-provider integrations
• Webhook signing secrets
• Database credentials

A rotation plan should prevent the old secret from remaining valid through cached sessions or secondary credentials.

8. Investigate before declaring remediation complete

Patching stops the known vulnerable behavior. It does not answer whether exploitation occurred before the patch.

Closure criteria should include:

• Fixed build confirmed
• External exposure reviewed
• Suspicious HTTP candidates triaged
• Role and identity changes reviewed
• High-risk script changes reviewed
• MID Server evidence reviewed
• Downstream integrations reviewed
• Credentials rotated where appropriate
• Persistence mechanisms excluded or removed
• Post-patch validation completed
• Evidence retained with the incident record

Common Mistakes

Treating ServiceNow-hosted and self-hosted instances as the same

The vendor reported rapid action for cloud instances, while self-hosted and partner environments required supplied updates. Confirm the status of each deployment rather than applying one statement to all instances. (NVD)

Using AC:H as a reason to postpone

High complexity describes exploit conditions. It does not remove network reachability, unauthenticated access, or high impact.

Blocking only the published gadget

Observed exploitation reportedly used another gadget route. Patch the root cause.

Looking only for javascript: in raw logs

Encoding and normalization can hide the literal string. Decode safely while retaining the raw request.

Assuming a 200 response proves success

Many applications return 200 for error pages, redirects rendered in HTML, or harmless content. Correlate with platform and host behavior.

Assuming a blocked request proves safety

The attacker may have used another hostname, path representation, proxy, IPv6 address, or payload.

Ignoring dormant instances

Clones and test systems may contain production data and old credentials but receive less monitoring.

Ignoring MID Servers

The public research specifically identified connected proxy-server command execution as a potential impact. (Searchlight Cyber)

Running a public exploit against production

A successful test could modify platform state, access sensitive data, trigger integrations, or reach internal systems. Version and patch evidence are safer and usually more authoritative.

Closing the case immediately after patching

Patching and incident investigation answer different questions. Complete both.

Related ServiceNow Vulnerabilities

CVE-2026-6875 is not the first critical ServiceNow issue involving unauthenticated access, script execution, or AI-enabled workflows. Related CVEs help defenders understand recurring trust boundaries, but they should not be merged into one generic scanner rule.

CVE-2026-0542

CVE-2026-0542 is another ServiceNow AI Platform remote code execution issue. The official description says an unauthenticated user could, in certain circumstances, execute code within the ServiceNow Sandbox. ServiceNow supplied updates for hosted, self-hosted, and partner environments. Affected version boundaries included releases before Australia, selected Zurich and Yokohama patches, and Xanadu Patch 11 Hot Fix 1a. (NVD)

Its relevance is architectural:

• Both issues involve unauthenticated server-side scripting paths.
• Both concern the ServiceNow sandbox boundary.
• Both demonstrate that restricted code execution can still carry high risk.
• Both require exact release and hot-fix verification.

The public descriptions differ. CVE-2026-0542 refers to code execution within the sandbox, while CVE-2026-6875 involves escaping a stricter sandbox and reaching broader platform execution. Do not assume the same detection string or fixed release covers both.

CVE-2025-12420 — BodySnatcher

AppOmni disclosed CVE-2025-12420, named BodySnatcher, in January 2026. The issue involved the Virtual Agent API and Now Assist AI Agents. AppOmni reported that an unauthenticated attacker could exploit account-linking behavior to impersonate a ServiceNow user using an email address and then perform operations available to that identity. (AppOmni)

The affected application versions and earliest known fixes published by AppOmni included:

Application	Affected versions	Earliest listed fixes
Now Assist AI Agents	5.0.24 through 5.1.17 and 5.2.0 through 5.2.18	5.1.18 and 5.2.19
Virtual Agent API	Up to 3.15.1 and 4.0.0 through 4.0.3	3.15.2 and 4.0.4

BodySnatcher is not a sandbox escape. Its relevance is the way AI and conversational interfaces can become alternative execution paths into privileged enterprise workflows.

Together, the two vulnerabilities show different failure modes:

• CVE-2025-12420 crossed an identity and account-linking boundary.
• CVE-2026-6875 crossed a script-evaluation and sandbox boundary.

Defending only the model prompt layer would not stop either root cause.

CVE-2024-4879, CVE-2024-5178, and CVE-2024-5217

In 2024, Assetnote disclosed a three-vulnerability ServiceNow chain affecting Vancouver and Washington releases. The chain involved unauthenticated code execution and access to sensitive platform data. ServiceNow provided hosted-instance updates and patches or hot fixes for customers and partners. (Assetnote)

The earlier chain is relevant because it shows that ServiceNow exploitation can involve multiple platform primitives rather than one isolated endpoint. Security teams should maintain a program-level view of:

• Unauthenticated pages
• Query and template evaluation
• Script execution
• File access
• Table access
• MID Server reach
• Identity and role changes
• Custom application code

A scanner that tests only one CVE path can miss a different route to the same privileged capability.

Building a Safe Validation Workflow

A defensible CVE-2026-6875 validation process should produce evidence without introducing new production risk.

Phase 1 — Authorization and scope

Define:

• Exact instance hostnames
• Hosting model
• Environment classification
• Allowed data sources
• Allowed active requests
• Prohibited exploit behavior
• Approved maintenance windows
• Incident escalation contacts
• Evidence-retention requirements

For this vulnerability, the default production rule should prohibit active sandbox-escape payloads.

Phase 2 — Asset and version evidence

Collect:

• Instance build information
• ServiceNow support records
• Patch deployment records
• Node inventory
• Recovery-image status
• Clone inventory

Classify each instance:

confirmed_fixed
confirmed_affected
version_unknown
decommissioned_and_unreachable
requires_vendor_confirmation

Do not label version_unknown as safe.

Phase 3 — Exposure review

Determine whether the vulnerable instance was reachable from:

• The public internet
• Partner networks
• VPN users
• Internal untrusted segments
• Shared corporate networks
• Cloud workloads
• Third-party integration infrastructure

Record whether the direct ServiceNow hostname bypassed the corporate edge.

Phase 4 — Historical request analysis

Analyze edge and platform logs for the endpoint, parameter, encoded script markers, abnormal request length, and request bursts.

Preserve:

• Raw request
• Normalized request
• Timestamp
• Source
• Destination hostname
• Response status
• Response size
• User-Agent
• WAF action
• Correlation identifier

Phase 5 — Impact hunting

Review:

• Users
• Roles
• ACLs
• Script Includes
• Business rules
• Scheduled jobs
• System properties
• Integrations
• Credentials
• AI Agent definitions
• MID Server activity
• Downstream-system audit logs

Phase 6 — Remediation

Apply the fixed build, remove temporary exemptions where possible, harden MID Servers, rotate credentials, and restrict unnecessary exposure.

Phase 7 — Post-patch validation

A safe post-patch validation can confirm:

• The documented fixed build is running.
• All nodes report the expected version.
• Guarded Script is operating as intended.
• No unexplained compatibility exemption remains.
• The edge detects known suspicious request structures.
• Logs flow to the SIEM.
• MID Server controls remain functional.
• Business workflows continue to operate.

It does not need to reproduce unauthenticated RCE.

AI-assisted validation can help correlate assets, release families, maintenance evidence, HTTP logs, and remediation records, but the agent must be constrained by an explicit authorization boundary. A workflow should not infer that “CVE validation” authorizes it to submit public RCE payloads. The safer model described in Penligent’s authorized AI pentesting workflow is to encode scope as a machine-readable control, preserve evidence, and require approval before high-impact actions.

In an authorized environment, an agentic security platform such as Penligent can help organize asset discovery, version checks, log analysis, evidence capture, and remediation retesting. For CVE-2026-6875, the useful automation is evidence correlation and safe exposure review—not autonomous exploitation of a production ServiceNow control plane.

Incident-Response Decision Matrix

Patch state	Suspicious request	Impact evidence	Recommended response
Confirmed fixed before request	No	No	Record evidence and continue routine monitoring
Confirmed fixed before request	Yes	No	Treat as blocked or failed attempt; validate edge and platform logs
Patched after request	Yes	No	Investigate the vulnerable window and connected systems
Patched after request	Yes	Yes	Escalate as confirmed or probable compromise
Version unknown	No	No	Resolve version immediately; do not assume safety
Version unknown	Yes	No	Treat as high-priority suspected exposure
Confirmed affected	No retained logs	Unknown	Patch, preserve remaining evidence, review roles, scripts, credentials, and MID Servers
Confirmed affected	Yes	MID Server anomaly	Initiate full incident response and isolate affected connectors
Confirmed affected	Yes	Privileged account change	Treat as likely successful exploitation until disproved

FAQ

Is CVE-2026-6875 remotely exploitable without authentication?

• Yes. ServiceNow’s CVE record states that an unauthenticated user could, in certain circumstances, execute code within the ServiceNow platform.
• The attack is network accessible and requires no user interaction.
• The CVSS vector rates attack complexity as high, meaning successful exploitation requires a nontrivial technical chain.
• High complexity does not require the attacker to possess credentials. (NVD)

Are ServiceNow-hosted instances still at risk?

• ServiceNow says it deployed security action to hosted instances and provided patches to self-hosted customers and partners.
• Searchlight Cyber says strong cloud mitigations were deployed within approximately 24 hours of its April 1 report.
• After third-party exploitation reports appeared, ServiceNow said it had not observed evidence that the reported activity involved instances hosted by ServiceNow.
• Customers should still confirm the build and patch state of every hosted, cloned, partner-operated, and connected environment. (Searchlight Cyber)

How can I verify whether my instance is patched?

• Obtain the exact ServiceNow family, patch, hot fix, and build information from authenticated administrative sources.
• Compare it with the applicable fixed release in the ServiceNow advisory.
• Confirm the result through Now Support when the instance is on an unusual or parallel maintenance branch.
• Preserve the change record, deployment evidence, and post-upgrade validation.
• Do not rely only on HTTP banners, page footers, scanner fingerprints, or a WAF rule.

Can a WAF block CVE-2026-6875?

• A WAF can detect or temporarily block requests to the publicly documented endpoint and parameter.
• It can inspect decoded query values for script-like content and abnormal request patterns.
• It may miss alternate encodings, direct-hostname access, different gadget strings, or another path to the vulnerable primitive.
• Reported in-the-wild payloads already used a different gadget route from the public proof of concept.
• A WAF is a temporary risk-reduction layer, not a substitute for the ServiceNow patch. (BleepingComputer)

Does a request to assessment_thanks.do prove compromise?

• No. The endpoint can have legitimate uses.
• A suspicious parameter can prove that exploitation was attempted, but not that the sandbox escape succeeded.
• An HTTP 200 or 500 status is not conclusive.
• Correlate the request with ServiceNow transaction logs, system errors, audit changes, role changes, integration activity, and MID Server telemetry.
• Treat platform or connected-system changes as stronger evidence than an edge signature alone.

What should I investigate on connected MID Servers?

• Review command audit records, EDR process trees, service activity, shell and sudo logs, network connections, DNS activity, new files, scheduled tasks, and account changes.
• Identify every credential available to the MID Server and every network segment it can reach.
• Compare observed commands with expected Discovery or orchestration schedules.
• Investigate unexplained child processes created by the MID Server’s Java or service context.
• Rotate high-value credentials if access cannot be excluded.
• Patching ServiceNow does not remove persistence from a previously compromised MID Server.

Is it safe to run the public PoC against production?

• No. A successful sandbox escape can affect sensitive platform data, identities, scripts, workflows, integrations, and connected infrastructure.
• Version and patch evidence should be the primary method for determining vulnerability.
• Use historical log analysis for exposure review.
• Perform active validation only in an isolated, authorized lab that contains no production data, credentials, or network connectivity.
• Do not use a production clone unless its secrets, integrations, email, MID Servers, and outbound actions have been safely disabled.

Final Assessment

CVE-2026-6875 should be treated as a platform-compromise risk, not merely a suspicious request parameter.

The flaw combined an unauthenticated query sink, JavaScript evaluation, a restricted sandbox, Script Include loading, and mutable cross-context behavior. The resulting escape could provide broad ServiceNow scripting capabilities and, according to the researchers, reach connected proxy infrastructure. (Searchlight Cyber)

The most important actions are straightforward:

• Confirm the exact fixed build for every instance.
• Patch self-hosted and partner-operated environments immediately.
• Preserve edge, platform, identity, and MID Server logs.
• Hunt beyond the first published gadget.
• Review roles, scripts, credentials, workflows, and integrations.
• Treat MID Servers as part of the potential blast radius.
• Validate remediation without sending an RCE payload to production.

A ServiceNow instance can sit at the intersection of enterprise identities, operational data, automation, AI Agents, and internal infrastructure. That makes patch evidence, exposure review, and post-compromise hunting more important than a scanner’s binary vulnerable-or-safe label.