September 2026 ServiceNow AI Platform CVE Batch (CVE-2026-13016, CVE-2026-86857 to CVE-2026-86860)

Your instance is affected if it runs Yokohama, Zurich or Australia below the patch levels ServiceNow published on 24 September 2026. Five CVEs landed in one batch, all in the ServiceNow AI Platform, and four of the five need no login at all. The most severe is an unauthenticated SQL injection. One patch closes all five, so the only question worth answering is which build your instance is on.

What This Is

On 24 September 2026, ServiceNow published five CVEs against the ServiceNow AI Platform, remediated together and shipped in a single set of patch levels. Each was found through internal security testing, customer security assessments, or ServiceNow's responsible-disclosure and bug-bounty programmes. ServiceNow states it found no evidence of malicious exploitation for any of the five.

Scores, vectors and CWE assignments above are as published by ServiceNow as CNA on CVE.org and enriched by NVD — all publicly checkable against each CVE's record. The CVSS vectors separate capabilities that the one-line descriptions blur together. CVE-2026-86858 is scored VC:N/VI:H — confidentiality None, integrity High — so it is a write primitive, not a read one. CVE-2026-86859 is its mirror at VC:H/VI:N. Both score 8.7, and triaging this batch by score alone hides that they describe opposite abilities. CVE-2026-86860 scores SC:H/SI:H on the subsequent-system metrics, which is how ServiceNow's phrase "resulting in privilege escalation" is expressed numerically: the consequence is rated as reaching past the vulnerable component. CVE-2026-13016 keeps SC:N/SI:N but carries VC:H/VI:H/VA:H — full impact on the instance and its database.

Fixed-in patch levels, identical for all five CVEs:

Customers enrolled in the ServiceNow August Patching Program received Yokohama Patch 13 Hot Fix 5a, Zurich Patch 10 Hot Fix 4a W32, or Australia Patch 2 Hot Fix 4b W32 automatically. Xanadu and earlier receive no fix in this batch. Those families are out of support, which is not the same as being unaffected — no fixed version exists, so no version check can clear them.

Why This Is Dangerous

Four of the five require no credentials. An attacker does not need a stolen password, a guest account, or a self-registered portal user — only the instance URL, which is public by construction for any customer-facing ServiceNow deployment.

Attack Scenario 1 — Database-level compromise via CVE-2026-13016. An attacker who has never logged in executes SQL statements of their own choosing against the database behind the instance. This is scored VC:H/VI:H/VA:H: they can read any table, modify records, and affect availability. Platform ACLs are irrelevant here — ACL evaluation happens above the database, and an attacker executing statements directly has stepped underneath every control the platform offers. There is no role configuration, no ACL tightening, and no scoped-application boundary that contains this.

Attack Scenario 2 — Silent privilege escalation via CVE-2026-86860. An attacker reads instance data through a missing authorization check, and ServiceNow rates the outcome as privilege escalation reaching past the AI Platform itself. The data an attacker wants first is the data that buys authenticated access: user records, integration configuration, and anything a previous operator pasted into a record in plain text. A read-only flaw becomes a write-capable one the moment it yields a working credential.

Attack Scenario 3 — Data forgery via CVE-2026-86858. An unauthenticated attacker creates, modifies or deletes records. This is the scenario most likely to be missed during recovery, because the instinct after a disclosure is to ask "what did they read?" An integrity flaw inverts the question. A forged approval, an altered change record, or a silently deleted audit row is an attack that leaves the instance running normally and looking correct.

Attack Scenario 4 — Entitlement bypass via CVE-2026-86859 and CVE-2026-86857. Both let a caller reach AI Platform data they are not entitled to; CVE-2026-86859 needs no login, CVE-2026-86857 needs any login. On an instance with self-registration, a customer-facing portal, or a large contractor population, "any authenticated user" is a much larger set than it first sounds, and CVE-2026-86857's PR:L is a weaker barrier than it appears on the vector.

The AI Platform is the common surface. All five are in the same component. An organisation that has activated Now Assist, AI Search, or AI agents has enabled this surface; the batch is a statement about the concentration of risk in that component, not five unrelated coincidences.

How to Detect

There is no verified detection signal for these CVEs. No public indicator of compromise, no exploitation fingerprint, and no log pattern has been published or verified against a live instance for any of the five. Detection here means establishing your patch level against the advisory matrix — not hunting for exploitation you have no verified way to recognise. Searching transaction logs for "suspicious AI endpoint access" without a verified matcher produces false confidence in both directions.

Determine the instance release and patch level

