ENTERPRISE SAAS

Three CVSS 10.0 ServiceNow Flaws

Unauthenticated Code Execution and SQL Injection. ServiceNow patched four AI Platform vulnerabilities on August 27, 2026, three of them rated CVSS 10.0 and reachable by an unauthenticated attacker over the network.

Matt Lucas  |  August 30, 2026  |  6 min
Three CVSS 10.0 ServiceNow Flaws — editorial hero illustration
CVEs in this postCVE-2026-18885CVE-2026-18886CVE-2026-6875CVE-2026-6876CVE-2026-74820Live detections →All RedEye CVEs →
3
flaws rated CVSS 10.0
4
release families affected
0
public exploits as of Aug 28
PR:N / UI:N
no creds, no clicks
Detected by CaverLive detection for CVE-2026-6875 in the RedEye Intel Feed →
TL;DR
  • What: ServiceNow published an advisory on August 27, 2026 for four AI Platform vulnerabilities, three of which carry a CVSS 10.0 rating and can be reached without authentication.
  • Impact: An attacker with only network access to a vulnerable instance could execute arbitrary code, write instance data to escalate privileges, or run arbitrary SQL against the backing database, and the CVSS vector claims high impact on connected systems too.
  • Fix / mitigation: Apply the fixed builds ServiceNow lists for Xanadu, Yokohama, Zurich, and Australia, for example Xanadu Patch 11 Hot Fix 7a and Australia Patch 5, and confirm CVE-2026-6875 from the July advisory is also closed.
  • Who's at risk: Self-hosted ServiceNow operators carry the full burden; ServiceNow-hosted customers were updated by the vendor but still need to verify their build.

ServiceNow patched four vulnerabilities in the ServiceNow AI Platform on August 27, 2026. Three of them are rated 10.0 on CVSS, the ceiling of the scale, and all three are described as reachable by an unauthenticated attacker. If you run a self-hosted instance, nothing has been fixed for you yet. ServiceNow updated the instances it hosts and handed the update to partners and self-hosted customers, which means the patch action sits with your team.

The three maximum-severity flaws share one 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. Read left to right, that is network reachable, low complexity, no attack requirements, no privileges, no user interaction, and high impact to confidentiality, integrity, and availability in both the vulnerable component and the systems downstream of it. There is no user to phish and no credential to steal. Reachability is the whole precondition.

The four CVEs

The three top-rated bugs are distinct classes of failure in three separate components: a data API, an upload handler, and a query builder. That pattern matters when you scope your response. A single hardening measure at the edge will not cover all three, and the presence of three unrelated pre-auth defects in one advisory suggests the review that produced them was broad rather than a single-component sweep.

The ORDER BY injection is worth pausing on. Parameterized queries do not protect an ORDER BY clause, because the clause takes an identifier, not a value. Dynamic schema features that let a user pick a sort column are a classic place for that gap to appear, and the fix normally has to be an allowlist of valid column names. If you have built custom code that sorts on user-supplied field names, treat that as a pattern to audit in your own scoped applications as well.

What the severity ratings actually rest on

The 10.0 scores are ServiceNow's own. ServiceNow is the CVE Numbering Authority for its products, so it assigns the CVE and scores it. Since April 15, 2026, NIST has enriched only vulnerabilities that appear in CISA's Known Exploited Vulnerabilities catalog, affect federal government software, or are designated critical under Executive Order 14028. None of these four were in the KEV catalog as of August 28, 2026. There is no second scoring opinion on record.

That cuts both ways. Nobody has independently confirmed the 10.0s, and nobody has independently disputed them either. The vendor has more visibility into its own code than any outside scorer would, and it chose to publish three maximums and to set attack complexity to low on all three. It scored the earlier July sandbox escape at 9.5 with an identical vector except for high attack complexity, so the difference in scoring is deliberate rather than uniform. Treat the ratings as vendor-supplied and act on them anyway.

One internal inconsistency to note

ServiceNow describes CVE-2026-6876 as exploitable by an unauthenticated user, but the CVSS vector it assigned to that same flaw specifies PR:L, low privileges required. That vector also records no impact beyond the vulnerable component. If the prose is right, 8.7 understates it. If the vector is right, some access is needed first. Patch it either way and do not use the 8.7 to defer it past a maintenance window.

Affected versions

Two details will trip up automated scoping. First, all four records set a default product status of unaffected, so any release not named in the list falls outside the affected set rather than defaulting to vulnerable. Second, the record for CVE-2026-18886 marks "Any version before Australia Patch 5" with a status of unknown, while the other three mark that same version as affected. If you are on that build, the safe reading is to patch and stop asking.

The July precedent

This advisory follows CVE-2026-6875, a pre-authentication sandbox escape in the same platform. Searchlight Cyber reported it to ServiceNow on April 1, 2026, and ServiceNow published on July 13. Within days, Defused reported in-the-wild exploitation, then issued a correction stating the captured payload matched Searchlight Cyber's published proof of concept. ServiceNow told The Hacker News its investigation found no evidence the activity was related to instances it hosts.

The useful lesson there is about timing, not attribution. Once a proof of concept for a ServiceNow pre-auth flaw goes public, scanning traffic replaying it shows up in sensors fast enough to be mistaken for real compromise. For the three new flaws, The Hacker News found no public exploit code as of August 28, 2026, and Searchlight Cyber had published no technical write-up. Your patch window is the gap between now and the first write-up, and on the July flaw that gap was measured in days.

Priority order for the next 72 hours

Inventory every ServiceNow instance including non-production and acquired-company tenants, then confirm the build string against the four release families above. Patch self-hosted instances first, since ServiceNow-hosted ones were already updated. Verify the July fix for CVE-2026-6875 is present in the same pass. Then pull web logs for GraphQL Composite Data API calls and configuration image uploads from unauthenticated sessions and check for anything before the patch date.

What to watch

ServiceNow stated in all four records that it is not currently aware of exploitation. That is a statement about vendor visibility on a specific date, not a forecast. Three pre-auth vulnerabilities in an enterprise workflow platform that holds asset inventories, ticket contents, credentials in integration records, and CMDB data is exactly the target profile that draws access brokers. Adam Kues at Searchlight Cyber noted in July that ServiceNow was "severely restricting the type of code that can run in sandbox contexts," so the platform is being hardened while researchers keep finding ways in. Assume a technical write-up lands, and be patched before it does.

Questions about your exposure?

RedEye Security provides assessments for organizations that need to understand their real risk.

Talk to us