ServiceNow Patches Four AI Platform Flaws, Three Rated CVSS 10.0 for Unauthenticated Attack

ServiceNow has patched four vulnerabilities in the ServiceNow AI Platform, and three of them carry the maximum possible severity score: CVSS 10.0. In certain circumstances, each of the three can be reached by an attacker who has no account and no credentials, then used to run code or execute SQL against the instance behind it. That is the headline. The part that decides whether it becomes your problem is quieter: ServiceNow already patched the instances it hosts, but every self-hosted customer and every partner running its own instance has to apply the fix by hand.

The advisory landed on August 27, 2026, and was first reported by The Hacker News the next day. ServiceNow, which acts as the CVE Numbering Authority for its own products, assigned all four identifiers and all four scores. None of the four has appeared in CISA's Known Exploited Vulnerabilities catalog, and ServiceNow says it is not aware of any of them being exploited. So this is a patch-before-it-matters story, not a fire drill. But "before it matters" has a short shelf life on a platform this exposed, and the responsibility split is where teams lose time.

What ServiceNow Patched

The four flaws sit in different parts of the platform, but three share the same worst-case profile: no login required, low attack complexity, and full compromise of confidentiality, integrity, and availability. Here is the exact set, as listed in ServiceNow's August 2026 CVE advisory:

• CVE-2026-18885 (CVSS 10.0) is a code injection flaw in the GraphQL Composite Data API. ServiceNow says an unauthenticated user could use it to execute arbitrary code and read or change instance data.
• CVE-2026-18886 (CVSS 10.0) is an improper access control flaw in the system configuration image upload processor, which could let an unauthenticated user create or modify instance data and escalate privileges.
• CVE-2026-74820 (CVSS 10.0) is a SQL injection reached through a dynamic schema ORDER BY clause, which could let an unauthenticated user run arbitrary SQL against the database under the instance.
• CVE-2026-6876 (CVSS 8.7) is a sandbox escape in the Now Platform. ServiceNow's written description says an unauthenticated user could run arbitrary code, though the CVSS vector it published for the same flaw records PR:L, meaning low privileges are required. That gap between the prose and the vector is worth flagging: the two disagree, and ServiceNow is the only source scoring it.

The three maximum-severity flaws all carry the 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. In plain terms, that describes a network-reachable attack that needs no privileges, no user interaction, and little skill, with high impact both to the vulnerable component and to the systems connected to it. It is the shape of score that gets a platform added to exploitation scanners quickly once a working exploit exists.

Which Versions Are Affected

ServiceNow scoped the advisory by release family. Each entry below means "any version before" the named patch level, and any release the advisory does not name is treated as unaffected by default.

One wrinkle for anyone automating this check: the record for CVE-2026-18886 marks "Any version before Australia Patch 5" with a status of unknown, while the other three mark the same version as affected. If you are on that exact release, treat it as in scope until ServiceNow says otherwise.

Why the CVSS 10.0 Label Needs a Second Look

A 10.0 is the loudest number in vulnerability management, and it deserves respect. It also deserves context here, because of who produced it. ServiceNow is its own CVE Numbering Authority, so the company assigned these scores to its own products. That is normal and allowed. It just means there is no independent second opinion baked in.

There is a structural reason no second opinion exists yet. Since April 15, 2026, NIST has enriched only the vulnerabilities that show up in CISA's Known Exploited Vulnerabilities catalog, affect federal government software, or are designated critical under Executive Order 14028. None of these four qualifies as of August 28, 2026, so NIST has not weighed in, and the National Vulnerability Database carries no independent analysis. ServiceNow's rating is the only severity assessment on record.

The advisory itself is terse. Its own summary line reads: "On August 27, 2026, ServiceNow issued CVE-2026-6876, CVE-2026-18885, CVE-2026-18886, and CVE-2026-74820 regarding the underlying logic that allowed for the reported security issues." There is no technical write-up, and Searchlight Cyber, the firm credited with related research, had published none for the August flaws at the time of writing. The Hacker News found no public exploit code for the three maximum-severity flaws.

