Why This One Belongs at the Top of the Queue
We rank vulnerabilities by where they sit and what they touch, and CVE-2026-6875 scores badly on both. ServiceNow is the connective tissue of enterprise IT: it brokers change management, HR cases, security operations, and the service catalog, and it holds privileged credentials to reach almost everything downstream. A pre-authentication remote code execution flaw on that platform is a foothold with a directory of onward targets already attached. The CVSS score of 9.5 reflects the impact, and the real risk multiplier is the integration sprawl most enterprises have wired into their instance over years.
The exposure math is stark. ServiceNow says its AI Platform runs an estimated 100 billion workflows a year, and analysts put its footprint at roughly 85 percent of the Fortune 500. When a bug lets an unauthenticated attacker run code on that layer, the population of high-value targets is enormous and known. For a CISO or CTO, this is the kind of flaw that justifies pulling an emergency change window rather than waiting for the next monthly cycle. We would treat any internet-reachable ServiceNow instance as presumed-targeted until the patch is confirmed applied and the logs are reviewed.
How the Sandbox Escape Works
The flaw lives in ServiceNow's script execution environment, specifically the query engine that backs GlideRecord. ServiceNow exposes a query-filter operator that evaluates attacker-supplied text as JavaScript, and several pre-authentication endpoints pass unauthenticated user input straight into that engine. That combination lets an attacker slip out of the intended sandbox and reach a code-execution primitive without ever presenting credentials. Researchers observed attacks arriving as HTTP POST requests aimed at the /assessment_thanks.do endpoint, an unauthenticated survey-response handler that most operators never think about as an attack surface.
Adam Kues of Searchlight Cyber, who reported the issue, described it as "exploitable in high-complexity attacks, but allowing unauthenticated code execution and full compromise of the ServiceNow instance." High complexity is not comfort here. The threat intelligence firm Defused confirmed that attackers in the wild used a different sandbox-escape gadget route than the published proof of concept, reaching the same outcome through an alternative path. That detail matters for defenders: any virtual patch or WAF signature written only against the public PoC will miss the variant that is already live, so the durable fix is the vendor patch itself.
The Timeline Defenders Need to Understand
The disclosure clock ran fast. Searchlight Cyber reported the vulnerability to ServiceNow on April 1, 2026. ServiceNow shipped fixes across its release trains, with self-hosted customers receiving the security update in mid-July. The existence of CVE-2026-6875 became public around July 13, and researchers observed the first in-the-wild exploitation attempts within days, with active abuse confirmed by July 21. That is a compressed window between public knowledge and mass exploitation, which is now the normal cadence for critical enterprise SaaS flaws.
The patched versions span ServiceNow's family releases, including Brazil, Australia Patch 2, Zurich Patch 7b and Patch 9, and Yokohama Patch 12 Hot Fix 1b and Patch 13. Operators should confirm the exact build their instance runs rather than assuming a family name covers them, because the hot-fix designations carry the actual remediation. For teams that manage multiple instances across sub-production and production, the audit needs to cover all of them. Attackers do not care whether an internet-reachable instance is labeled a sandbox environment, they care whether it answers on /assessment_thanks.do.
Hosted Versus Self-Hosted Changes Your Exposure
ServiceNow drew a line in its response, stating: "Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts." For customers on ServiceNow-managed cloud instances, that suggests the vendor absorbed the patching, though verification through your account team is still worthwhile. The sharper risk falls on self-hosted deployments, where the customer owns the update cadence. Those are the instances most likely to be lagging, and they are exactly the ones attackers are scanning for right now.
This split is a governance lesson worth capturing beyond this single CVE. Many organizations assume that a SaaS-branded platform means the vendor patches everything, and self-hosted or on-prem editions quietly break that assumption. For a CIO, the action item is a clear inventory of which ServiceNow instances are vendor-managed and which are your responsibility, with named owners for the second category. The same question applies to every major platform in the estate, because the moment exploitation starts, ambiguity about who patches is the same as nobody patching.
What Compromise Actually Costs Here
Code execution on a ServiceNow instance is the beginning of the attack, the launch point for reaching the connected estate. The platform stores integration credentials, service account tokens, and connection details for the systems it orchestrates, which can include Active Directory, cloud tenants, ticketing, and monitoring. A full compromise of the instance, in Searchlight Cyber's words, puts all of that within reach, along with any proxy servers the instance connects through. That is how a single web endpoint becomes lateral movement into identity infrastructure and cloud control planes.
There is also a data-sensitivity dimension that legal and privacy teams should not miss. ServiceNow instances frequently hold HR case records, IT support transcripts containing credentials users pasted into tickets, and security operations data describing the organization's own defenses. An attacker reading that content learns the internal map before making a move. For incident responders, the assumption after any confirmed exploitation should be that stored secrets are burned, which means credential rotation for integrations, not just applying the patch and closing the ticket.
The Decision in Front of Security Leaders
The immediate move is unambiguous: apply the July security update to every self-hosted ServiceNow instance now, confirm the build number, and treat internet-reachable instances as the top priority. ServiceNow's new Guarded Script feature tightens what code can run in sandbox contexts and is worth enabling as a forward defense, though it does not substitute for the patch on an already-exposed instance. Teams should also hunt for exploitation evidence in web logs, focusing on POST traffic to /assessment_thanks.do and anomalous script execution, because active abuse predates most detection signatures.
The wider takeaway is about how we treat the platforms we have decided to trust with everything. A workflow engine that touches identity, finance, and operations deserves the same patch urgency and the same monitoring depth as a domain controller, because functionally it operates like one. We would use this CVE as the prompt to reassess exposure of all business-critical SaaS admin surfaces, confirm which endpoints answer without authentication, and put named owners against emergency patching for each. The next pre-auth flaw on a platform this central is a question of when, and readiness is the only variable a leader controls.
