SURIQ
ServiceNow instances are being broken into right now, and the exploit code circulating in public is not the one hitting real targets. Researchers who published a proof of concept for CVE-2026-6875 documented one way through the platform's script sandbox. The payloads landing on live instances since Friday reach the same result through a different path. That gap is the story: any team that responded by blocking the published technique, instead of applying the patch, is still exposed.
The flaw sits in the ServiceNow AI Platform, the rebranded Now Platform that a large share of enterprises run for IT service management, HR, and security operations. Searchlight Cyber reported it to ServiceNow in early April. ServiceNow rated it CVSS 9.5 and shipped fixes to its hosted customers the following day. Self-hosted operators only received patches on July 13, when the CVE became public, and Defused reported the first in-the-wild payloads on July 18, five days later. Self-hosted instances that patch on their own schedule are the exposed ones, a pattern that keeps repeating for actively exploited enterprise software.
What the sandbox escape lets an attacker do
CVE-2026-6875 is a pre-authentication code-injection flaw. An attacker with only network access to a vulnerable instance can run code on it with no login, no credentials, no phishing, and no prior foothold, the same unauthenticated reach that made recent pre-auth bypasses in privileged-access appliances so serious. Successful exploitation gives full control of the instance, including its stored data and the ability to create administrator accounts.
The root cause is in how the platform loaded included script libraries. Searchlight Cyber found that the gs.include() function pulled libraries into a less restricted execution context. By manipulating the global JavaScript objects those libraries touch, an attacker could get their own code compiled and executed outside the stricter sandbox that is supposed to contain untrusted script. In the observed attacks the entry point is the unauthenticated /assessment_thanks.do endpoint, which is a useful string to watch in your access logs.
Why blocking the public exploit is not the same as fixing it
When a proof of concept goes public, a common reflex is to write a signature for it: a web application firewall rule, an intrusion detection pattern, a block on the exact request the exploit sends. For CVE-2026-6875 that reflex is a trap. The sandbox escape is not a single magic string. It is a class of manipulation against how included scripts are compiled, and sandbox escapes rarely reduce to one blockable payload.
Searchlight Cyber documented one gadget. The attackers hitting live instances are using another to reach the identical code-execution primitive, which means a rule tuned to the published exploit waves them through. This is the recurring weakness of virtual patching against sandbox and deserialization bugs: you block an instance of the technique, not the underlying flaw. Here the only reliable fix is the vendor patch.
The real blast radius is your MID Server
A compromised ServiceNow instance is bad on its own. What turns this into a network problem is the MID Server. The MID Server is a lightweight application that ServiceNow customers install inside their own network so the cloud platform can reach internal systems for discovery scans, orchestration, and integrations with on-premises tooling. According to the reporting, code execution on the instance can extend to running commands on connected MID Server hosts.
That converts a pre-authentication web flaw in a cloud platform into command execution on a machine sitting inside your perimeter, with whatever the MID Server's service account can reach. It is the same exposure that makes an unauthenticated flaw in an in-cluster service so dangerous. If you treated ServiceNow as a contained SaaS risk, this is the part to reassess. The MID Server is a pivot point, and it lives on your side of the firewall.
Patch first, then hunt where the attacker would land
Patch to a fixed release for your family from the table above. Self-hosted instances are the ones still exposed, since hosted customers were covered back in April. Then assume the five-day window between the July 13 patch and the July 18 exploitation may have been enough, and hunt.
Because the in-the-wild route differs from the public exploit, indicators of compromise drawn from that exploit will not match. Hunt on behavior instead:
- New or unexpected accounts in the
sys_usertable holding the admin role, especially any created after July 13. - Anomalous script execution and outbound connections on your MID Server hosts, which should have a predictable, narrow set of destinations.
- Unauthenticated requests to
/assessment_thanks.doin your instance access logs, correlated with unusual server-side activity.
The signal that matters most is not on ServiceNow's cloud, which you cannot instrument, but on the MID Server hosts you own. Those are ordinary servers. Process, authentication, and network telemetry from them is where a managed detection layer would catch the pivot that the platform itself will not show you.
The pattern is familiar and getting faster. A critical pre-authentication flaw in a widely deployed enterprise platform went from public patch to mass exploitation in five days, and the operators who patch on their own schedule are the soft target every time. Hosted customers were quietly fixed in April. The lesson is not that ServiceNow was slow. It is that the window to patch enterprise infrastructure is now measured in days, and blocklisting the first public exploit is no substitute for closing the hole.
| Release family | Fixed in |
|---|---|
| Yokohama | Patch 12 Hot Fix 1b, Patch 13 |
| Zurich | Patch 7b, Patch 9 |
| Australia | Patch 2 |
| Brazil | Brazil GA and later |