ServiceNow CVE-2026-6875 turns AI workflow platforms into urgent patch targets

ServiceNow's July security advisory for CVE-2026-6875 has moved quickly from "critical patch" to "assume the window is closing." The flaw affects the ServiceNow AI Platform and can allow an unauthenticated attacker, under certain conditions, to execute code inside the platform. Independent threat reporting now says exploitation attempts were observed within days of public technical disclosure.

That combination matters because ServiceNow is not a small side application in many enterprises. It often sits at the center of IT service management, incident workflows, change approvals, asset records, employee services, integrations, automation logic, and increasingly AI-enabled workflow execution. A serious remote code execution issue in that layer should be treated as a business workflow exposure, not just another application server patch.

ServiceNow says it addressed the issue for hosted instances and provided relevant updates for self-hosted customers and partners. The key defender question is no longer whether the CVE is interesting. It is whether every affected instance, integration path, and self-hosted environment has clear patch evidence.

What happened

ServiceNow published KB3137947 on July 13, 2026 for CVE-2026-6875, describing a critical sandbox escape in the ServiceNow AI Platform. The advisory says the issue could let an unauthenticated user execute code within the ServiceNow platform in certain circumstances.

The fixed releases listed by ServiceNow include:

• Brazil EA and Brazil GA
• Australia Patch 2
• Zurich Patch 7b and Zurich Patch 9
• Yokohama Patch 12 Hot Fix 1b and Yokohama Patch 13

NVD records the same core impact: ServiceNow addressed a remote code execution vulnerability in the AI Platform, with updates deployed for hosted instances and made available to self-hosted customers and partners.

Public reporting then raised the urgency. Help Net Security, BleepingComputer, The Hacker News, and SecurityWeek all reported that threat intelligence firm Defused observed in-the-wild exploitation activity after Searchlight Cyber published technical details. ServiceNow told multiple outlets that, based on its investigation at the time, it had not observed evidence that the activity related to ServiceNow-hosted instances.

That distinction is important. It does not make the vulnerability harmless. It narrows the immediate risk conversation toward self-hosted, partner-managed, unusually exposed, or not-yet-updated environments, while still requiring hosted customers to verify patch status and review logs where appropriate.

Why this is different from a normal SaaS patch

Many SaaS vulnerabilities are handled almost entirely by the vendor. The customer watches the advisory, confirms the vendor has remediated the hosted service, and reviews any tenant-specific guidance.

CVE-2026-6875 is messier because ServiceNow explicitly references both hosted updates and updates for self-hosted customers and partners. That creates two operational tracks:

• hosted instances where ServiceNow has deployed fixes
• self-hosted or partner-managed instances where administrators must confirm the relevant patch level

The second track is where timing becomes dangerous. Once public research, proof-of-concept behavior, or observed exploit traffic exists, attackers can begin scanning for lagging environments. For a platform used to coordinate work across security, IT, HR, finance, and operations, that is not a routine patch queue item.

This is a vulnerability that belongs in an exposure-driven response model. Teams should ask which instances are reachable, which are self-hosted, which are integrated with internal services, which hold privileged workflow data, and which proxy or MID Server style components could become part of the blast radius.

The technical issue in plain English

The vendor describes the issue as a sandbox escape. In practical terms, a sandbox is supposed to limit what code can do. Platforms that allow workflow automation, scripting, AI-assisted actions, or custom logic often need some controlled execution environment. The security boundary is supposed to prevent untrusted or low-trust code from reaching broader platform capabilities.

With CVE-2026-6875, the concern is that an unauthenticated attacker can reach a path that results in code execution inside the ServiceNow platform. Public reporting has associated observed activity with a pre-authentication endpoint and with a sandbox escape technique disclosed by researchers.

For defenders, the useful mental model is:

• the attack does not start with stolen credentials
• the target is the platform's server-side execution surface
• successful exploitation can move from a narrow request path into broader platform code execution
• the value of the compromise depends on what the instance can see and do

This is not an "AI prompt jailbreak" story. The AI relevance comes from where the vulnerability sits: inside a platform increasingly used to bind AI features to enterprise workflow data, automation, approvals, records, and integrations. A platform compromise could expose traditional ITSM data and AI-enabled workflow context at the same time.

What defenders should verify first

The first priority is patch evidence. Do not rely on assumptions such as "ServiceNow is SaaS, so we are covered" if the organization operates self-hosted, partner-managed, cloned, test, development, or unusual integration environments.

Security and platform teams should confirm:

