A recent advisory with a specific version list
On September 25, 2026, the Canadian Centre for Cyber Security published advisory AV26-963 about vulnerabilities in ServiceNow AI Platform. Its practical scope is clear: administrators and security teams should identify their instance version and compare it with the fixed levels listed by the vendor. The Canadian agency’s advisory refers to information current as of September 24. It does not, by itself, confirm that any particular instance is exposed or has been compromised.
The alert is useful because it distinguishes the platform’s commercial name from the affected version branches. It is not enough to know that an organization uses ServiceNow, or that its environment belongs to a recent family: the branch and applied patch must be checked. The operational decision depends on that comparison, and organizations using hosted, self-managed, or third-party-administered environments should confirm who applies the update and how that work is verified. Version labels can look similar while referring to different maintenance paths, so the comparison needs to use the exact branch and hot fix shown for the instance. Keep the advisory’s date in mind as well: it describes what was known at that point, rather than making a claim about every later development.
Which branches to compare against the patches
The advisory lists versions earlier than three Australia levels: Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3, and Patch 5. For Yokohama, it sets Yokohama Patch 13 Hot Fix 5a as the threshold. For Zurich, it gives three separate references: Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32, and Patch 11 Hot Fix 3. The wording “earlier than” means administrators need to compare the exact version with the relevant threshold, rather than assume that every installation in the same family is fixed.
An important qualification is that the advisory does not provide a single patch number for every branch. Zurich also has several listed update paths, so do not turn the list into a simplified rule such as “install the highest patch.” The starting version, maintenance schedule, and service model may affect the appropriate route. If the internal inventory cannot establish the branch and hot fix with confidence, ask the responsible administrator or vendor support to confirm them. Record which threshold applies to each environment and how that conclusion was reached; a generic product-family label is not a substitute for this verification.
Five CVE identifiers, but not five complete technical accounts
The Italian CSIRT of Tuscany alert, which refers to the ServiceNow bulletin, lists five identifiers: CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860, and CVE-2026-13016. It also characterizes the group as two critical and three high-severity flaws. This helps explain that the version list relates to multiple vulnerabilities, but it does not replace reading the technical advisory for each CVE or establish by itself whether a particular configuration is exposed.
Among the records accessible during this review, CVE-2026-86857 is described as an authorization issue that could allow an authenticated person to access AI Platform data they are not authorized to see. CVE-2026-86859 is described as an authorization issue that could allow unauthenticated access to data. These examples show why access control and information exposure matter; they do not justify assigning the same details to the other three identifiers. Do not infer specific techniques, conditions, or consequences for every CVE from the advisory’s combined list. The severity summary and identifier list provide useful orientation, but are not a substitute for the technical description and applicability information for each individual issue.
What is known about exploitation and scope
In the CVE-2026-86857 record description, ServiceNow says it deployed an update to hosted instances and provided the update to partners and self-managed customers. The same text says the company was not aware of malicious exploitation against ServiceNow instances when the record was published. That statement must retain its time-bound scope: it describes what the provider knew then, does not prove that exploitation never occurred, and does not guarantee that no later information will emerge.
The Canadian advisory lists the product and versions, but reports no specific incidents at customer organizations and does not establish how many instances might be affected. “Vulnerability published” must not be confused with “confirmed intrusion.” Assessing a particular case requires information from the instance itself, logs, and confirmation from the provider; the sources reviewed do not support a claim that these flaws are under active exploitation. Organizations should therefore avoid treating either the absence of a reported incident or a general product notice as a conclusive assessment of their own environment.
Checklist for operations and security teams
First, identify the service model and who is responsible for maintaining it. If ServiceNow hosts the instance, request confirmation that the relevant update was applied to that environment and record the response and date. If the installation is self-managed or maintained by a partner, compare the exact branch and patch level with the advisory list, then coordinate the update according to ServiceNow’s instructions. The public notice recommends reviewing the links provided and applying the necessary updates; it does not give a universal console procedure that can be assumed to work for every deployment.
Next, document the evidence of closure: branch, patch or hot fix, application date, and person responsible for validation. If the organization has several environments—for example, production, test, or instances separated by business unit—check each one rather than extrapolating the status of one installation to the others. Treat any version that appears earlier than the relevant thresholds as unresolved until support confirms the mitigation path. If a version already meets the stated level, retain evidence of the comparison; do not automatically interpret that as a complete assessment of other risks or configurations. A dated record also makes later review easier if maintenance responsibility or the hosting arrangement changes.
The key fact is the exact version, not an assumption
The verifiable conclusion as of September 26, 2026, is limited: the Canadian Centre for Cyber Security published an alert about ServiceNow AI Platform with specific branches and patch levels; a CSIRT summary lists five CVEs; and the records reviewed describe two of them as authorization and data-access issues. For administrators, the reasonable action is to compare each instance’s exact level with the list, confirm coverage with ServiceNow where appropriate, and apply the relevant updates according to the vendor bulletin.
There are informational limits. The alert does not, by itself, detail the technical components of all five CVEs, the separate effect of each one, or exploitation status across all instances. The absence of those details in the public advisory does not prove that they do not exist; it simply prevents asserting them here. Until the provider or technical records supply additional information, the priority is not to speculate about incidents, but to verify the patch status of every deployment and record the confirmation. Keep any later vendor clarification separate from the facts established by this notice, and reassess affected environments if the published thresholds or maintenance guidance change.