Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-18885

  • ServiceNow scored three of its own AI Platform flaws at a flat 10.0, and a fourth record contradicts itself on authentication

    ServiceNow scored three of its own AI Platform flaws at a flat 10.0, and a fourth record contradicts itself on authentication

    ServiceNow’s PSIRT published four CVEs on 27 August and scored three of them at a flat CVSS v4.0 10.0 with byte-identical vectors — while the fourth record describes an unauthenticated attacker and scores one who needs an account.

    What happened

    NVD published four ServiceNow CVEs on 27 August 2026, three of them at 20:17 UTC and the fourth a minute later. All four are still in Received status and were last modified on 29 August. All four are scored by [email protected] — ServiceNow is the CNA here, and these are the vendor’s own numbers for the vendor’s own product. All four cite a single reference: ServiceNow’s knowledge base article KB3152242.

    Three carry a CVSS v4.0 base score of 10.0, Critical:

    • CVE-2026-18885 — CWE-94, code injection in ServiceNow AI Platform. The description says it lets unauthenticated users “execute arbitrary code in the ServiceNow platform and gain access to, or modify, instance data.”
    • CVE-2026-18886 — CWE-284, improper access control, letting unauthenticated users “create or modify instance data beyond what was intended, resulting in privilege escalation.”
    • CVE-2026-74820 — CWE-89, SQL injection, letting unauthenticated users “execute arbitrary SQL statements against the instance’s underlying database and gain access to, or modify, instance data.”

    All three carry exactly the same 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 fourth, CVE-2026-6876, is a sandbox escape in the Now Platform, CWE-94 with CWE-693 and CWE-1284, scored 8.7, High, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

    The affected-version list in the CVE records is long, and it is the useful part. ServiceNow AI Platform is vulnerable below each of: Xanadu Patch 11 Hot Fix 7a; Yokohama Patch 12 Hot Fix 3b and 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 on the m-branch, Patch 10 Hot Fix 3 on the standard branch, Patch 11 and Patch 12; and Australia Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 and Patch 5.

    On exploitation, ServiceNow’s position as reported is: “We are not currently aware of malicious exploitation against ServiceNow instances. We recommend customers promptly apply appropriate updates or upgrade to a patched release if they have not already done so.” The company patched its own hosted fleet and directed customers to secure self-hosted instances.

    CISA’s SSVC decision points on all three 10.0 records read Exploitation: none, Automatable: yes, Technical Impact: total. On CVE-2026-6876 they read Exploitation: none, Automatable: no, Technical Impact: total. None of the four carries a cisaExploitAdd or cisaActionDue field, so there is no KEV entry and no federal remediation deadline attached.

    Why it matters

    A CVSS v4.0 10.0 is a harder thing to reach than a CVSS v3.1 9.8, and the difference is worth understanding before deciding what these numbers are telling you.

    Under v3.1, an unauthenticated network attack with total confidentiality, integrity and availability impact caps out at 9.8. Under v4.0, that same shape lands around 9.3. Getting to a flat 10.0 requires all three subsequent system metrics to be High as well — SC:H/SI:H/SA:H. That is a specific, deliberate assertion: compromise of the vulnerable component propagates to systems beyond it. It is not a rounding artifact and it is not the scale’s default ceiling. Somebody chose it, three times.

    The somebody is ServiceNow. As the CNA for its own products, ServiceNow assigns the CVE, writes the description and sets the vector. That is normal and it is how CNA scoring is supposed to work — the vendor knows the architecture. But it means these are self-assessments, and the assessment being made is that a defect in the ServiceNow AI Platform reaches past the ServiceNow AI Platform. For a system that typically holds the CMDB, the ticket history, the HR case records and privileged integration credentials into most of the rest of an estate, that is a claim worth taking at face value, because the vendor is the party best placed to know and it is not a flattering thing to publish about yourself.

    Now notice what the identical vectors do not tell you. Three structurally different defects — a code injection, an access control failure and a SQL injection — produced the same eleven metric values. That is possible, and for a platform where any unauthenticated write is game over it may be exactly right. But it also means the score is describing the platform’s blast radius rather than the individual bug. You cannot use these numbers to rank the three against each other, because they were not built to distinguish them. Anyone whose remediation process sorts by base score is going to find all three tied at the top of the list with nothing to break the tie, and will have to read the descriptions to sequence the work — which is the correct outcome, arrived at by accident.

    Then there is CVE-2026-6876, where two fields of one record disagree. The description says the flaw lets unauthenticated users “execute arbitrary code within the Now Platform.” The vector says PR:L — privileges required, low — which means the attacker holds at least a basic account. Both fields come from the same CNA in the same submission. They cannot both be right.

    This is not a pedantic complaint. Whether an attacker needs an account is the difference between a flaw exposed to the internet and a flaw exposed to your user population, and it changes both the urgency and the compensating control. A tool ingesting the vector will queue this behind the unauthenticated three. A human reading the description will not. The record does not settle it, and in the specific case of a sandbox escape — where the standard precondition is the ability to get code into the sandbox in the first place — PR:L is the more plausible of the two readings. We are flagging the contradiction rather than resolving it, because resolving it is ServiceNow’s job.

    One last piece of context, offered as context and not as a finding. CVE-2026-6876 sits in a low-numbered 2026 block, near CVE-2026-6875 — a separate ServiceNow flaw from July that drew in-the-wild activity which one threat intelligence firm characterized as matching published proof-of-concept code rather than original research. Adjacent CVE numbers usually mean adjacent reservation dates, not related bugs, and we have no evidence connecting the two. What the July episode does establish is the tempo: ServiceNow flaws attract scanning quickly once a PoC exists, and “no exploitation observed” is a statement about today.

    What to do

    • Establish hosted versus self-hosted first. ServiceNow has patched instances it operates. If your instance runs on ServiceNow’s cloud, confirm your patch level rather than assuming, but the work is likely done. If you run it yourself, all of it is yours.
    • Patch to the boundaries in the CVE records, which are more precise than any summary. Xanadu: Patch 11 Hot Fix 7a or later. Yokohama: Patch 12 Hot Fix 3b, or 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 or 3 depending on branch, Patch 11, or Patch 12. Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4, or Patch 5.
    • Mind the m-branches. Zurich Patch 10 and Australia Patch 3 each have separate m-branch and standard-branch fix levels. Getting the branch wrong means installing a build that is not the fix.
    • Do not sequence by score. The three 10.0s are tied by construction. Sequence by exposure: the SQL injection and the code injection give data access and execution; the access-control flaw gives privilege escalation that persists after you close the other two.
    • Treat integration credentials as in scope. If you conclude an instance may have been reached, the credentials it holds for downstream systems are the real loss, and they are not fixed by patching ServiceNow.
    • Watch for a KEV addition. There is none today. Given Automatable: yes on all three 10.0s and a vendor advisory that is now public, a proof of concept is the only missing ingredient.

    Sourcing note

    Checked: NVD API records for CVE-2026-18885, CVE-2026-18886, CVE-2026-74820 and CVE-2026-6876, which supplied the publication timestamps, descriptions, CVSS v4.0 vectors and scores, CWE assignments, the full affected-version list, the CISA SSVC decision points, and the confirmation that none of the four carries a KEV date. The CNA on all four is [email protected].

    Could not reach: ServiceNow’s advisory KB3152242 at support.servicenow.com, the single reference on all four records, which returned only page furniture to us. ServiceNow’s quoted statement on exploitation and its guidance to self-hosted customers are therefore taken from BleepingComputer’s report of 28 August, which read the advisory, and are labeled as secondary rather than quoted as primary. The description of CVE-2026-18885 as sitting in the GraphQL Composite Data API and CVE-2026-18886 in configuration image upload comes from other secondary coverage and is not in the NVD records; we have not repeated those specifics above as fact.

    Unresolved: whether CVE-2026-6876 requires authentication, which the record answers two ways; who reported the four flaws, which no source we checked identifies; and whether the July CVE-2026-6875 activity has any bearing here, which we have no evidence for either way.