CVE-2026–6875: How One javascript: Prefix Broke ServiceNow's Sandbox

On July 14, 2026, researchers at Searchlight Cyber dropped a bombshell for anyone running a self-hosted ServiceNow instance: a critical, completely unauthenticated remote code execution vulnerability, now tracked as CVE-2026–6875. ServiceNow shipped patches the same day. It didn't matter. By July 17, attackers were already exploiting it in the wild.

That's a three-day gap between "here's the patch" and "here's the exploit." If you manage a self-hosted instance and haven't updated, this is your sign.

In this article: how the bug works, how researchers escaped ServiceNow's sandbox, who's exploiting it right now, and what to do about it.

Why this one matters more than most CVEs

ServiceNow isn't a niche product. The platform reportedly runs over 100 billion workflows a year and powers AI-driven applications at roughly 85% of Fortune 500 companies. A pre-authentication RCE on infrastructure that central isn't a routine patch-Tuesday item — it's the kind of bug that ends up in incident response retrospectives.

The bug: a feature that evaluates itself into trouble

The root cause traces back to ServiceNow's GlideRecord query API — the interface that accepts user-supplied data in hundreds of spots throughout the codebase. Buried in that API is a documented quirk: prefix any value with javascript:, and ServiceNow will evaluate the string as live JavaScript before treating it as a query argument.

In other words, a feature meant for convenience turned every one of those query entry points into a potential script execution vector — for anyone who could find an unauthenticated one to reach.

ServiceNow wasn't blind to this risk. It had already wrapped user-supplied filters in a second layer of defense, a purpose-built script sandbox. That sandbox blocks eval, restricts which Java classes are reachable, limits function definitions, and keeps unauthenticated table access strictly read-only. On paper, that should have contained the blast radius.

Escaping the sandbox

This is where Searchlight's research gets interesting. The sandbox restricted code running inside it — but functions pulled in through gs.include(), ServiceNow's mechanism for loading external script libraries, weren't bound by the same restrictions.

The researchers found they could override Object.clone with the Function constructor, then set AbstractAjaxProcessor.prototype to their own payload. When the code subsequently called gs.include('ItemViewElementsProvider'), the sandbox ended up invoking Function(payload) in a completely unsandboxed context — handing the attacker a live, callable function outside any of the sandbox's guardrails.

From there, the path to real damage was short. The reachable, unauthenticated entry point turned out to be the /assessment_thanks.do endpoint, via a parameter called sysparm_assessable_type — user input from that parameter flows straight into a GlideRecord query with no sanitization at all.

With code execution achieved outside the sandbox, an attacker gets the same access Searchlight had flagged in an earlier, related bug: the ability to pull data from any table, mint admin accounts on demand, and run shell commands on any connected proxy server — servers that often sit deep inside a company's internal network.

The response — and the race that followed

Searchlight reported the vulnerability privately back on April 1, 2026. To ServiceNow's credit, cloud instances got mitigations within 24 hours, blocking modification of the key JavaScript functions the exploit relies on. Full patches addressing the underlying issue for self-hosted instances followed over the next several weeks, landing July 14.

ServiceNow also hardened the sandbox itself going forward: a new "Guarded Script" mode now restricts executable code to a single simple expression, blocking variable declarations, control flow, function definitions, and multi-statement payloads outright — a structural change meant to make this entire class of sandbox escape much harder to repeat.

None of that stopped the clock, though. Threat intelligence firm Defused confirmed active, in-the-wild exploitation just three days after the patch dropped — hitting the same /assessment_thanks.do sink Searchlight had documented, though reaching code execution through a different gadget chain of their own.

As of this writing, ServiceNow's official advisory still states the company isn't aware of exploitation against its instances — a gap worth noting between vendor messaging and independent threat intel.

What you should do right now

Status Action Self-hosted ServiceNow instance Apply the July 14 patch immediately if you haven't Cloud-hosted instance Confirm the April mitigation is active; check for the newer Guarded Script update Either Review logs for requests to /assessment_thanks.do with unusual sysparm_assessable_type values Either Audit for unexpected admin account creation in the relevant window (mid-to-late July 2026) Either Check connected proxy servers for signs of unauthorized shell command execution Ongoing Treat the disclosure-to-exploitation window (about 72 hours here) as your new baseline for patch urgency on internet-facing enterprise platforms

The takeaway

What stands out about CVE-2026–6875 isn't just the severity — it's the speed. A researcher-disclosed, vendor-patched vulnerability was being actively exploited within three days, on a platform that sits at the center of enterprise IT for a huge share of the Fortune 500. The sandbox escape itself is also a good case study in a recurring theme in application security: a defense-in-depth layer (the script sandbox) is only as strong as its most permissive escape hatch (gs.include()), and attackers are very good at finding exactly that hatch.

If you run ServiceNow anywhere in your stack, this is worth checking today — not next patch cycle.

Source: Searchlight Cyber research report; Security Affairs.