On 13 July 2026, ServiceNow publicly disclosed CVE-2026-6875, a critical code injection vulnerability in the ServiceNow AI Platform that allows an unauthenticated attacker to escape the platform’s script sandbox and execute code remotely against a targeted instance. On 18 July, researchers observed the first in-the-wild exploitation attempts — five days after the disclosure and the availability of patches for self-hosted instances.

The vulnerability was found by researchers at Searchlight Cyber and reported to ServiceNow in early April 2026. CISA’s ADP enrichment classifies it as CWE-94, Improper Control of Generation of Code. ServiceNow pushed a security update to its hosted instances the day after public disclosure and made patches and security updates available to self-hosted customers and partners through June, culminating in the 13 July patch release (KB3137947) that self-hosted and partner-hosted customers must apply manually.

That last clause is the entire story. The population under active attack is not “ServiceNow customers.” It is the subset who own their own patch cycle and did not complete it inside a five-day window.

What an attacker gets

The technical impact here is close to maximal, and the reason is architectural rather than incidental.

ServiceNow runs customer-authored server-side scripts inside a restricted sandbox. That sandbox is the boundary between “a low-privilege user can automate a workflow” and “a low-privilege user can run arbitrary code against the platform.” CVE-2026-6875 breaks the boundary without requiring any authentication at all.

With unsandboxed execution on the instance, an attacker can:

  • Read and write any table. In a typical enterprise deployment that includes the CMDB, incident and change records, HR case data, procurement records, and any custom application built on the platform.
  • Create administrator accounts, converting a single exploitation event into durable access that survives the patch.
  • Issue commands to connected MID Servers. This is the pivot that turns a SaaS compromise into an internal-network compromise. MID Servers are the on-premises proxies that ServiceNow uses to reach systems behind the customer firewall for discovery, orchestration, and integration. They are, by design, trusted by the internal network and trusted by the instance. An attacker with instance-level code execution inherits that trust relationship.

Full compromise of the instance and of any connected proxy servers is the accurate description of the ceiling.

Why ITSM platforms are a disproportionate target

Security programmes routinely classify ServiceNow as a business application rather than as security infrastructure. That classification is wrong, and this CVE demonstrates why.

The CMDB is a map of the estate. An attacker who reads the configuration management database obtains an authoritative, curated, current inventory of the target’s servers, applications, owners, dependencies, and — frequently — their criticality ratings. This is reconnaissance that would otherwise take weeks, delivered pre-organised.

Change records describe upcoming maintenance windows. They tell an attacker when systems will be down, when monitoring may be relaxed, and when anomalous activity is expected.

Integration credentials accumulate. ITSM platforms hold service accounts for Active Directory, cloud providers, monitoring tools, endpoint management, and ticketing integrations. They are a credential vault that nobody classifies as a credential vault.

Support tickets contain the data users paste into them. As the parallel Ernst & Young support-ticket breach demonstrated in the same month, a ticketing system’s real data classification is determined by what users attach to tickets, not by what the system was designed to hold.

Workflow automation has write access to everything. The value of an orchestration platform is that it can act on other systems. Compromise of the orchestrator is compromise of the orchestrated.

The compliance obligations this triggers

Vulnerability remediation timelines

Nearly every framework an enterprise is measured against now specifies remediation windows for critical vulnerabilities:

  • PCI DSS 4.0 Requirement 6.3.3 requires critical or high-security patches to be installed within one month of release, with a risk-based approach for others.
  • HIPAA Security Rule § 164.308(a)(1)(ii)(B) requires security measures sufficient to reduce risks to a reasonable and appropriate level; the proposed Security Rule overhaul would make patching timelines explicit rather than inferred.
  • CISA BOD 22-01 requires federal civilian agencies to remediate KEV-listed vulnerabilities within specified deadlines, and the KEV catalogue has become the de facto private-sector prioritisation list.
  • NIS2 Article 21 requires essential and important entities to have policies for vulnerability handling and disclosure, with management-level accountability.
  • DORA Article 9 requires financial entities to have mechanisms to promptly detect anomalous activities and to identify and remediate ICT vulnerabilities.

