On Friday 18 July 2026 the first real exploitation attempts landed against CVE-2026-6875, a critical flaw in the ServiceNow AI Platform that lets an attacker run code on the instance with no credentials, no phishing and no prior foothold. What unsettles defenders is not only the severity —CVSS 9.5— but the clock: ServiceNow shipped the patch on 13 July and the attacks arrived five days later.
ServiceNow is one of the most widely deployed service-management platforms in large organisations. It underpins incident management, the configuration database (CMDB), process automation and AI-driven flows. When a flaw lets someone seize that platform from the outside, the attacker does not land on some isolated server: they land on the operational nervous system of the business, with visibility over tickets, configuration data and the integrations that connect the instance to the internal network. This article explains, from the defender's point of view, how the problem works, what traces it leaves and which concrete controls reduce the risk.
What CVE-2026-6875 is, and why it is this serious
The flaw is a sandbox escape in the platform's scripting layer. ServiceNow evaluates expressions and small code fragments inside a sandbox designed to keep that code away from the underlying system. The vulnerability breaks that boundary: by chaining primitives in the engine itself, an attacker gets the code to stop running inside the box and start running with the server's privileges.
What raises the stakes is that the entry point sits before authentication. The research that prompted the advisory —published by the Assetnote team at Searchlight Cyber under the title ‘Smashing the ServiceNow Sandbox’— identifies an endpoint reachable without a session that accepts user-controlled input. In other words, anyone with network access to the instance can reach the vulnerable point. There is no password and no second factor standing in the way.
ServiceNow acknowledges the scope of compromise in its KB3137947 advisory: reading data held in tables, creating administrator accounts and —this is what turns a cloud incident into an internal-network problem— the ability to run commands on connected MID Servers, the relay hosts the instance uses to talk to systems inside the corporate perimeter.
The timeline that matters: from research to attack
This is a textbook case of how quickly today's gap between ‘known’ and ‘attacked’ closes. The vulnerability was reported to ServiceNow in early April 2026. The advisory and patch went out on 13 July. The first exploitation attempts were seen on 18 July, five days later.
One nuance deserves emphasis: threat-intelligence firm Defused documented a second escape chain distinct from the public proof of concept. It matters because many improvised defences are tuned to the first known pattern; a variant that arrives by another route slips past them. Anyone who blocked only the initial PoC signature may be covering half the door.
Figures and facts you can check directly against the sources:
| Item | Value |
|---|---|
| Product | ServiceNow AI Platform |
| Type | Sandbox escape → unauthenticated RCE |
| CVSS | 9.5 (critical) |
| Initial report | Early April 2026 (Assetnote / Searchlight Cyber) |
| Patch and advisory | 13 July 2026 (KB3137947) |
| First exploitation | 18 July 2026 (5 days after patch) |
| Aggravating factor | Second escape chain that evades PoC-tuned defences |
Sources: NVD, ServiceNow KB3137947, Help Net Security, SecurityWeek.
Why the usual controls fall short
Three factors defeat the traditional defensive recipe here. First, there is no authentication to break: the usual arsenal —MFA, password policy, brute-force detection— never comes into play because the attacker does not log in. Second, the implicit trust placed in the platform: ServiceNow is typically integrated deeply, with broad permissions and connections to directories, ticketing, email and, via the MID Server, the internal network itself. Compromising it is not taking an isolated server; it is inheriting its privileges. Third, the speed at which the attacker adapts. As the second escape chain shows, a WAF rule tuned to the first public pattern ages in hours.
Defence therefore cannot rest on a single signature; it has to lean on behavioural detection and on shrinking the exposed surface. Deciding well what to patch and in what order is exactly the kind of call a sound vulnerability programme should resolve with criteria such as KEV, EPSS and SSVC, which we covered in detail on the blog.
Detection: what it leaves behind and where to look
This is where the defender regains the advantage. However quiet the entry, it leaves observable traces if you are watching in the right place.
In the instance and edge logs:
- Anomalous requests to pre-authentication endpoints, in particular /assessment_thanks.do, the entry point documented in the public research.
- Unexpected creation of accounts with an administrator role, or sudden role changes on existing users.
- Unjustified changes to Script Includes, business rules or any object that runs server-side code.
- Bulk access to or extraction of table data outside the normal usage pattern.
On the MID Server hosts, which are the bridge to the internal network:
- Unexpected process creation on the MID Server host: a signal of command execution that warrants an immediate alert.
- Outbound connections from the MID Server to new or unusual destinations, a possible sign of lateral movement or exfiltration.
- Commands issued to the instance that match no approved automation.
Instrumenting the hosts that run MID Servers with EDR and correlating their events in the SIEM turns an invisible intrusion into an actionable alert. When the pattern fits no existing rule, proactive threat hunting is what closes the gap between what is known and what is already under way.
Practical defence: what to do this week
Order matters. These are the actions that cut exposure immediately, not a generic list of good intentions.
- Apply the ServiceNow patch (KB3137947) across every affected instance. That is the measure that shuts the door; the rest contains and verifies.
- Enable the ‘Guarded Script’ model ServiceNow introduced with the patch: it limits low-trust code to simple expressions and forces complex logic —variables, conditionals, loops, assignments— into controlled Script Includes.
- Review the instance's exposure: restricting network access to the admin panel and endpoints to known ranges and identities reduces who can even reach the vulnerable point.
- Segment and watch the MID Servers: least privilege on the service accounts they use, and network isolation so a compromise does not translate into free access to internal systems.
- Audit administrator accounts and roles created or changed since early July, and rotate credentials and integration tokens the instance holds.
- Assume possible compromise if the instance was exposed between 13 July and effective patching: trigger the incident response plan and hunt for persistence, not just the initial access.
The angle worth remembering: third-party risk
A ServiceNow compromise is not merely a technical problem; it is, by definition, an incident at a critical technology supplier. For many organisations the platform is the system from which IT operations are governed. That framing —third-party risk management— is what connects this case to the boardroom and to regulation. The underlying lesson is the same one left by the European Commission breach and one we keep documenting in our digital supply-chain lessons: the risk no longer lives only inside your perimeter, it lives in the platforms you depend on.
For entities in scope of NIS2, a significant incident in a system of this importance triggers notification duties —an early warning within the first 24 hours— and an impact assessment. Under DORA, ServiceNow fits as an ICT service provider: it should sit in the third-party register, with its dependencies mapped and a clear continuity plan should the platform fail or be compromised. And because the flaw lives in the platform's AI layer, it is also a reminder that AI security in the enterprise is not a future debate: it is attack surface today.
At a glance
CVE-2026-6875 is not just another line on the weekly list. It brings together the three ingredients that turn a vulnerability into a crisis: unauthenticated remote code execution, a platform sitting at the centre of operations, and active exploitation within days of the patch. The good news is that defence does not depend on guessing the next payload: patching, enabling Guarded Script, cutting exposure, watching the MID Servers and treating the case as what it is —a critical-supplier incident— covers what needs covering. The expensive part is not acting; it is discovering six weeks from now that the instance had been open since July.