al-ice.ai

ServiceNow Patched Five AI Platform Flaws — Four Need No Login at All

AI Vulnerabilities & CVEs by al-ice.ai Editorial

ServiceNow published its September CVE batch on September 24 as knowledge-base article KB3159623. Five vulnerabilities, all in the ServiceNow AI Platform, all filed into NVD within the same minute that evening. Two are rated critical under CVSS v4.0 at 9.3; the other three score 8.4, 8.7, and 8.7.

The batch is worth reading closely for a reason the severity numbers do not convey. Four of the five are described as reachable by an unauthenticated attacker, and the set covers every direction of failure at once: read data you should not see, write data you should not touch, execute SQL against the database directly, and escalate privilege off the back of it.

The five, from the vendor's own text

ServiceNow's descriptions are terse and carry the standard "in certain circumstances" hedge throughout. Reproduced with their identifiers, CVSS v4.0 scores as assigned by ServiceNow's PSIRT, and the CWE classification NVD recorded:

  • CVE-2026-13016 — 9.3 critical, CWE-89. SQL injection. An unauthenticated user, in certain circumstances, could execute arbitrary SQL statements against the instance's underlying database and gain access to, or modify, instance data beyond what was intended. Vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H — network, no privileges, no user interaction, high impact across confidentiality, integrity and availability. Internal tracking PRB2036897.
  • CVE-2026-86860 — 9.3 critical, CWE-862. Missing authorization. An unauthenticated user could extract instance data beyond what was intended, resulting in privilege escalation. The vector carries high subsequent-system confidentiality and integrity impact (SC:H/SI:H), which is why it reaches critical despite being read-oriented. PRB2050429.
  • CVE-2026-86858 — 8.7 high, CWE-284. Improper access control. An unauthenticated user could create, modify, or delete instance data beyond what was intended. Pure integrity impact: VC:N/VI:H/VA:N. PRB2059173.
  • CVE-2026-86859 — 8.7 high, CWE-284. Authorization bypass. An unauthenticated user could access data they are not entitled to, potentially enabling further unintended access. PRB2055263.
  • CVE-2026-86857 — 8.4 high, CWE-862. Authorization bypass, and the only one in the batch requiring authentication (PR:L). An authenticated user could access data beyond their entitlement. Scores high on subsequent-system impact. PRB2033195.

ServiceNow states it is not currently aware of malicious exploitation against ServiceNow instances for any of the five, and that each was found through internal security testing, customer security assessments, or its responsible-disclosure and bug bounty programs, and remediated independently.

The August patch hiding in the September batch

One sentence in the advisory differs from the other four, and it changes what the disclosure date means.

For CVE-2026-86858 — the unauthenticated create/modify/delete flaw — ServiceNow writes: "In August 2026, ServiceNow deployed a security update to hosted instances and ServiceNow provided the update to our partners and self-hosted customers." The corresponding sentence for the other four says simply "ServiceNow deployed a security update," with no month.

So an unauthenticated data-modification flaw was fixed roughly a month before it was named. For hosted customers that gap is invisible and harmless — the patch arrived when it arrived. For self-hosted operators it is the entire question: if you deferred the August update because nothing in it looked urgent, you have been carrying an unauthenticated write primitive on the strength of a changelog that did not tell you what it closed. The CVE gave that update a severity a month after the decision to skip it was made.

This is a recurring shape in vendor-managed platforms, and it is not misconduct — coordinating an identifier takes longer than shipping a fix, and shipping the fix first is the right order. But it does mean the published date measures disclosure, not exposure, and self-hosted deployments are the population for whom that distinction has teeth.

Why "AI Platform" is the whole product

Every one of these lands in a component ServiceNow calls the AI Platform, and it is easy to misread that as a bolt-on feature module. It is not. ServiceNow renamed the core Now Platform to the AI Platform; the affected releases are the platform release trains themselves — Yokohama, Zurich, and Australia. This is not a vulnerability in an optional assistant. It is a vulnerability in the thing your ITSM, CMDB, HR cases, and change management all run on.

That matters for scoping. A CMDB is, by construction, a map of everything an organisation operates: hostnames, owners, dependencies, environments, credentials-adjacent metadata. Unauthenticated SQL access to the instance database is not merely a data breach of one application. It is a breach of the inventory that describes every other application, and — via CVE-2026-86858's write path — of the record that change and approval workflows treat as ground truth.

