ServiceNow AI Platform

TL;DR

In-the-wild exploitation of “CVE-2026-6875,” an unauthenticated sandbox-escape RCE in ServiceNow AI Platform (formerly Now Platform), was observed in July 2026. The vulnerability, reported by Searchlight Cyber on April 1, lets an unauthenticated attacker escape the sandbox with a single request that reaches a publicly reachable endpoint (/assessment_thanks.do) and reach arbitrary code execution; the exploitation reached the same code execution by a path different from the public PoC. ServiceNow addressed hosted instances progressively from April and released the self-hosted update on July 13, and states it has not observed exploitation against its own hosted instances. What is at issue is that execution is decided by “could it reach the endpoint” rather than by an independent verification of per-action authorization — and in particular that a single point of reach escalates to admin creation, MID Server reach, and full instance takeover. Detection and pre-action proof are complementary, not substitutes.

Incident Summary

Subject: ServiceNow AI Platform (formerly Now Platform), a PaaS that integrates AI into enterprise core workflows. By ServiceNow’s account it processes over 100 billion workflows a year and is said to be adopted by 85% of the Fortune 500.
Vulnerability: CVE-2026-6875. An unauthenticated (pre-auth) sandbox-escape RCE. Some reporting puts the severity in the CVSS 9 range (Critical; reported value 9.5).
Discovery and report: discovered by Searchlight Cyber and reported on 2026-04-01 (“Smashing the ServiceNow Sandbox: Pre-Authentication RCE”).
Fix: ServiceNow addressed hosted instances progressively from April. It released the update for self-hosted instances on 2026-07-13.
Exploitation: Defused confirmed in-the-wild exploitation over the weekend (the first attempt on Friday). The exploitation hits the unauthenticated entry point Searchlight documented, /assessment_thanks.do, but the sandbox-escape gadget reaches the same code-execution primitive by a path different from the public PoC.
Impact: an unauthenticated attacker can escape the sandbox and reach full instance takeover, access to data in tables, admin account creation, and command execution on connected MID Server proxies (a high-difficulty attack).
Vendor position: in its official advisory ServiceNow states it “has not observed evidence of exploitation against ServiceNow-hosted instances,” and strongly recommends that both self-hosted and hosted customers apply the patch.

Timeline

2026-04-01: Searchlight Cyber reports CVE-2026-6875 to ServiceNow.
2026-04 onward: ServiceNow addresses hosted instances progressively.
2026-07-13: ServiceNow releases the update (KB article) for self-hosted instances.
around 2026-07-17 (Friday): the first attempt at in-the-wild exploitation is observed.
2026-07-18 to 19 (weekend): Defused confirms and discloses in-the-wild exploitation. The exploitation hits /assessment_thanks.do and reaches the same code execution by a path different from the public PoC.
2026-07-20: reporting (BleepingComputer and others). ServiceNow states it has not observed evidence of exploitation against its own hosted instances and recommends applying the patch.

Note: the technical facts are based on Searchlight Cyber’s research, Defused’s in-the-wild exploitation report, NVD (CVE-2026-6875), and established media (BleepingComputer, Help Net Security, SecurityWeek, and others). The severity score, the scope of exploitation, and whether harm occurred vary by source and point in time, and ServiceNow states it has not observed evidence of exploitation against its own hosted instances. Consult the latest primary sources (the vendor advisory and NVD).

Attack Vector

Reaching the unauthenticated endpoint: without authenticating, the attacker sends a crafted HTTP request to a sink reachable while unauthenticated (/assessment_thanks.do).
Escaping the sandbox: using a sandbox-escape gadget, the attacker breaks out of the platform’s isolation. The path used in the exploitation is a different route from Searchlight’s public PoC, but it reaches the same code-execution primitive.
Code execution: the attacker runs arbitrary code within the ServiceNow platform. Because no authentication is required, reachability translates directly into executability.
Escalation of privilege: it can reach full instance takeover, access to data in tables, admin account creation, and command execution on connected MID Server proxies.

Structural Analysis