My read: The absence of a KEV listing and public exploit code is a scheduling gift, not an all-clear. Three unauthenticated, low-complexity 10.0s on a platform that holds workflow, ITSM, and increasingly AI-driven automation data is exactly the kind of target that draws exploit development once a patch exists to diff against. Treat the window as short. The right posture is "patch this cycle," not "wait for KEV," because on this class of SaaS the KEV listing tends to arrive after the exploitation, not before it.

Who Actually Has to Patch

This is where the story stops being about ServiceNow and starts being about your inventory. ServiceNow said it deployed the update to hosted instances and provided the update to its partners and self-hosted customers. The practical translation is a split.

The patch-responsibility split for the August 27, 2026 ServiceNow AI Platform advisory. CyberSignal diagram.

If ServiceNow hosts your instance, the fix is likely already applied, but "likely" is not "verified." Confirm the patch level rather than assuming the vendor got to your tenant. If you run your own instance, or a managed service provider or reseller runs one on your behalf, the update does not install itself. Someone has to schedule it, and until they do, the instance stays exposed.

What to Do Now

For teams running or depending on the ServiceNow AI Platform, the defender checklist is short and specific:

• Apply the update immediately on any self-hosted instance. Map your release family to the affected table above and move to the named patch or hot-fix level (or later). The Xanadu, Yokohama, Zurich, and Australia families all have fixed builds.
• Verify partner and reseller status. If a partner, managed service provider, or reseller operates an instance for you, get written confirmation of the patch level. This is the leg that gets missed, because "someone else runs it" quietly becomes "no one patched it."
• Confirm your hosted-tenant patch level. Even on ServiceNow-hosted instances, verify rather than assume. Ask for the applied patch or hot-fix version and check it against the advisory.
• Monitor for exploitation. Watch the ServiceNow advisory and the KEV catalog for status changes, treat any of these four appearing in KEV as an escalation trigger, and review authentication and admin activity logs on internet-reachable instances.

For the security-program view of where this fits, our complete guide to vulnerability management covers how to prioritize a batch like this when the vendor is the only party scoring it, and our guide to AI security covers the specific exposure that comes with AI-driven platforms holding sensitive workflow data.

The Pattern Worth Watching

This is not the first maximum-or-near-maximum flaw in this platform this summer. In July, ServiceNow disclosed CVE-2026-6875, a pre-authentication sandbox escape in the same AI Platform that we covered when it came under active exploitation. That episode is a useful lesson in reading exploitation claims carefully: the threat intelligence firm Defused first reported in-the-wild exploitation, then issued a correction stating that the captured payload matched Searchlight Cyber's published proof-of-concept rather than a novel attack. ServiceNow, for its part, said it had "not observed evidence that this activity is related to instances that ServiceNow hosts."

ServiceNow scored that July sandbox escape at 9.5, with every metric identical to the new three except attack complexity, which it set to high. The three August flaws are rated a half-point higher precisely because ServiceNow judged them easier to pull off. That progression, from a 9.5 that drew real exploitation interest to three 10.0s with lower complexity, is the reason the patch window here deserves urgency even without a KEV listing.

The broader thread is one we have tracked before, when Fortinet, Ivanti, and ServiceNow lined up a coordinated critical patch cycle: enterprise platforms that sit at the center of IT operations are drawing maximum-severity, unauthenticated bugs at a steady clip, and the ones that hurt are usually the ones where nobody was sure who owned the patch. Settle that question for your ServiceNow footprint before you need to.

Updated August 28, 2026: This is a developing advisory. We will note material changes, including any KEV listing or confirmed exploitation.

Primary Documents

• ServiceNow August 2026 CVE Advisory Notification (KB3152242)
• CVE records: CVE-2026-18885, CVE-2026-18886, CVE-2026-74820
• The Hacker News: Three CVSS 10.0 ServiceNow Flaws Could Let Unauthenticated Attackers Execute Code and SQL (August 28, 2026)
• CISA Known Exploited Vulnerabilities Catalog