Critical ServiceNow AI Platform Flaw Lets Attackers Run Code Unauthenticated

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Platform security and enterprise infrastructure for US and EU teams

The short answer

What did ServiceNow actually patch?

ServiceNow published an advisory for CVE-2026-6875, described as a "Sandbox Escape in ServiceNow AI Platform." A sandbox is the containment layer that is supposed to run code — including AI-generated or automation logic — in a restricted environment, walled off from the underlying system. This flaw lets an attacker break out of that containment and execute code directly on the platform. Critically, ServiceNow's own description notes it can be triggered without valid credentials, which is what pushes the severity to a CVSS score of 9.5.

The exposure is broad. ServiceNow said the issue affects both its managed-cloud (hosted) instances and self-hosted deployments run by customers and partners. The company reports it addressed the vulnerability by deploying a security update to hosted instances automatically, while relevant updates were provided to self-hosted customers and partners to apply themselves. For teams building on top of enterprise platforms — whether you extend ServiceNow or run comparable enterprise software — the split matters: the vendor can fix its own cloud, but any instance you operate yourself is your responsibility to patch.

On exploitation, ServiceNow struck a measured tone: as of its advisory it said it had no evidence of the flaw being exploited in the wild. That is reassuring but not a reason to wait. Unauthenticated RCE bugs in prominent platforms attract fast reverse-engineering once a patch and any technical detail are public, so the gap between "no known exploitation" and "actively exploited" can be short. Treat the absence of attacks as a head start, not a safety margin.

Why does a sandbox escape rank so high?

Severity in a case like this is not just about "code runs." It is about where the code runs and what it can touch. ServiceNow sits at the heart of IT service management for a large share of big enterprises, orchestrating workflows and holding records that connect to identity systems, CMDBs and downstream applications. Code executing on that platform, at the platform's own privilege level, is not an isolated compromise — it is a foothold with reach.

Security analysts covering the disclosure spelled out the plausible consequences of unauthorized code execution in an enterprise service-management environment: access to sensitive business data, manipulation or fabrication of records and workflows, theft of stored credentials or API tokens, and lateral movement into other connected applications. The unauthenticated angle removes the usual first hurdle — an attacker does not need a stolen password or an insider to begin. That combination, a sensitive target plus a no-login entry point, is exactly what a 9.5 rating is meant to communicate.

There is also a specific irony worth naming: the failure is in the AI Platform's sandbox — the very component whose job is to safely contain execution. As enterprises wire generative AI and autonomous agents into their workflow tools, these execution layers multiply, and each one is a place where untrusted input can end up adjacent to real code paths. A sandbox escape is the failure mode that turns "the AI can run a helper action" into "an attacker can run anything."

What risk does this expose in your stack?

The first, immediate risk is unpatched instances. If you self-host ServiceNow or run it through a partner, an unapplied update leaves an internet-reachable, unauthenticated RCE open. That is the kind of exposure ransomware crews and access brokers hunt for, precisely because it needs no credentials and lands on a high-value system.

The second risk is concentration around a platform of record. Systems like ServiceNow accumulate integrations — SSO, secrets, connectors to finance, HR and cloud accounts — so a compromise there is rarely contained to the tool itself. For regulated FinTech and healthcare teams, the compliance stakes are sharp: a breach touching a system that stores or routes customer and transaction data pulls in GDPR, SOC 2 and sector rules, and "we assumed the vendor patched it" is not a defensible control narrative for a self-hosted instance.

The third, quieter risk applies even if you never touch ServiceNow: sandbox debt in your own AI features. Many teams have added code-execution surfaces this year — agents that run tools, functions that evaluate model output, low-code actions triggered by user input — without treating the isolation layer as a hardened security boundary. If your sandbox is a convenience wrapper rather than a defended perimeter, an escape in your product would carry the same shape of consequences this ServiceNow bug does.

What it means for US & EU software teams

If you operate ServiceNow, this is an ordinary but urgent patch cycle. Confirm your instance version against the patched-release list rather than assuming coverage, put self-hosted and internet-facing environments first, and review AI Platform and Now Assist usage logs for anomalies while you are in there. Vendor-managed cloud instances were addressed by ServiceNow, but verification still beats assumption.

The broader takeaway is architectural, and it lands hardest on teams shipping their own AI capabilities. The safest way through the current wave of agentic features is to treat every code-execution surface as hostile-by-default: isolate it with separate tenancy and least-privilege service accounts, segment it on the network, and make the execution layer independently patchable so you can fix it without redeploying the whole application. This is the discipline that separates a durable custom software build from one where an AI helper quietly becomes the softest way in.

There is a procurement read, too. When you evaluate an AI platform — ServiceNow's or anyone's — ask how the execution sandbox is isolated, how quickly the vendor ships and communicates fixes, and what your responsibility is under a self-hosted model. A vendor that discloses clearly, patches its own cloud, and gives self-hosters a fast path is behaving well; the failure mode is the customer who never learns a boundary they depend on has moved. Bake sandbox escape into your own security testing scope so you find these boundaries before an attacker does.

What to do this week

Turn the disclosure into a short, concrete hardening pass rather than a fire drill.

1. Patch ServiceNow now. Check your instance against the patched-release list; prioritize self-hosted and internet-facing deployments, then partner-run environments.
2. Verify, don't assume, cloud coverage. Confirm your hosted instance received the update rather than trusting that "managed" means "already safe."
3. Hunt for anomalies. Review AI Platform / Now Assist logs and access records for unusual execution or privilege activity around the disclosure window.
4. Inventory your own execution surfaces. List every place AI-generated or user-triggered code runs in your products — agents, tool calls, low-code actions — and identify which are actually sandboxed.
5. Harden the sandbox. Enforce least privilege, separate tenancy and network segmentation on each execution layer, and make it patchable on its own.
6. Add escape to your test plan. Include sandbox escape and unauthenticated-RCE paths in your next penetration test, not just injection and auth bugs.

A critical flaw in a mature vendor's AI platform is not a reason to distrust the category — it is a reminder of where the risk concentrates as AI moves into enterprise workflows. Teams that patch quickly and treat their own execution sandboxes as defended boundaries will absorb news like this as routine. Teams that treat the sandbox as an afterthought are one disclosure away from learning why it isn't.

Frequently asked questions

Sources

SecurityWeek — Vulnerabilities Patched by Fortinet, Ivanti, ServiceNow, 15 July 2026
ServiceNow Security Advisory — CVE-2026-6875: Sandbox Escape in ServiceNow AI Platform (KB3137947)
CVE.org — CVE Record: CVE-2026-6875 (ServiceNow)