This incident belongs to the identity-auth category of Pillar 03 (Agent Authority Proof). The central failure primitive is that the platform allowed code execution based on “could it reach a specific endpoint without authentication,” not on an independent verification of “is this action authorized for this actor and this scope.” As a secondary category we add agent-infrastructure, in that it is an enterprise foundation that runs AI workflows at scale. When a single request reaching a sink that requires no authentication escapes the sandbox and reaches execution, reachability and execution privilege are effectively fused.

What is specific to this incident is that the sandbox — the very layer meant to contain execution — was itself escaped, and moreover the same execution was reached by a path different from the public PoC. This shows that as long as defense depends on a specific path or on surface signals (the endpoint reached, the presence or absence of authentication, the sandbox boundary), a different path, once found, reaches the same execution. What is required is an independently verifiable authorization bound not to the path but to the action itself.

With the same vendor as Brief No.046 (ServiceNow unauthenticated API, where a single setting removed authentication and customer instances were queried while unauthenticated), it repeats the structure in which “unauthenticated reach becomes a privileged operation directly” (it is independent as an incident — a different CVE, a different endpoint, a sandbox escape). It is of the same type as Brief No.088 (Kestra, where authentication fell off at the end of a path and code ran as root while unauthenticated) and Brief No.003 (Starlette / BadHost, where Host-header manipulation bypassed authentication), in the structure where a surface judgment of authentication/authorization connects directly to execution privilege. It connects with Brief No.094 (Cursor / DuneSlide, where a single planted instruction escaped the sandbox to arbitrary code execution) on the sandbox-escape surface, and with Brief No.033 (F5 BIG-IP, where the compromise of a single device chained to the whole domain) on the surface where a single point of reach escalates to full takeover. The shared primitive is the same: reachability and surface signals are independent of per-action authorization.

The Detection–Proof Gap

Searchlight Cyber’s discovery and report, ServiceNow’s provision of a patch, Defused’s detection and warning of in-the-wild exploitation, and the visibility through reporting are indispensable to suppressing harm, and this Brief does not deny that role. The sequence from vulnerability discovery to patch to observation of in-the-wild exploitation is the starting point for defenders to respond. Detection does play its part.

At the same time, patching and detection of in-the-wild exploitation do not provide material to independently establish — at the moment execution begins, bound to the action itself — whether the request now arriving is a legitimate action authorized to execute or an exploitation trying to escape the sandbox while unauthenticated. The fact that the exploitation reached the same execution by a path different from the public PoC shows that as long as defense depends on a specific path or signal, a different path can slip through to the same result. A patch closes a known path, but the very structure in which whether execution is allowed is decided by “could it reach” remains unless per-action authorization is independently verified. As material for an audit to establish “was the code execution on this platform a legitimate action by an authorized actor?”, the mere surface premise that “it did not go through an authentication endpoint / it should be inside the sandbox” is not an independent trail of the action’s authorization. This is a gap in a structurally independent layer, outside the reach of the detection layer.

Pre-action attestation requires, before execution begins, a proof — independently verifiable and decoupled from the endpoint reached or the sandbox boundary — that the action is authorized (proof-as-auth). If no proof accompanies it, unauthorized execution is denied by default (deny-by-default). This does not erase the sandbox-escape bug itself; it is a design principle that does not let unauthorized execution be established. That said, this incident is an unauthenticated (anonymous) pre-auth exploitation, and there is no actor to bind to the initial point of reach itself. Therefore where proof-as-auth is strongest in this case is not the initial reach but the subsequent escalation of privilege — not letting admin creation, MID Server reach, table data, and full instance takeover translate into “a single point of reach equals full authority.” A patch closing a known path and detection of in-the-wild exploitation (the detection-side “it reached / a known hole”) and pre-action attestation of per-action authorization (“is this execution authorized right now?”) are a complement, not a substitute.

For the detection-vs-attestation thesis, see “The last layer left for cyber defense in the age of AI” (Lemma, 2026-05); for verifying before the action, see “Proof-as-Auth: sign in without ever sending your key” (Lemma, 2026-05).

Response and Industry Context