/*
 * CVE-007 — September 2026 AI Platform CVE batch: patch-level verification
 * Reports the instance build so it can be compared against the advisory matrix.
 *
 * Run as: Background script with admin role
 * Impact: Read-only, safe for production
 */

var buildTag = gs.getProperty('glide.buildtag', '');
var buildDate = gs.getProperty('glide.builddate', '');
var war = gs.getProperty('glide.war', '');
var instanceName = gs.getProperty('instance_name', '');

gs.info('=== CVE-007: SEPTEMBER 2026 AI PLATFORM CVE BATCH ===');
gs.info('Instance:   ' + instanceName);
gs.info('Build tag:  ' + buildTag);
gs.info('Build date: ' + buildDate);
gs.info('WAR:        ' + war);
gs.info('');

var tag = buildTag.toLowerCase();
var relFamily = 'Unknown';
if (tag.indexOf('yokohama') > -1) relFamily = 'Yokohama';
else if (tag.indexOf('zurich') > -1) relFamily = 'Zurich';
else if (tag.indexOf('australia') > -1) relFamily = 'Australia';
else if (tag.indexOf('xanadu') > -1) relFamily = 'Xanadu';

gs.info('Release family: ' + relFamily);
gs.info('');

if (relFamily == 'Xanadu' || relFamily == 'Unknown') {
    gs.info('NO FIX PUBLISHED for this release family in the September 2026 batch.');
    gs.info('Out of support is NOT the same as unaffected — treat as exposed and plan an upgrade.');
} else {
    gs.info('Compare the patch level in the build tag above against:');
    if (relFamily == 'Australia') {
        gs.info('  Australia: Patch 2 Hot Fix 4b W32 / Patch 4 Hot Fix 3 / Patch 5');
    } else if (relFamily == 'Zurich') {
        gs.info('  Zurich: Patch 10 Hot Fix 3b / Patch 10 Hot Fix 4a W32 / Patch 11 Hot Fix 3');
    } else {
        gs.info('  Yokohama: Patch 13 Hot Fix 5a');
    }
    gs.info('At or above the listed level for your branch = patched for all five CVEs.');
}

glide.buildtag carries the release name and patch level together (for example glide-zurich-07-01-2025__patch6-01-16-2026), which is why it is the property to trust. glide.builddate is a timestamp and does not reliably identify a patch level — two instances on different patches can share a build date, so a date comparison is not a substitute for reading the tag.

Confirm the upgrade actually landed

Re-read the build tag after the patch window closes, using the script above. A stalled, rolled-back or partially-applied upgrade leaves the previous build serving while the change record says the work is finished, and the build tag is the only thing that reports what is actually running. Cross-check it against System Diagnostics → Upgrade History in the platform UI for the completion state of the most recent upgrade.

Do not accept a change record, a maintenance-window confirmation, or a vendor notification as evidence of patch level. Each of those says what was intended; the build tag says what is serving.

Remediation

1. Read your build tag and compare it to the matrix above. Use the first script, or System Diagnostics → Stats. This is the whole determination — patched or not patched — and it takes a minute. Do it before anything else on this list.

   Mitigates: All four scenarios — establishes whether any of them currently apply to this instance.

2. Hosted (SaaS) instances: confirm, do not assume. ServiceNow patched hosted instances itself, but confirmation is a build-tag read, not a trust exercise. An instance pinned to an older patch branch for change-freeze reasons may not have received it.

   Mitigates: All four scenarios — but only once the build is actually confirmed. An assumed patch mitigates nothing.

3. Self-hosted and partner-managed instances: apply the patch or upgrade now. This is where the real exposure sits. Self-hosted customers historically lag hosted deployment by days to weeks, and that gap is the residual risk window for four unauthenticated flaws.

   Mitigates: All four scenarios — this is the only step that removes the vulnerabilities rather than containing them.

4. If you cannot patch within 24–48 hours, restrict network reachability. Limit public access to the instance at the WAF or perimeter until the patch lands. This is containment, not a fix: it narrows who can reach the flaw, and does nothing about who already could.

   Mitigates: Attack Scenario 1 (Database-level compromise) and Attack Scenario 4 (Entitlement bypass) — it narrows external reachability but does nothing about authenticated users who retain access through the allowed path. CVE-2026-86857 needs only a login, and a self-registered portal user or a compromised contractor SSO session is an external attacker holding a valid one.

5. Check the upgrade completed. Run the second detection script. A stalled or rolled-back upgrade leaves the previous build serving while the change record says the work is done.

   Mitigates: All four scenarios — a patch that did not land is indistinguishable from one that was never applied, except on paper.

