What happened
On August 27, 2026, ServiceNow issued an advisory covering three maximum-severity AI Platform vulnerabilities and one high-severity Now Platform vulnerability. On August 28, 2026, the Canadian Centre for Cyber Security published AV26-857 and directed administrators to review affected releases and apply updates. CVE-2026-18885 is code injection, CVE-2026-18886 is improper access control enabling privilege escalation, and CVE-2026-74820 is SQL injection; each received a CVSS 4.0 score of 10.0. CVE-2026-6876 is an 8.7 sandbox escape affecting the Now Platform.
The cited fixed releases are Xanadu Patch 11 Hot Fix 7a; Yokohama Patch 12 Hot Fix 3b or Patch 13 Hot Fix 4; Zurich Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m, Patch 10 Hot Fix 3, Patch 11 or Patch 12; and Australia Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 or Patch 5, according to the active branch. ServiceNow said it was not aware of malicious exploitation against ServiceNow instances at the publication cutoff. The cited sources did not publish exploit indicators, malicious infrastructure or product-specific detection signatures.
ServiceNow AI Platform; no specific AI agent framework was identified in cited sources. No underlying model or version was identified in cited sources. No operator-configured agent action was identified; the issue is vulnerable platform logic. The vulnerable platform logic could permit unauthenticated code execution, privilege escalation or SQL statements. Attribution posture: The cited sources identify no exploiting actor because malicious exploitation had not been reported.
Why this matters now
ServiceNow is frequently treated as a business workflow service rather than a privileged control plane. In practice, instances can hold configuration data, service-management records, security cases and integration authority across cloud, identity, human-resources and infrastructure systems. An unauthenticated path to code execution or database modification therefore creates consequence beyond the platform’s own data.
The remediation responsibility differs materially by operating model. ServiceNow said it updated hosted instances and supplied updates to partners and self-hosted customers. A hosted customer needs evidence of vendor-side application and tenant coverage; a self-hosted customer must establish its exact release branch and install the relevant update. A generic statement that ServiceNow is patched does not distinguish those obligations.
No active exploitation was reported for these three maximum-severity vulnerabilities at the cutoff. That lowers the basis for declaring an incident but does not justify routine scheduling. The unauthenticated, low-complexity access conditions and the platform’s integration reach compress the patch horizon while still requiring evidence-based prioritisation.
The decision for security leaders
Require one owner to reconcile contract records, configuration management data and ServiceNow administration records into a deployment map. The key decision is who applied the update and what evidence proves it for each production, development, acquired and partner-operated instance.
For self-hosted systems, approve an accelerated change window against the exact active release branch. For hosted systems, obtain a vendor or partner assurance that identifies the tenant, update status and any exceptions. Do not treat a cloud service’s general update statement as tenant-specific evidence.
Review the platform as a privileged integration hub. Identify service accounts, OAuth grants, API credentials and orchestration permissions reachable from the instance. Where business need does not justify standing authority, reduce it independently of the vulnerability patch.
Evidence of closure
- A deployment map identifies hosting model and owner for every ServiceNow instance.
- Release evidence matches each self-hosted instance to its applicable fixed branch.
- Written provider assurance confirms update status for each hosted tenant.
- Telemetry review records an approved disposition and its evidence limitations.
The Security.io assessment
This brief is included because Friday’s authority notice put three independent, unauthenticated maximum-severity flaws into an enterprise workflow and AI control plane. There was no reported exploitation, so it ranks below the confirmed PaperCut activity and weekend incidents. It still warrants immediate ownership decisions because hosted and self-hosted customers have materially different remediation obligations.
The AI label should not distort the assessment. The cited evidence describes vulnerable application logic in the ServiceNow AI Platform; it does not show an AI model choosing or executing an attack. The relevant control question is whether unauthenticated requests can reach privileged platform functions and whether the organisation can prove the applicable update was installed.
Without published indicators, retrospective review must be behaviour-led: unexpected code execution, unusual web requests, abnormal database errors, unexplained data changes and new outbound connections. A clean review lowers concern but cannot provide mathematical proof of non-exploitation. The closure package should state telemetry limits and retention gaps explicitly.
Questions for the morning meeting
- Can the organisation distinguish ServiceNow-hosted, partner-hosted and self-hosted instances?
- Which integrations and secrets would be reachable from a compromised ServiceNow instance?
- Has each self-hosted branch reached its applicable fixed patch level?
- What evidence confirms vendor-managed instances received the security update?