ServiceNow CVE-2026-18885, CVE-2026-18886 and CVE-2026-74820: a CVSS 10.0 platform flaw under active exploitation

In late August and early September 2026, three ServiceNow flaws were grouped into a single warning by security researchers. The identifiers are CVE-2026-18885, CVE-2026-18886 and CVE-2026-74820, the maximum CVSS score is 10.0, and the reports from Border Cyber Group and other tracking teams describe ongoing exploitation rather than a theoretical risk.

Why the score is the least interesting part

A 10.0 score tells you the vendor's assessment of the worst case. It does not tell you whether your instance is reachable, which is the question that decides the urgency for a specific organisation.

ServiceNow is the system of record for incident tickets, change records, employee requests and, in many deployments, the workflow that approves and executes automated actions. A flaw that lets an attacker act with the platform's privileges reaches all of that at once. It is not one application's data; it is the operating picture of an IT department, plus the credentials used by every integration that writes to it.

That is why the exploitation reports matter more than the base score. When a platform of this kind is being targeted in the wild, the window between disclosure and attempted compromise is measured in days, and the attackers do not need to know anything about a particular installation before trying.

Self-hosted instances have the hardest version story

ServiceNow's own guidance for self-hosted customers is branch-specific. Fixes are delivered as hot fixes that depend on the release branch in use, which means the answer to "is this fixed" is not a single version number. Two organisations can both be on supported releases and have different patch states.

The practical approach has three steps. Identify the exact branch and build of every instance, including development and test instances that share credentials with production. Map each one to the corresponding hot fix from the vendor's documentation. Then confirm the applied build from inside the instance rather than from a change record, because the record shows intent and the instance shows reality.

If the platform is delivered as a cloud service, the vendor manages the update, and the work shifts to verifying that no unauthorised accounts, plugins or integration credentials were created during the exposure window.

What an attacker would leave behind

Platform flaws of this class are usually exploited through the application's own interfaces, so the artifacts live in the application's records rather than in a web server log. Four places are worth reviewing. New user accounts, especially accounts created outside the normal approval path or with roles that exceed their apparent purpose. New or modified system properties and scheduled jobs, which are the standard persistence mechanism on this platform. Recently created integration users and OAuth applications. And export or report activity against tables the organisation does not normally export.

Reviewing the audit trail for the last thirty days, rather than the last week, is the safer choice, since a 10.0 flaw in active exploitation may have been used before the fix was available.

The limits of the public record

The public reporting groups the three CVE identifiers into one warning and describes active exploitation. It does not publish an exploitation technique, and the mechanism behind each identifier is not described in the sources reviewed here. This article does not add technical detail that the sources do not contain.

What to do first

For self-hosted instances, the order is clear. Identify the branch, apply the branch-specific hot fix, and then audit the accounts, integrations and scheduled jobs for changes that nobody approved. Rotating the credentials used by integrations is worth doing at the same time, because those credentials are the part of the estate that a platform compromise exposes even after the flaw is patched.

References