A five-day exploitation window is shorter than every one of those formal timelines. Which means compliance with the letter of the framework and protection against this specific attack are not the same thing — the framework sets a floor, and the floor is below the threat.

Incident reporting

If exploitation occurred before patching, the reporting obligations stack quickly:

  • SEC Item 1.05 Form 8-K within four business days of a materiality determination for public companies.
  • GDPR Article 33 notification within 72 hours where personal data was accessible — and in a ServiceNow instance holding HR cases, it almost certainly was.
  • HIPAA Breach Notification Rule where ePHI is present.
  • CIRCIA covered-entity reporting once the final rule’s timelines are operative, per our CIRCIA analysis.
  • NIS2 Article 23 early warning within 24 hours and incident notification within 72 hours for in-scope EU entities.

The materiality determination for an ITSM compromise is genuinely difficult, because the affected data spans every business function. Organisations should not attempt that assessment for the first time under a four-day clock.

The hosted/self-hosted split is a governance question

ServiceNow patched its hosted instances within a day. Self-hosted and partner-hosted customers had to act themselves, and those are the instances where active exploitation attempts have been observed.

This split recurs across the SaaS estate and it is systematically mismanaged. The common failure mode is that the vendor’s rapid response to its own multi-tenant environment creates an organisational impression that “the vendor handles patching” — an impression that is correct for the majority of instances and catastrophically wrong for the minority that are self-hosted, partner-hosted, air-gapped, or maintained on an older release for compatibility reasons.

Three governance corrections follow:

Maintain a deployment-model inventory, not just a vendor inventory. For every significant SaaS platform, record explicitly whether each instance is vendor-hosted, partner-hosted, or self-hosted, and who holds the patching obligation in writing. Production, UAT, development, and that one instance a business unit stood up for a pilot in 2023 may have different answers.

Treat partner-hosted as self-hosted for planning purposes. A managed service provider running your instance introduces a notification and action dependency you do not control. Contractual patch SLAs for critical vulnerabilities should be specified in hours.

Subscribe to the vendor’s security advisory channel directly. Relying on general threat intelligence feeds to learn about your own platform’s critical CVEs introduces a delay you cannot afford when the exploitation window is five days.

Immediate actions

Confirm patch state, do not assume it. Verify KB3137947 application on every instance including non-production. Non-production ServiceNow instances routinely contain production data copies and are frequently more exposed.

Hunt before you conclude you are clear. Patching closes the door; it does not evict anyone already inside. Look specifically for: newly created accounts with elevated roles, unexpected modifications to script includes and business rules, anomalous MID Server command execution, unexplained outbound connections from MID Server hosts, and bulk table exports.

Rotate MID Server and integration credentials if there is any indication of exploitation, and review the privilege level those service accounts hold on internal systems. Most are over-privileged relative to their actual function.

Restrict instance exposure. Where business requirements permit, IP-allowlist administrative and API access. Pre-auth vulnerabilities are only reachable by parties who can reach the endpoint.

Document the timeline. Record when the advisory was received, when the risk assessment was performed, when patching completed, and what hunting was done. If a regulator or auditor asks about this CVE — and for regulated entities, they will — that record is the difference between a demonstrated process and an assertion.

Conclusion

CVE-2026-6875 is not remarkable as a vulnerability class. Sandbox escapes leading to unauthenticated code execution appear several times a year across the enterprise software estate. What makes it worth studying is the compression: reported in April, disclosed 13 July, exploited 18 July.

That five-day interval is now a realistic planning assumption for critical, pre-authentication flaws in widely deployed platforms. Any remediation process that requires a change advisory board meeting, a two-week testing cycle, and a scheduled maintenance window cannot meet it. Organisations need a documented emergency path for this specific scenario — one that is exercised, authorised in advance, and does not depend on the availability of any single individual.

The organisations breached through this vulnerability will not be the ones that lacked a patching policy. They will be the ones whose patching policy assumed a month.

This article is provided for informational purposes only and does not constitute legal advice.