CVE-2026-6875 (CVSS 9.5): No Password Required — Attackers Are Actively Exploiting ServiceNow’s Pre-Auth Sandbox Escape

At 14:38 IST on 21 July 2026, a ServiceNow instance at your organisation is almost certainly processing a ticket — an access request, an HR onboarding, a vendor payment. What it may also be doing is waiting for an unauthenticated attacker to send a single crafted HTTP request, escape the platform sandbox, and obtain the same power as a platform administrator. That scenario is no longer theoretical. CVE-2026-6875 (CVSS 9.5) is under active exploitation, and a second bypass technique for the published proof of concept was confirmed over the weekend. If you run self-hosted ServiceNow, the patch has been available since July 13. Every day you wait is a day you are choosing to leave the door open.

What Is CVE-2026-6875? The Short Answer for Decision-Makers

ServiceNow’s AI Platform (formerly the Now Platform) runs JavaScript-based business logic inside a two-layer sandbox. The outer layer grants scripts broad platform-administrator capability while shielding the underlying operating system. An inner layer — the “script sandbox” or “filter sandbox” — is meant to apply tighter restrictions to any user-supplied input before it can touch the outer layer.

CVE-2026-6875 is a code injection flaw in the GlideRecord query API. When a caller passes an addQuery() argument prefixed with javascript:, the platform evaluates the expression as live JavaScript before using the result as a query value. An attacker who knows this behaviour can escape the inner sandbox — reaching the code-execution primitive with full outer-layer privilege — without having authenticated to the platform at all. The vulnerable endpoint is /assessment_thanks.do, which is exposed to unauthenticated callers.

The vulnerability was discovered by Searchlight Cyber, who reported it to ServiceNow on 1 April 2026. ServiceNow patched SaaS-hosted instances within a day, but the patch for self-hosted customers was only released publicly on 13 July 2026 alongside full technical disclosure. That five-day window between public disclosure and the first observed exploits is remarkably short, suggesting sophisticated actors were watching the advisory closely.

Technical Breakdown — Inside the Sandbox Escape

Understanding how this works matters because your firewall rules, WAF signatures, and EDR tuning depend on the attack shape. Here is what the kill-chain looks like:

1. Unauthenticated HTTP request to /assessment_thanks.do with a specially crafted sysparm_query parameter containing a javascript:-prefixed payload.
2. GlideRecord evaluation: the platform’s query engine processes the prefix, evaluating the attacker-controlled JavaScript expression inside the inner sandbox.
3. Sandbox escape: the evaluated expression leverages a “gadget chain” — a sequence of trusted internal platform objects — to pivot from the filter sandbox into the outer execution layer.
4. Code execution with platform-admin privilege: from here, the attacker can read every data table (HR records, credentials, financial data), create new administrator accounts, install malicious applications, or send commands to MID Server proxy agents — machines that sit on your internal network and relay data between ServiceNow and your on-premises systems.

The detail that makes this especially dangerous: Defused security researchers confirmed over the weekend that attackers are already using a second sandbox-escape gadget chain that reaches the same code-execution primitive by a different route than Searchlight Cyber’s published PoC. In their words: “The payloads hit the same pre-auth sink @SLCyberSec documented (/assessment_thanks.do), but the sandbox-escape gadget reaches the same code-execution primitive by a different route than their published PoC.”

This matters enormously for defenders. A WAF rule or IDS signature written specifically for the original PoC will not catch the second chain. You cannot signature-patch your way out of this; you must apply the vendor patch.

Attribute	Value
CVE ID	CVE-2026-6875
CVSS Score	9.5 (Critical)
Vulnerability Type	Pre-authentication code injection / sandbox escape → RCE
Authentication Required	None
Vulnerable Endpoint	/assessment_thanks.do
Root Cause	addQuery() evaluates javascript:-prefixed input as live JS
Discovered By	Searchlight Cyber (reported 1 April 2026)
SaaS Patch Date	April 2026
Self-Hosted Patch Date	13 July 2026
Active Exploitation Since	18 July 2026

Why ServiceNow Means Maximum Blast Radius

If this were a bug in an obscure IoT device, we could shrug. It is not. ServiceNow’s platform processes over 100 billion workflows a year across IT service management, HR, legal, finance, and security operations. 85% of Fortune 500 companies use it. In India, major BFSI institutions, IT/ITES companies, and government-linked enterprises have been aggressive adopters, particularly as the platform’s AI capabilities — the reason it was rebranded the “AI Platform” — gained traction in automated NOC/SOC workflows.

A compromised ServiceNow instance is not a compromise of one application. It is often a compromise of your entire IT management layer:

• HR workflows: employee PII, salary data, termination records, background check results.
• ITSM ticket history: a goldmine of vulnerability disclosures, incident details, and change management records that give attackers a map of your infrastructure.
• MID Server lateral movement: MID Servers are privileged agents that sit inside your network. Compromising one via a ServiceNow instance gives an attacker a beachhead on your LAN without ever touching a perimeter device. This is particularly significant for organisations where ServiceNow integrates with monitoring tools like SolarWinds, Dynatrace, or Splunk.
• Credential exposure: service account credentials, OAuth tokens, and API keys stored in ServiceNow’s credential tables can cascade into Active Directory, cloud environments, or third-party SaaS platforms.

This attack profile rhymes with what we saw earlier this year when CVE-2026-46817 gave unauthenticated attackers full access to Oracle EBS Payments — enterprise platforms are the new perimeter, and they are increasingly the target.