• every production instance is on a fixed release
• self-hosted environments received the relevant update
• non-production instances are not internet reachable with old code
• partner-managed deployments have written remediation confirmation
• public exposure paths are known and intentional
• integration components connected to the platform are inventoried

Patch confirmation should include the exact release family and fixed version, not just a ticket that says "ServiceNow patched."

Hunt for signs of access, not just exploit strings

Because public reporting includes endpoint and payload details, it may be tempting to search only for exact proof-of-concept indicators. That is a useful first pass, but it is not enough.

The safer incident response approach is to look for suspicious behavior around the vulnerable time window and around the platform functions an attacker would value after code execution.

Useful review areas include:

• unusual requests to pre-authentication endpoints
• abnormal errors or script execution failures
• unexpected administrative account, role, or group changes
• suspicious modifications to workflow logic, scripts, business rules, or integrations
• unusual outbound connections from ServiceNow-related infrastructure
• changes to proxy, connector, or MID Server behavior
• new records, scheduled jobs, or automation rules created outside normal change windows

If exploitation is suspected, defenders should preserve logs before cleanup. Platform logs, reverse proxy logs, WAF logs, identity logs, and network telemetry may each hold part of the timeline.

Why connected systems matter

ServiceNow often has reach far beyond its own application boundary. It may integrate with identity providers, email systems, ticketing automations, cloud APIs, CMDB records, endpoint tools, vulnerability scanners, SIEM workflows, software deployment systems, and approval chains.

That means a compromised instance may be useful even if attackers cannot immediately execute operating system commands on every connected system. They may still be able to read sensitive workflow data, trigger automations, modify records, understand internal topology, or identify credentials and tokens stored for integrations.

This is where exposure management and patch management need to work together. The most urgent instances are not necessarily the biggest ones. They are the ones that combine affected code, reachable request paths, sensitive workflow authority, and privileged integrations.

Hosted customers still have work to do

ServiceNow's statement that it has not observed evidence tied to ServiceNow-hosted instances should reduce speculation, but it should not create passivity.

Hosted customers should still:

• confirm their instance family and patch level
• read ServiceNow's advisory and any tenant-specific guidance
• review whether any unsupported customizations or scripts require attention
• check whether security controls saw probing or blocked traffic
• document the remediation state for audit and executive reporting

For regulated teams, the record of response matters. A concise note that identifies the CVE, affected platform, vendor fix status, local exposure review, and log review outcome is often as important as the patch itself.

Executive takeaway

CVE-2026-6875 is a sharp example of how enterprise AI adoption changes vulnerability priority. The issue is not that an AI model was tricked into saying something unsafe. The issue is that AI-enabled workflow platforms are becoming powerful execution and integration layers. When one of those layers has a critical pre-authentication code execution path, the response needs to include platform owners, security operations, identity teams, and business process owners.

Treat the advisory as a priority validation exercise:

• prove the fixed version
• identify every self-hosted or partner-managed instance
• review exposure and logs
• assess connected workflow blast radius
• keep exact evidence for the remediation record

The teams that moved when ServiceNow published fixes are in the best position. The teams that wait for exploitation to become perfectly attributed may be giving attackers the simpler timeline.

What is CVE-2026-6875?

CVE-2026-6875 is a critical ServiceNow AI Platform sandbox escape that can allow unauthenticated code execution within the platform under certain circumstances.

Is CVE-2026-6875 being exploited?

Several security news outlets reported that Defused observed in-the-wild exploitation activity after public technical disclosure. ServiceNow told reporters that, based on its investigation at the time, it had not observed evidence related to ServiceNow-hosted instances.

Which ServiceNow versions are fixed?

ServiceNow lists fixed releases including Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b, and Yokohama Patch 13.

Does this affect only self-hosted instances?

No public summary should reduce it to only self-hosted systems. ServiceNow says hosted instances received deployed updates and self-hosted customers and partners received relevant updates. The highest uncertainty and customer action burden is typically around self-hosted, partner-managed, non-production, or unusually exposed environments.

What should defenders do now?

Confirm patch level, identify all ServiceNow instances, verify self-hosted and partner-managed updates, review exposure, preserve and examine logs, and assess connected systems that could expand the impact of a platform compromise.

References

1. CVE-2026-6875 - Sandbox Escape in ServiceNow AI Platform
2. NVD: CVE-2026-6875
3. Exploitation of ServiceNow Vulnerability Seen Days After Disclosure
4. ServiceNow pre-auth RCE exploited in the wild (CVE-2026-6875)
5. Critical ServiceNow AI Platform Flaw Exploited for Unauthenticated Code Execution
6. Critical ServiceNow code execution flaw now exploited in attacks