ServiceNow AI Platform: a sandbox escape allows unauthenticated code execution
On July 13, 2026, ServiceNow patched a critical sandbox escape in its AI Platform that lets an unauthenticated attacker run code on affected instances. It's a reminder that the sandbox around an AI feature is a security boundary — treat it like one.
What is this?
On July 13, 2026, ServiceNow published an advisory (KB3137947) for a critical vulnerability in its AI Platform — the layer that runs AI-assisted features and the code they generate or execute inside ServiceNow environments. The flaw is described as a sandbox escape: under certain conditions, an attacker can break out of the restricted execution environment the platform relies on and run code directly on the instance. What makes it serious is that exploitation, per ServiceNow, does not require authentication, and it affects both ServiceNow-hosted and self-hosted deployments.
ServiceNow says it has already patched its hosted instances and shipped fixes to self-hosted customers and partners, and that it is not aware of exploitation in the wild as of the advisory date. The company deliberately kept technical detail out of the advisory to give customers time to patch before a reliable exploit is developed — a standard responsible-disclosure posture for a pre-exploitation critical flaw.
How it works
ServiceNow has not released the underlying technical cause, so what follows is the general class rather than a working exploit. AI platforms routinely execute untrusted or model-generated content — expressions, scripts, tool calls — inside a sandbox meant to constrain what that code can touch. A sandbox escape is any bug that lets code inside that boundary reach outside it: a missing restriction on an API surface, an object reachable from the sandbox that exposes privileged functionality, or a parsing/evaluation path that runs attacker-controlled input with more authority than intended.
The important structural point is the combination of two properties. First, the vulnerable surface is reachable without credentials, which turns “an authenticated user could misbehave” into “anyone with network access to the instance can.” Second, a successful escape lands the attacker in the platform’s own execution context, where — on a system used for IT service management, workflow automation, and security operations — they could disrupt workflows, read or modify records, or pivot to other systems the instance can reach.
Why it matters
Enterprises run a lot of sensitive process on ServiceNow, and instances are frequently exposed to broad networks by design. An unauthenticated code-execution primitive against that kind of platform is close to a worst case: no phishing, no stolen token, just network reach to an unpatched instance. The absence of observed exploitation is cold comfort, because public disclosure of a critical unauthenticated flaw tends to accelerate reverse-engineering — the window between “patch is out” and “exploit exists” is often short.
More broadly, this is the pattern to internalize as AI features spread into enterprise platforms: every new “let the AI run this” capability ships a new execution sandbox, and that sandbox is now part of your attack surface. The security of the feature is only as good as the security of the boundary around it, and those boundaries are new, complex, and under-tested compared to the platforms they’re bolted onto.
Defenses
The concrete, immediate action is to patch, but the durable lessons are architectural.
- Apply the fix per release family. ServiceNow addressed the flaw across its supported trains — for self-hosted instances, install the patch for your family (the advisory lists fixed releases including recent Zurich and Yokohama patch levels) rather than assuming hosted-side fixes cover you.
- Confirm hosted vs self-hosted status. Hosted customers should verify the platform update landed; self-hosted administrators own their own patch timeline and should treat this as urgent even without signs of activity.
- Reduce network exposure. Unauthenticated flaws are far less dangerous when the instance isn’t broadly reachable. Put ServiceNow behind network-layer restrictions (VPN, IP allowlisting, WAF) so “network access” isn’t equivalent to “internet.”
- Treat AI execution sandboxes as trust boundaries, not conveniences. Any platform that runs model-generated or user-supplied code should assume the sandbox will eventually be escaped: minimize what the sandbox can reach, deny outbound network by default, and scope the platform’s own credentials to least privilege.
- Monitor for post-patch abuse. Watch administrative activity, unexpected integrations, unusual workflow or record changes, and anomalous API behavior — the signals a successful escape would produce even if the entry point is now closed.
Status
| Item | Value |
|---|---|
| Product | ServiceNow AI Platform (hosted and self-hosted) |
| Nature | Sandbox escape → unauthenticated remote code execution |
| Disclosed | July 13, 2026 (advisory KB3137947) |
| Reference | CVE-2026-6875 |
| Fixed in | Brazil EA/GA; Australia Patch 2; Zurich Patch 7b/9; Yokohama Patch 12 HF1b/Patch 13 |
| Exploitation | None known in the wild as of disclosure |
| Auth required | No |
Key dates: July 13, 2026 — ServiceNow advisory and patch; July 14, 2026 — press coverage. ServiceNow has not published technical root-cause detail, consistent with pre-exploitation responsible disclosure.