The Evolving Threat Landscape: Why “We Patched the PoC Signature” Is Not Enough

The appearance of a second gadget chain within days of the initial exploitation wave signals that threat actors are actively investing in this vulnerability. This is the pattern we have seen with other high-value pre-auth RCEs: the first wave uses the published PoC; within a week, custom variations emerge that bypass detection content written for the original payload.

Organisations that believe they are protected because their WAF is blocking the Searchlight Cyber PoC’s specific payload should reconsider that assumption today. The endpoint is the same (/assessment_thanks.do), but the gadget chains are not — and more variants are likely coming as the vulnerability ages and wider attacker communities develop tooling around it.

This is also why I am cautious about the “complexity: high” designation some sources have applied. High complexity typically means the attacker needs specific conditions or knowledge. In practice, the barrier has proven low enough that exploitation began within five days of patch release, and multiple independent attack paths already exist. The effective complexity for a well-resourced threat actor is low.

What You Should Do Right Now — Sanjay Seth’s Defensive Playbook

Here is the prioritised action list for IT and security leaders managing ServiceNow deployments:

1. Identify your deployment model immediately.
   • SaaS/hosted: ServiceNow says hosted instances were patched in April 2026. Verify this with your account team — do not assume. Ask for written confirmation of your instance’s patch level.
   • Self-hosted: You must update to one of the fixed releases: Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 HF 1b, or Yokohama Patch 13. If you are on any older release family, apply the latest applicable fix immediately.
2. Block or tightly restrict /assessment_thanks.do at the perimeter while patching is in progress. This is not a substitute for patching — it will not catch the second gadget chain if it targets a different path — but it reduces your exposure surface. Check your F5, Fortinet FortiWeb, or reverse-proxy logs for unusual traffic to this endpoint right now.
3. Audit your MID Servers. Pull a list of all MID Servers connected to your ServiceNow instance. Verify each host’s integrity — look for unexpected processes, new user accounts, unusual outbound connections. A compromised MID Server could have given an attacker LAN access without triggering any ServiceNow-side alert.
4. Review credential tables and OAuth tokens in ServiceNow. If exploitation happened before you patched, assume all credentials stored in the platform are compromised. Rotate service account passwords and API keys, particularly any used for integrations with Active Directory, cloud platforms, or security tooling.
5. Search your SIEM and WAF logs for /assessment_thanks.do access going back to 18 July 2026. Focus on any unauthenticated or anonymised requests. Look for unusual session creation, new admin account activity, or privilege escalation events in the ServiceNow audit log.
6. Apply zero-trust principles to your ServiceNow integration layer. ServiceNow should only be able to reach the systems it absolutely needs to, using least-privilege credentials. If your MID Servers have broad network access, segment them now — this is a lesson we re-learn after every major enterprise platform breach.
7. Engage your vendor and CSM. Demand a written SLA for breach notification from ServiceNow. If you are in a regulated sector (BFSI, healthcare, defence), notify your CISO and legal counsel — depending on what data ServiceNow processes, a successful exploit may trigger breach disclosure obligations under DPDPA, RBI guidelines, or SEBI frameworks.

For organisations that have already patched: do not stop there. This incident is a warning that your enterprise workflow platforms are now tier-one attack targets. A formal zero-trust architecture review of your ServiceNow deployment — covering network segmentation, MID Server privileges, credential hygiene, and integration access controls — is overdue if you have not done one in the last 12 months.

Frequently Asked Questions

Are ServiceNow SaaS (cloud-hosted) customers safe?

ServiceNow reports that it patched all cloud-hosted instances in April 2026 and has seen no evidence of exploitation on its hosted infrastructure. However, “no evidence” reflects their telemetry at the time of their statement. You should still request written confirmation of your instance’s patch level from your ServiceNow account team, and audit your MID Servers and credential tables regardless — especially if any MID Servers are running inside your on-premises network.

Our WAF is blocking the CVE-2026-6875 PoC. Are we protected?

Partially — and that is the problem. Defused researchers confirmed a second sandbox-escape gadget chain that reaches the same execution primitive via a different route than the published PoC. Your WAF rule may block Chain 1 while Chain 2 sails through. The only complete protection is the vendor patch. Treat WAF rules as a temporary risk-reduction measure, not a remediation.

What data is most at risk if our ServiceNow instance was compromised?

Everything in every table that the platform-admin role can access — which is typically everything. Priority concerns include: HR records and PII, ITSM incident history (which maps your infrastructure), change management logs, stored credentials and OAuth tokens, and any data passed through integration workflows. If your ServiceNow instance integrates with your HRMS, payroll, or financial systems, assume those pipelines were visible to an attacker.

We are an Indian enterprise. Should we be worried specifically?

Yes. Indian BFSI, IT/ITES, and large enterprises are significant ServiceNow customers — the platform is deeply embedded in NOC/SOC automation, HR, and compliance workflows. If exploited and a data breach has occurred, DPDPA (Digital Personal Data Protection Act) and sector-specific RBI/SEBI guidelines impose breach notification obligations. You should brief your DPO now, document your patch status and investigation findings, and be ready to move quickly on disclosure if evidence of exploitation is found.

---

Bottom line: CVE-2026-6875 is a right now problem — not a “patch it next maintenance window” problem. The exploit is live, multiple attack chains exist, and the platform’s reach into enterprise workflows makes a successful compromise catastrophically consequential. Patch, investigate, and then rebuild your trust model for your ServiceNow environment from the ground up.