6. After patching, reason about integrity, not just confidentiality. CVE-2026-86858 permits unauthenticated creation, modification and deletion. If you are assessing a possible pre-patch exposure window, review records created or modified in that window — approvals, change records, and role grants especially — rather than only asking what might have been read.

   Mitigates: Attack Scenario 3 (Data forgery) — patching stops further writes but does not identify or reverse writes that already happened.

7. Treat credential rotation as a decision, not a reflex. CVE-2026-86860 and CVE-2026-86859 are read primitives against AI Platform data. If your instance stores secrets where a read primitive could reach them, rotation is warranted; if it does not, rotation is churn. The prerequisite is knowing where secrets live — which is the Secrets and Credentials Stored in ServiceNow Records question, not this one.

   Mitigates: Attack Scenario 2 (Silent privilege escalation) — removes the value of anything an attacker may have read before the patch.

Do not go looking for a platform property that "requires authentication" globally as a workaround. No such toggle closes these flaws, and the property names that sound like one do not exist. Patching is the remediation.

Regulatory Impact

• NIS2 Art.21§2(e) — security in acquisition, development and maintenance, including vulnerability handling and disclosure. A five-CVE batch in one component is exactly the event this obligation is written for: the evidence expected is a documented patch decision with a date, not an assurance that patching happens generally.
• NIS2 Art.21§2(a) — risk analysis and information system security policies. Four unauthenticated flaws in the AI Platform are a reason to re-examine whether that component's exposure was represented accurately in the instance risk assessment.
• NIS2 Art.23§1 — incident notification. Notification obligations attach to a significant incident, not to a disclosed vulnerability. Establishing whether the window was exercised supports that determination; it does not make it.
• DORA Art.10§1 — detection of anomalous activities. There is no verified detection signal for these CVEs, and that absence is itself a finding worth recording: the control's coverage here is patch-level assurance, not detection.
• DORA Art.9§1 / Art.19§1 — ICT risk protection and prevention, and major-incident reporting. For financial entities, a confirmed exploitation affecting an in-scope instance may trigger reporting timelines; an unexploited exposure window ordinarily does not.
• ISO A.8.8 — management of technical vulnerabilities. The fixed-in matrix and the date your instance reached it are the audit artefacts.
• ISO A.8.3 — information access restriction. CWE-862 and CWE-284 are failures of exactly this control at the platform layer, below where your own access-restriction configuration operates.
• GDPR Art.32 / Art.33 — security of processing and breach notification. If personal data was reachable through the flaws and exploitation is confirmed, the 72-hour notification clock is a live question. Absent evidence of exploitation, the Art.32 question — was the patch applied in good time — is the one that applies.

Expert Notes

• The build tag is the answer; the build date is not. glide.builddate looks like a patch indicator and is not one — instances on different patch levels can share it. glide.buildtag carries release family and patch level in a single string, which is why every check in this article reads it. This distinction has caused real misclassification during previous advisories.

• Read the vectors, not just the scores. CVE-2026-86858 and CVE-2026-86859 both score 8.7 and describe opposite capabilities — one writes, one reads. A triage process that sorts by CVSS and stops will treat them as interchangeable. The VC/VI split is where the actual difference lives.

• "No evidence of malicious exploitation" is a statement about visibility. ServiceNow reports none, and there is no CISA KEV entry or public exploit for any of the five. The CVEs are days old. Absence of observed exploitation this early is weak evidence, and it is not a reason to defer patching — it is the expected state for a vulnerability nobody has had time to weaponise.

• Xanadu silence is not Xanadu safety. The advisory lists fixed-in versions for Yokohama, Zurich and Australia only. An instance on Xanadu or older cannot be cleared by any version check in this article, because no fixed version exists to compare against. The correct reading is "no fix published", and the correct response is an upgrade plan.

• The advisory reference is KB3159623, and it is login-gated. That is the article ServiceNow's own CVE Records cite, and it is the one to open first. ServiceNow also publishes batch notifications under separate article numbers, so if you arrive at a different one, that is normal rather than a sign either is wrong — cite the article you actually read, not the one someone else quoted.

• The AI Platform is now a patch-cadence problem, not a feature decision. Five CVEs in one batch, following two prior critical sandbox vulnerabilities, means the component's disclosure rate is high enough that "we will patch at the next scheduled window" is a different risk posture here than elsewhere on the platform. Organisations running AI Platform features should be on a patch branch that receives hot fixes, not one pinned for stability.