ServiceNow patched three CVSS 10.0 flaws that need no password at all. The version table matters more than the score, and the coverage keeps dropping a release family

What ServiceNow published

On 27 August 2026, ServiceNow published advisory KB3152242 covering four vulnerabilities in its platform. Three of them are CVSS 4.0 10.0, the maximum score, and all three are exploitable by someone with no account, no credentials and no help from a user. The fourth, a sandbox escape, is 8.7.

Most coverage has reported this as three critical bugs to patch, which is true and incomplete. The advisory rewards a closer read, because it contains one number that will not age well, one release family that the coverage keeps dropping, and a score whose meaning is more specific than "very bad".

Three doors, not one bug

The first thing to fix is the mental model. These are not one flaw described three ways. They are three independent bugs, in three unrelated components, each of which gets an unauthenticated stranger to your instance data by a different route.

Three doors, not one bug

The three maximum-severity flaws

CVE	Component	Class	What it grants	Reported by
CVE-2026-18885	GraphQL Composite Data API	Code injection, CWE-94	Arbitrary code execution on the platform	Adam Kues, Assetnote
CVE-2026-18886	System configuration image upload processor	Improper access control, CWE-284	Create or modify instance data, escalating privilege	Kevin Gervot, Assetnote
CVE-2026-74820	Dynamic schema ORDER BY clause	SQL injection, CWE-89	Arbitrary SQL against the underlying database	Not credited in the record

Note what that means operationally. Only one of the three is the remote code execution everyone is talking about. The other two reach your data without needing code execution at all: one by creating or modifying records until it holds privilege it was never granted, one by running SQL directly against the database underneath. A team that patches with "the ServiceNow RCE" in mind has understood a third of the advisory.

There is a wrinkle worth flagging because it affects how you triage. ServiceNow’s own knowledge-base article describes CVE-2026-18886 as a code injection vulnerability, while its CVE record describes it as improper access control and carries CWE-284. Two vendor-authored documents disagree about the bug class. This site has written before about treating CWE labels as ground truth when they are a defensible classification rather than a precise fact, and here the vendor could not keep its own two descriptions consistent.

Why it is a clean 10.0, and what that asserts

A 10.0 is not a synonym for severe. Under CVSS 4.0 the vector says something specific, and this one is worth decoding because the second half is the part that matters for planning.

Why this is a clean 10.0, and what that asserts

All three carry the identical vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The first half is the familiar bad news: reachable over the network, low complexity, no preconditions, no privileges, no user interaction. The second half is the interesting one. SC:H, SI:H and SA:H say the impact extends to subsequent systems, beyond the vulnerable component itself.

For ServiceNow specifically, that is the correct reading rather than a formality. The platform holds the CMDB, the service desk, the change records and, more to the point, the stored integration credentials that let it talk to everything else in the estate. A total compromise of it is not an application incident. It is a position from which to reach the systems it was built to orchestrate.

One caveat on the number itself, which cuts both ways. That 10.0 is ServiceNow’s own score, submitted as the CVE Numbering Authority. At the time of writing all three sit in the National Vulnerability Database with status "Received", meaning NIST has not yet done its own analysis. That does not make the score wrong, and vendors are usually well placed to score their own products. It does mean the most-quoted figure in every headline is currently a self-assessment rather than an independently reviewed one.

The version table is the actionable part

If you read one thing in the advisory, read the version table, because this is where the news coverage has been slipping.

Fixed versions, by release family

Release family	Fixed at
Xanadu	Patch 11 Hot Fix 7a
Yokohama	Patch 12 Hot Fix 3b; 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 (m-branch); Patch 10 Hot Fix 3 (standard); Patch 11; Patch 12
Australia	Patch 2 Hot Fix 3; Patch 3 Hot Fix 2; Patch 3m; Patch 4; Patch 5

The line that will not age well

Here is the sentence every report is repeating, verbatim from ServiceNow: "We are not currently aware of malicious exploitation against ServiceNow instances."

It is accurate. It is also a statement about the vendor’s knowledge on the day of publication, and it is being read as a property of the vulnerability. Three things sit against it.

First, CISA disagrees about the trajectory. In its Vulnrichment enrichment of these records, CISA scores all three as Exploitation: none today, but also as Automatable: yes with Technical Impact: total. Automatable means the reconnaissance, weaponisation and delivery can be scripted across many targets at once. CISA is saying that when an exploit exists, this is mass-scannable, not bespoke.

Second, the absence of a public exploit is real but thin. None of the three is in the CISA Known Exploited Vulnerabilities catalogue, and a search of public repositories returns nothing for any of the three identifiers. That absence is meaningful rather than an artefact, because the same search for ServiceNow’s July flaw returns a full weaponised framework.

Third, and most instructive, the last ServiceNow bug from the same research team shows how fast this changes, and how unreliable the exploitation signal is in both directions.

The July precedent, and why exploitation reporting is hard

1. 13 Jul

   ServiceNow discloses CVE-2026-6875

   A pre-authentication sandbox escape in the ServiceNow platform, CVSS 4.0 9.5, found by Adam Kues of Assetnote, the same researcher credited on one of the August flaws.

2. 14 Jul

   Full technical write-up published

   Assetnote publishes the mechanism, including the sandbox escape technique. A working exploit framework appears publicly.

3. Days later

   Exploitation reported in the wild

   A threat-intelligence account reports active exploitation, and it is picked up widely.

4. Shortly after

   The report is corrected

   The captured payload turns out to match the researcher’s own published proof of concept. ServiceNow states it has not observed evidence the activity relates to instances it hosts.

That sequence is the lesson. "No known exploitation" was true until it was not, and then "exploitation observed" was reported and turned out to be somebody replaying a public proof of concept at internet scale. Both halves of the exploitation signal are weaker than they look, which is an argument for patching on the vector rather than waiting for the news to tell you it is urgent.

Hosted does not mean handled

The advisory says: "ServiceNow deployed a security update to hosted instances and ServiceNow provided the update to our partners and self-hosted customers." That sentence is doing a lot of work, and it is worth pulling apart.

The position

The headline number is real and the advice attached to it is simple: patch, this week, on every release family including Australia. But the more useful reading is about how to hold two facts at once. The advisory says nobody has seen this exploited. CISA says that when somebody does, it will scale. Both are true, and only one of them is durable.

This is the shape this site keeps finding in security artefacts. "We are not currently aware of malicious exploitation" is a timestamp, not a property, and it is being consumed as a risk rating. The version table, by contrast, is a fact that does not decay, and it is the part of the advisory that most of the coverage rendered incompletely. When a document contains one line that expires and one that does not, the industry reliably quotes the one that expires.