Read alongside CVE-2026-86860's privilege escalation, the chain assembles itself without much imagination: read what you shouldn't, escalate off what you read, then write. None of the advisories claim these compose, and we are not asserting they do — ServiceNow assigned separate PRB identifiers and remediated them independently. But they were all present in the same platform at the same time, and a defender scoping worst case should assume an attacker who found one would look for the others.

Which version actually contains the fixes

The version table in KB3159623 is more confusing than it needs to be, and misreading it is the likeliest way to be told you are patched when you are not.

Customers in the ServiceNow August Patching Program received:

  • Yokohama — Patch 13 Hot Fix 5a
  • Zurich — Patch 10 Hot Fix 4a W32
  • Australia — Patch 2 Hot Fix 4b W32

ServiceNow separately lists additional versions that contain remediations for all five CVEs in the September batch: Zurich Patch 10 Hot Fix 3b, Patch 11 Hot Fix 3; Australia Patch 4 Hot Fix 3, Patch 5.

Note that the second table has no Yokohama row. Operators on Yokohama should read the first table as their target and confirm against ServiceNow's release notes rather than inferring from the Zurich and Australia entries. Hot-fix suffixes such as 4a, 4b, 3b, and the W32 designation are not orderable by intuition — Hot Fix 4a is not self-evidently newer than Hot Fix 3b in a way an operator can reason about from the string alone. Check the exact build, not the patch number.

The structural point

Five CVEs, four unauthenticated, and not one of them is an AI vulnerability. There is no prompt injection here, no tool-call abuse, no model-in-the-loop anything. They are SQL injection and four flavours of missing authorization — the same bugs that have been in web applications for twenty-five years, sitting in a product whose name now begins with "AI."

That is the observation worth carrying forward, and it cuts against where most attention currently goes. A platform becomes an AI platform by adding agents, assistants, and autonomous workflows on top of an existing data layer. The agents inherit the data layer's access control. If that layer has an unauthenticated authorization bypass underneath it, no amount of guardrail engineering at the agent tier is relevant, because the attacker has no reason to go through the agent at all.

We reached the same conclusion from the opposite direction in IBM's Financial Transaction Manager bulletin, where one AI-specific RAG-poisoning flaw shipped alongside dozens of conventional deserialization and traversal bugs, and in SalesBleed's Agentforce exfiltration chain, where the novel agent behaviour mattered only because it reached ordinary CRM data. ServiceNow itself has been here before, with CVE-2026-0542 in March.

The pattern holds: the AI features are the reason these platforms are being deployed faster and wired to more data, and the vulnerabilities being found in them are overwhelmingly the boring kind. Budget accordingly.

What to do

  • Verify your exact build against KB3159623 — not the patch number, the full hot-fix string. Hosted instances were updated by ServiceNow; self-hosted and partner-managed deployments are the ones carrying risk.
  • Treat CVE-2026-86858 as a separate timeline. It was patched in August. If your self-hosted instance skipped that update, you were exposed to an unauthenticated write path for roughly a month longer than the September publication date suggests.
  • Check whether your instance is internet-reachable. Four of five carry AV:N/PR:N. Network exposure is the difference between "patch on the normal cycle" and "patch now" — and ServiceNow instances are frequently public by design, because that is how portals and integrations work.
  • Hunt retrospectively rather than relying on "no known exploitation." ServiceNow reports no evidence of malicious exploitation, which is a statement about what the vendor can see across hosted instances, not a clean bill of health for yours. For an unauthenticated SQL injection, look for anomalous query patterns and error rates against the instance database, and for unexpected record creation or deletion in the window before your patch landed.
  • Scope by data, not by module. If this instance holds your CMDB, the blast radius of a read primitive is your entire estate inventory — asset ownership, dependency mapping, environment topology. Assess it as that, not as one application's records.
  • Audit what your AI agents and integrations can reach in the platform. The vulnerabilities here bypass the agent layer entirely, but the same over-broad service accounts that make agent features convenient are what turn an authorization bypass into a full extraction. Least privilege at the integration account is the control that limits both.

Sources: