TL;DR
- 01What happened
ServiceNow AI Platform had a flaw, CVE-2026-6875 (CVSS 4.0 score 9.5), that let input to a page reachable without logging in (
/assessment_thanks.do) be evaluated as JavaScript, escape the sandbox and run arbitrary code. Searchlight Cyber reported it on April 1; ServiceNow mitigated its cloud instances within 24 hours and published an advisory on July 13. The researcher published details on the 14th, and exploitation attempts were seen on the 17th. - 02Why it was hard to tell
Code that escapes can read any table, create admins and run commands on the relay servers (MID Servers) customers place inside their own networks. To the platform, all of it runs as the system’s own legitimate processing.
- 03The missing layer
No actual compromise has been reported, but attempts against unpatched instances began three days after the details went public. What failed was the layer that checks, before it runs, who authorised a permission-changing action like creating an admin, whatever entry point it came through.
What happened
- Target
- ServiceNow AI Platform, which runs companies’ IT, HR and customer-service work. According to the company, more than 85% of the Fortune 500 use it.
- Flaw
- CVE-2026-6875. A parameter on
/assessment_thanks.do, reachable before login, is evaluated as JavaScript as part of a data query. The evaluation happens inside a sandbox, but a mechanism for loading another script let code step outside its limits. - Severity
- CVSS 4.0 score 9.5 (Critical, scored by ServiceNow). Attack complexity is rated High.
- What it allows
- Reading any table, creating admins, and running commands on the MID Servers inside the customer’s network (per the researcher).
- Fix
- Cloud instances were mitigated within 24 hours of the report. The July 13 advisory lists fixed releases for each family (Zurich, Yokohama, Australia, Brazil). The fix immediately applies a “single expression only” restriction (Guarded Script) to pre-login traffic.
- Exploitation
- Attempts were seen from July 17. Defused says the payload it captured matched the researcher’s published validation payload (its first claim of “a different route” was corrected on the 20th). No actual compromise has been reported, and the CVE is not in CISA’s Known Exploited Vulnerabilities catalog (as of 2026-10-20).
Glossary
Sandbox — A restricted environment for running code received from outside. Escape it and the code can do anything the system can.
Pre-auth entry point — A page or API reachable without logging in. A hole here lets anyone try an attack.
MID Server — A relay server a ServiceNow customer runs inside its own network so the platform can talk to internal servers.
The patch closes the entry hole. There is also a stopping point at ④: check who authorised a permission-changing action before it runs, and getting through the hole does not mean full control.
/assessment_thanks.do
Inside the sandbox.
Runs without restrictions.
Runs as legitimate processing.
Timeline — disclosure and response
- Searchlight Cyber reports to ServiceNow, which deploys mitigations to all cloud instances within 24 hours.
- ServiceNow publishes its advisory (KB3137947) with fixed releases: “We are not currently aware of exploitation against ServiceNow instances.”
- Searchlight Cyber publishes technical details.
- Exploitation attempts begin to be seen (press reports).
- Defused posts on X, saying the route differs from the researcher’s published PoC.
- Defused corrects this: the captured payload matched the published one. ServiceNow tells the press it has not observed evidence the activity relates to instances it hosts. Canada’s Centre for Cyber Security adds the exploitation reports to its advisory.
Facts rest on ServiceNow’s advisory, Searchlight Cyber’s research and Defused’s posts (all primary), and on press reports. Reports disagree on when self-hosted fixes arrived (June or July 13). As of October 2026, no actual compromise, KEV listing or Japanese government alert has been found.
After disclosure
- SecurityWeek: Reported that the attempts may have come from members of the security industry looking for vulnerable systems.
- ServiceNow: Guarded Script applies to pre-login traffic immediately, and to logged-in traffic on cloud instances over about four weeks. On self-hosted instances, admins move through the phases by hand.
Why it wasn’t stopped
This case was not a failure of customer care, nor only of slow patching. Once a value entered before login escaped the sandbox, reading data and creating admins went through as the platform’s legitimate processing, never asked who had authorised them.
Once a value entered before login escaped the sandbox, every later action ran as legitimate processing, never asked who had authorised it.
Proof works before an action runs; detection works after attempts or anomalies surface. In between, actions by code that got through the entry point are treated as legitimate processing.
Three days from disclosure to attempts
Detection worked: ServiceNow mitigated cloud instances within 24 hours of the report, and Defused caught attempts three days after the details went public. But a patch closes the hole that was found, and although “it reached the entry point” and “this action is authorised” are separate facts, on this platform the first stood in for the second. That distance is the detection–proof gap, and it is a structural one.
The same structure appears in ServiceNow’s unauthenticated API (one setting removed authentication and customer instance data was queried).
How to counter this
Close the entry holes, and stop what gets through with permissions. Apply the fixed releases and reduce the entry points reachable before login. Beyond that, check before they run who authorised permission-changing actions, such as creating an admin or running commands on internal servers, whatever entry point they came through. When the next hole is found, it will not reach full control.
Industries and operations to watch
- IndustryAI adoption (cross-industry)
- Organisations that run IT, HR and customer-service work on a business platform like ServiceNow. Business data and connections to internal systems gather there.
- OperationAccounts & permissions
- Creating admin accounts and connecting the platform to internal servers. Here, both could be reached from a single request before login.
Do today’s controls close it?
| Control | This case | Why |
|---|---|---|
| Applying fixed releases | Partial | It closes the hole that was found, but not the window before patching or the next hole. |
| Login and multi-factor authentication (MFA) | Not relevant | The entry point was before login. |
| Sandbox | Ineffective | There was a way out of its limits. |
| Monitoring admin creation and connections | Partial | It can notice, but only after the admin exists. |
- Apply fixes and reduce pre-login entry points. On self-hosted instances, move through the Guarded Script phases yourself. Turn off unused public pages and guest traffic.
- Check permission-changing actions before they run, whatever the entry point. For admin creation, role grants and commands on internal servers, match who is acting under which permission, and do not let it through if that cannot be matched.
- Record which permission allowed which action, outside the platform. Keep what was stopped and what was let through in a form that can later be shown to a third party: in other words, as proof.
Three things to confirm in your organisation about business platforms (cloud or self-run)
- Have you closed the entry points reachable without login that you do not use?
- When a new admin account is created, who gets notified?
- When a critical vulnerability is announced, is there a set number of days within which fixes are applied?
Note: if code that got through the entry point runs where it can rewrite the permission check itself, this check can be broken too. Placing the check outside the platform makes it stronger, but also adds work to legitimate admin tasks.
Sources
- Primary, vendor advisoryServiceNow “CVE-2026-6875 - Sandbox Escape in ServiceNow AI Platform”
- Primary, researcher’s write-upSearchlight Cyber “Smashing the ServiceNow Sandbox: Pre-Authentication RCE”
- Primary, post on XDefused Exploitation attempts observed
- Primary, post on XDefused Correction that the payload matched the public PoC
- Primary, vulnerability databaseNVD CVE-2026-6875
- Primary, advisoryCanadian Centre for Cyber Security “ServiceNow security advisory (AV26-693)”
3 more (reporting, analysis)
- ReportingBleepingComputer “Critical ServiceNow code execution flaw now exploited in attacks”
- ReportingHelp Net Security “ServiceNow pre-auth RCE exploited in the wild (CVE-2026-6875)”
- ReportingSecurityWeek “Exploitation of ServiceNow Vulnerability Seen Days After Disclosure”
References: “The last layer left for cyber defense in the age of AI”, “Proof-as-Auth: sign in without ever sending your key”