What Happened
ServiceNow patched CVE-2026-6875 on July 14, 2026 as part of a scheduled security release. By July 19 — five days later — threat intelligence firm Defused confirmed the vulnerability was being actively exploited in the wild.
CVE-2026-6875 affects self-hosted deployments of the ServiceNow AI Platform. It is a pre-authentication sandbox escape: an attacker without credentials sends a crafted request that breaks out of the platform’s sandboxed code execution environment and achieves remote code execution on the underlying host. The flaw carries a CVSS score of 9.5. Defused’s analysis went further, identifying a second gadget chain that reaches the same code-execution outcome through a different bypass route — meaning the single published proof of concept is not the only viable attack path. Both chains work without authentication.
ServiceNow is used as an ITSM, IT operations, HR, and security operations platform by thousands of large enterprises and government bodies globally. Self-hosted “on-premise” or private-cloud instances manage their own patching and are the installations at risk; ServiceNow-hosted instances were patched by the vendor. Sources: BleepingComputer / Help Net Security
Why This Matters for Canadian Organizations
ServiceNow is entrenched across Canadian enterprise and the public sector. Federal departments, major banks, insurance carriers, telecommunications companies, and large healthcare systems rely on it to manage IT service requests, security incidents, HR workflows, and asset inventories. Many operate self-hosted or private-cloud instances to meet data residency requirements — precisely the installations that needed to apply the July 14 patch themselves and are now exposed if they have not done so.
The stakes are unusually high. A self-hosted ServiceNow instance does not merely contain ticketing data. It frequently holds employee personal information, security vulnerability disclosures, third-party vendor access records, hardware inventory, network topology, and active incident details. In a financial institution context, exploitation of a ServiceNow server gives attackers a map of the organization’s IT environment and potentially access to sensitive audit trails. Under OSFI B-13, Canadian federally regulated financial institutions are required to report technology and cyber incidents to OSFI within prescribed timelines. Under PIPEDA, any breach involving unauthorized access to personal information triggers notification obligations. An attacker who achieves RCE on a ServiceNow host before patches are applied would have access to data triggering both obligations.
The five-day gap between patch and confirmed exploitation is shorter than many enterprise patch cycles. Security teams following a 30-day or even 14-day patch SLA for ITSM platforms are behind.
What to Do
If your organization operates a self-hosted or private-cloud ServiceNow AI Platform instance, confirm immediately whether the July 14 patch has been applied. If it has not, treat this as an emergency change requiring same-day deployment. Verify with your ServiceNow administrator that both the primary fix and any supplementary patches listed in ServiceNow’s security bulletin are installed — Defused’s discovery of a second exploit gadget chain suggests the published CVE does not cover the full attack surface.
Review ServiceNow application and access logs from July 14 onward for anomalous pre-authentication requests, unexpected code execution events, new API integrations, or changes to administrator accounts. If you have not previously scoped which users and systems have access to your ServiceNow instance from outside your network perimeter, do so now and restrict internet-facing exposure to the minimum necessary. Canadian organizations subject to OSFI B-13 should consult their incident response procedures to determine whether confirmed exploitation activity in the broader ecosystem triggers a precautionary notification obligation even in the absence of a confirmed breach at their own instance.