Searchlight Cyber: discovered the vulnerability and reported it to ServiceNow on April 1. Its research (“Smashing the ServiceNow Sandbox: Pre-Authentication RCE”) documents the unauthenticated sandbox-escape RCE.
ServiceNow: addressed hosted instances progressively from April and released the self-hosted update on July 13. Its official advisory states it “has not observed evidence of exploitation against instances ServiceNow hosts” and recommends both sets of customers apply the patch. The company also privately disclosed, in the prior month, a separate incident in which customer-instance data was queried via an unauthenticated API (a later advisory explains it as tied to bug-bounty-related research activity; see Brief No.046).
Defused / reporting: Defused confirmed and disclosed in-the-wild exploitation over the weekend, noting that exploitation hitting /assessment_thanks.do reaches the same code execution by a path different from the public PoC. BleepingComputer, Help Net Security, SecurityWeek, and others reported.
Cross-industry point: it was reappraised that on an enterprise foundation running AI workflows at scale, an unauthenticated point of reach plus a sandbox escape can connect directly to full instance takeover. Closing known paths with a patch and replacing “whether execution is allowed” with an independent verification of per-action authorization are separate layers, and without the latter, attempts to “reach the same execution by a different path” remain.

“How to constrain code execution on an AI platform not by the endpoint reached or the sandbox boundary but by an independently verifiable, per-action authorization” is expected to advance, prompted by this incident, as a requirement for enterprise AI foundations.

Lemma’s Analysis

Against the detection–proof gap this incident exposed (an unauthenticated point of reach plus a sandbox escape reaching execution without independently verifying per-action authorization), Lemma proposes a design that requires, before execution begins, a cryptographic proof — independently verifiable and decoupled from the reach path or the sandbox boundary — that the action is authorized for this actor and this scope.

Deny-by-default per-action authorization: before a privileged operation begins, have it prove — decoupled from the endpoint reached, the presence or absence of authentication, and the sandbox boundary — that “this action is authorized for this scope,” and deny by default any execution not accompanied by that proof. Do not make “it could reach an unauthenticated sink” the basis for privileged execution.
Path-independent authorization: by binding authorization to the action itself rather than to the reach path, the deny-by-default holds consistently even against attempts to “reach the same execution by a different path.”
Scoped privilege and minimal environment: allow privileged operations such as MID Server reach and admin creation only under a per-action scoped authorization proof, cutting the chain by which a single point of reach escalates to full takeover. Even when, as here, the initial reach is unauthenticated and holds no actor, this escalation-cutting layer works independently.
Selective disclosure: disclose at minimum only “this execution satisfies the authorization requirement,” keeping internal credentials and secrets out of the environment.

Note that imposing proof-as-auth on the initial point of reach itself, by an unauthenticated, anonymous attacker, means changing the trust model of that public path from “reach = permitted” to “proof of authorization = permitted,” and its application to the initial reach is weaker than in cases where the theft of a key is at issue (Brief No.103 and the like). The main point of this layer is a complement that, combined with patches closing known paths, does not let post-reach privilege escalation translate into “a single point of reach equals full authority.” On that honestly scoped basis, detection (patches closing known paths, observation of in-the-wild exploitation) works on containing known holes, and pre-action attestation (verification of per-action authorization before privileged execution) works on cutting escalation — the two work complementarily.

Sources

Searchlight Cyber (the discovering research): “Smashing the ServiceNow Sandbox: Pre-Authentication RCE” — https://slcyber.io/research-center/smashing-the-servicenow-sandbox-pre-authentication-rce/
NVD: CVE-2026-6875 — https://nvd.nist.gov/vuln/detail/CVE-2026-6875
BleepingComputer: “Critical ServiceNow code execution flaw now exploited in attacks” (2026-07-20; Defused’s confirmation of in-the-wild exploitation, the different-path sandbox escape, ServiceNow’s statement) — https://www.bleepingcomputer.com/news/security/critical-servicenow-code-execution-flaw-now-exploited-in-attacks/
Help Net Security: “ServiceNow pre-auth RCE exploited in the wild (CVE-2026-6875)” (2026-07-20) — https://www.helpnetsecurity.com/2026/07/20/servicenow-cve-2026-6875-exploited/

About this Brief’s distribution

This material is a structured analysis of public information and is not an audit, diagnosis, or recommendation for any specific organization.