Three ServiceNow AI Platform flaws (CVSS 10.0) let an unauthenticated attacker run code. Patch now.

ServiceNow's AI Platform just drew three separate flaws rated a perfect 10.0, and any one of them can be reached by someone who has never logged in. The vendor patched them on August 27 and says it has seen no exploitation so far. Hold that thought, because five weeks ago a different pre-auth flaw in the same platform went from patch to real-world attack in five days. The interesting part is not any single bug. It is that the platform enterprises use to run their tickets, their asset inventory, and their change process keeps handing out unauthenticated paths to code execution.

The three maximum-severity issues (reported by The Hacker News and BleepingComputer) sit in different corners of the product but share one property: the CVSS 4.0 vector marks them network-reachable, low-complexity, and requiring no privileges and no user interaction. A fourth, lower-rated flaw shipped in the same batch. ServiceNow's own records state it is not currently aware of malicious activity against instances. Treat that as a starting gun, not an all-clear.

What the three flaws actually are

CVE-2026-18885 is the one that should worry an architect most. It is a code-injection flaw in the platform's GraphQL Composite Data API, the batched-query interface the AI Platform uses to pull related records in one round trip. Composite and batched GraphQL resolvers are a recurring weak spot precisely because they fan a single request out across many fields, and authorization that is enforced per field can be skipped when the batch layer resolves data on its own. When a data API of that shape accepts input that reaches code execution, the blast radius is the whole instance.

CVE-2026-74820 is a SQL injection through a dynamic ORDER BY clause. Sort parameters are a classic injection sink because developers parameterize the WHERE filter and then concatenate the sort column as a bare string, on the assumption that a column name is harmless. It is not, and on a platform whose database holds your configuration management database and credential references, read-or-write access to that store is close to game over. CVE-2026-18886 is an access-control failure in the image-upload path that lets a request act above its privilege level. We have watched the same unauthenticated-plus-database-access pattern play out this year in a Metabase zero-day and, at the platform tier, in Dassault's 3DEXPERIENCE.

Why "not exploited yet" understates the stakes

Two things make the current calm misleading. The first is what ServiceNow is. It is rarely a leaf node on the network. It holds the configuration management database, it stores service-account and integration credentials, and it is wired outward to the ticketing, monitoring, and provisioning systems it orchestrates. A foothold there is not a data-loss event in one app. It is a pivot into everything the platform is trusted to talk to, which is usually a lot. Rating these flaws only by what they do to ServiceNow undercounts the real exposure.

The second is timing, and we have a local data point for it. In July we covered CVE-2026-6875, a pre-authentication sandbox escape in this same AI Platform. According to the reporting at the time, in-the-wild exploitation began July 18, five days after the July 13 patch, and the live payloads used a different escape route than the public proof of concept. So the platform has a recent history of a patched pre-auth flaw drawing working attacks inside a week, through a path the published exploit did not show. Three fresh 10.0s with a patch already public is exactly the setup that history rhymes with.

Map your instance to the right hot fix

The fix is real but it is not one button. ServiceNow ships these corrections as per-release-family hot fixes across its Xanadu, Yokohama, Zurich, and Australia lines, and the exact hot fix you need depends on which patch level your instance already runs. That makes patching a mapping exercise: identify your release family and current patch, then apply the specific hot fix that ServiceNow lists for it in the advisory, rather than reaching for a single version number. Self-hosted and self-managed instances carry the whole job; do not assume a background update handled it. For the precise hot fix per family, work from ServiceNow's security advisory directly, since the matrix is long and getting the wrong cell means you are still exposed.

Prioritize the internet-reachable instances first, then the ones an attacker could reach after a single hop from a compromised segment. If you cannot patch an exposed instance immediately, put it behind your VPN or restrict the GraphQL data endpoints at the proxy tier while you stage the change, and treat that as a stopgap measured in hours, not a mitigation you live with.

What to watch while the hot fix lands

Because there are no in-the-wild indicators for these three yet, signature hunting has nothing to match. Hunt on behavior instead, and lean on the shape of the flaws:

• Unauthenticated or anomalous calls to the GraphQL data API, especially composite or batched queries from sources that never used them before.

• New privileged accounts or unexpected role grants created after your patch date, the same tell that surfaced the July intrusions.

• Errors or unusual query volume against the platform database that look like probing of sort or filter parameters.

• Outbound connections or script execution from the ServiceNow application and MID Server hosts that do not match their normal baseline.

A managed detection stack helps here for the same reason it helped in July: when there is no exploit signature to write, the win comes from having the platform's process, account, and network behavior already baselined so a deviation stands out. This is not a blocklist problem. It is a know-your-normal problem, and it is best solved before the exploitation you are watching for arrives.

Assume the quiet does not last. Patch the exposed instances today, map each one to its correct hot fix, and put the behavioral watch in place while you do, because the July timeline is the most honest forecast you have for this one.