ServiceNow's AI Platform sandbox escape: patched in July, attacked within days

TechScripts Nepal · Kathmandu · October 30, 2026 · 5 min read

ServiceNow sits in the middle of a lot of companies' IT, HR and security workflows, which is why a pre-authentication code-execution flaw in it gets attention. CVE-2026-6875, rated 9.5 out of 10, is exactly that: a sandbox escape in the ServiceNow AI Platform (formerly the Now Platform) that an unauthenticated attacker could use to run code on an instance.

This post covers the reported timeline, where the sources disagree, and what's worth checking. It leans on the Cloud Security Alliance's research note and on secondary security reporting, not on ServiceNow's own advisory, which we could not read directly. Confirm patch levels against the vendor's article before acting.

What the flaw is

According to the CSA's summary of the original research, the bug sits in a pre-authentication endpoint, /assessment_thanks.do. A request parameter, sysparm_assessable_type, is evaluated as a filter expression inside a sandbox, and a chain of JavaScript tricks lets an attacker get code evaluated in a context the platform treats as trusted. No credentials, phishing or prior foothold is needed.

The impact described comes from the researchers' proof of concept: reading or changing data in any table, creating new administrator accounts (which can survive patching), and running commands on connected on-premises MID Server proxies. The CSA note is explicit that it does not confirm in-the-wild attackers achieved those outcomes.

The timeline

As reported by the CSA note:

• Early April 2026: Searchlight Cyber reports the flaw to ServiceNow.
• April: ServiceNow pushes restrictions to cloud-hosted instances within roughly a day of the report.
• Through June: patches reach self-hosted and partner-hosted customers.
• July 13: public disclosure, with fixes for hosted and self-hosted instances.
• July 17: the threat-intelligence firm Defused first sees exploitation attempts, four days after disclosure, followed by a wider wave over the weekend of July 18–19.

The CSA says attackers used a different technical path from the published proof of concept. It offers independent rediscovery as one explanation but does not rule out partial leakage of the original research, and it doesn't pick one.

Where the sources disagree

• Was it exploited? Defused says yes, and the CSA agrees. ServiceNow, according to some reporting, said it was aware of the publication about exploitation, and one report quotes it as seeing no evidence of exploitation in the wild. No source we read cites a confirmed customer compromise.
• How bad is it? Most sources give a CVSS score of 9.5. One aggregator lists 9.8 for a different scoring source.
• Which versions are fixed? Lists differ between sources. The CSA note names Brazil, Australia Patch 2, Zurich Patch 7b and Patch 9, and Yokohama Patch 12 Hot Fix 1b and Patch 13. Other write-ups word it differently. This is why you need the vendor's article for your release line.
• Start dates. One advisory lists April as a "first seen" date, which matches the disclosure timeline, not exploitation. Treat the July 17 date as the first reported attacks.

Related fixes

A separate sandbox escape, CVE-2026-6876, was rated high and affects the Now Platform. ServiceNow also reportedly published fixes for several more critical code-injection and SQL-injection flaws on August 27. That detail comes from a relayed news report that says it hasn't been independently verified, and no exploitation was reported for those. We mention them because the pattern matters more than any one CVE: a platform this central gets patched repeatedly, so patching has to be a routine.

What to check

The CSA's recommended steps, which are sensible regardless of your release:

1. Apply the fixed release for your product family as an emergency change if you run self-hosted or partner-hosted instances.
2. Enable Guarded Script, which limits untrusted filter input to simple expressions (the CSA cites ServiceNow knowledge article KB2944435).
3. Search your logs for requests to /assessment_thanks.do where sysparm_assessable_type contains javascript:, Object.defineProperty or gs.include. Treat a match as a likely compromise.
4. Audit for persistence: new admin accounts, unexpected scheduled jobs or script includes, odd outbound connections, and MID Server command logs.
5. If you can't patch right away, restrict network access to the pre-authentication endpoints as a stopgap.

The bigger lesson is the same one we drew from the GitLab AI Gateway sandbox escape: when a platform lets users or AI features run scripts, the sandbox becomes the security boundary, and it's a hard one to get right.

Why this keeps catching teams out

Applying the patch is a single change. The slow part is everything around it: finding every instance, knowing which release line each is on, searching logs for the patterns above, and noticing an admin account nobody remembers creating. On a platform that touches IT, HR and security workflows, that work usually has no clear owner, so it waits until an advisory forces it.

At TechScripts Nepal we help teams turn that into a routine: a current inventory of what's exposed, an access review, and a patching process that a small team can keep up. When extra hands are needed, one of our engineers can work inside your team on the remediation (how that works). If you'd like a second pair of eyes on your environment, tell us about it.