ServiceNow published its August 2026 CVE advisory on August 27, and it contains something you almost never see in a single vendor bulletin: three separate CVSS 10.0 vulnerabilities, all exploitable by unauthenticated attackers, all in low-complexity attacks requiring no user interaction.

The three:

  • CVE-2026-18885 — code injection in the Now Platform. An unauthenticated attacker can, under certain circumstances, execute arbitrary code within the ServiceNow platform.
  • CVE-2026-18886 — code injection in the ServiceNow AI Platform. An unauthenticated attacker can create or alter instance data outside expected authorization boundaries, leading to privilege escalation.
  • CVE-2026-74820 — SQL injection in the ServiceNow AI Platform. An unauthenticated attacker can execute arbitrary SQL against the instance’s underlying database, exposing sensitive data or modifying database-backed records.

A fourth, lower-severity issue was fixed in the same release. ServiceNow says it is not currently aware of malicious exploitation against ServiceNow instances.

What a ServiceNow instance actually holds

The severity scoring understates the problem, because CVSS measures the vulnerability rather than the asset.

A mature ServiceNow deployment is the operational nervous system of an enterprise. It typically contains:

  • The CMDB — a complete, curated inventory of every server, application, network device, and dependency in the environment. For an attacker, this is a free network map that the victim maintained for them.
  • The full IT ticket history — including, invariably, credentials pasted into ticket bodies by users and support staff who were told not to and did it anyway.
  • Privileged access request and approval workflows, with the integrations to execute them.
  • HR case management, covering investigations, accommodations, terminations, and compensation.
  • Vendor and contract records, and often procurement and finance workflows.
  • Integration credentials to nearly everything else — the whole point of the platform is that it orchestrates other systems, which means it holds the keys to them.

An unauthenticated code execution primitive against that is functionally an unauthenticated code execution primitive against the organization’s IT operations layer. And CVE-2026-74820 gives direct SQL access to the database sitting underneath it all.

The AI Platform is the new attack surface, and it is showing

Two of the three maximum-severity flaws are in the ServiceNow AI Platform, not the mature Now Platform core. That is not a coincidence and it is the part of this advisory worth generalizing from.

AI feature layers across the enterprise software market are being shipped at a velocity that platform security review has not kept pace with. They introduce new parsing surfaces, new dynamic evaluation paths, new database query construction — often assembled by models or templating logic rather than by hand — and new authentication boundaries between the AI layer and the platform it sits on. A SQL injection in an AI platform component in 2026 is a strong indicator that query construction is happening somewhere it was not being reviewed with the rigor the core platform gets.

ServiceNow separately shipped CVE-2026-6875, a sandbox escape in the AI Platform. The pattern across the advisory is consistent: the AI surface is where the boundary failures are.

This should recalibrate how organizations treat AI feature enablement generally. An AI module bolted onto a system of record is not a feature toggle. It is a new, less-hardened front door onto the same data.

Not the first ServiceNow exposure this year

In June 2026 the platform was in the news for an unauthenticated API path that exposed customer data. The recurrence matters for one reason: organizations that treated that incident as a one-off and did not tighten instance exposure, ACLs, and monitoring are now facing a materially worse set of primitives against the same surface.

What to do

Patch now, and verify the instance version rather than the ticket. ServiceNow instances are vendor-hosted for most customers, but patch application timing and hotfix acceptance still vary by customer configuration and release family. Confirm your instance is on a fixed build.

Assume public proof-of-concept development is underway. Three maximum-severity unauthenticated flaws in a platform this widely deployed is an irresistible research target. The gap between advisory and working exploit for this class of bug is typically days, not months. Watch for KEV addition.

Restrict instance network exposure. IP allowlisting on ServiceNow instances is available and widely unused. If your instance only needs to be reachable from corporate ranges and specific integration endpoints, restrict it to those.

Audit what your ACLs actually allow. These flaws bypass authentication, but post-exploitation impact is still bounded by data model access rules. Instances with permissive default ACLs — a common accumulation over years of “just make the ticket work” changes — will bleed considerably more.

Rotate integration credentials stored in the platform if you find any evidence of anomalous access, and treat the CMDB as compromised-if-touched. It is the highest-value reconnaissance artifact in the environment.

Sweep tickets for embedded secrets. This is worth doing regardless of this advisory. Search the incident and request tables for password, API key, and token patterns. What you find will be the actual worst-case impact of any ServiceNow compromise, and it is fixable independent of any vendor patch.

Sources