AxowlBlog
Security Axowl

Three unauthenticated CVSS 10s in the system that approves access

ServiceNow patched three unauthenticated CVSS 10.0 flaws. When the platform that records approvals is writable before login, its records become claims to verify.

Most companies have one place where access gets requested, approved, and remembered. Someone files a ticket, a manager approves it, provisioning runs, and the record proving it all lands in the same platform. Very often that platform is ServiceNow. Everything downstream — the access grant, the audit answer six months later — rests on one assumption: this system only says what logged-in, authorized people made it say.

On August 27, ServiceNow published advisories for three vulnerabilities scored CVSS 10.0, and all three share the same profile: reachable over the network, low complexity, no privileges required, no user interaction. CVE-2026-18885 is a code injection in the GraphQL Composite Data API that can lead to code execution on the platform. CVE-2026-18886 is an access control flaw in an image upload processor that lets an unauthenticated user create or modify instance data — in other words, grant themselves privileges by writing the rows that define them. CVE-2026-74820 is a SQL injection through a dynamically built ORDER BY clause that reaches the instance’s database. A fourth issue, CVE-2026-6876, is a sandbox escape rated 8.7.

ServiceNow says each flaw is exploitable only in certain circumstances and is “not currently aware of malicious exploitation against ServiceNow instances.” Hosted instances were patched by the vendor; self-hosted customers have to apply the fixes themselves, per release line, using the advisory. Trade coverage reports no exploitation either. So far, this is a vendor fixing severe bugs in time. The more interesting question is what the exposure window means for data most teams never think of as at risk.

Unauthenticated means the identity layer was never asked

Every control in front of ServiceNow — SSO, MFA, conditional access, roles, ACL rules — kicks in after login. A pre-auth bug sits before all of it. An attacker using one of these flaws would not have beaten your IdP or phished an admin. They would have walked through a door that never asked who they were.

That matters more here because ServiceNow often manages access for everything else: access requests, role grants, joiner-mover-leaver workflows, firewall change tickets. It is the application other applications take orders from. CVE-2026-18886 makes the point literal: privilege escalation not by stealing a session, but by writing the data in which privileges are defined.

A writable system of record stops being a record

This is the part that outlives the patch. ServiceNow instance data is not just open tickets. It is the approval history — who requested access, who approved it, when, under which policy. It is the CMDB your incident timelines rely on. For many compliance programs it is the evidence itself: when an auditor asks whether access was approved, the answer is a ServiceNow export.

Two of the three flaws let an attacker write. Unauthenticated SQL against the database and unauthenticated changes to instance data both mean that, before patching, the ledger could in principle be edited by someone with no identity in it at all. Nobody has said publicly whether approval and audit tables were reachable through these paths, and no exploitation is known. But the structural point stands anyway: a record proving an approval happened is only as trustworthy as the write path into the table that holds it. While the window was open, every record in an unpatched, internet-facing instance was a claim, not proof.

These are two different statements: the vendor has seen no exploitation, and our approval history is provably untouched. ServiceNow can honestly say the first. The second requires integrity evidence stored somewhere the bug could not reach — and if your audit trail lives only inside the instance, it can never be more trustworthy than the instance itself.

What we’d check this week

Questions worth asking anywhere an approval system of record runs, not just on ServiceNow.

  • Confirm your instance is at or above the fixed version for its release line, using the table in the advisory. Hosted customers were patched by the vendor — verify rather than assume.
  • Map what is reachable without login. Service portals are often public by design; check whether GraphQL and upload endpoints face the internet or sit behind IP allowlists and a WAF.
  • Pull transaction logs for the pre-patch window and look for unauthenticated requests to GraphQL composite endpoints, image upload processors, and list queries with odd sort parameters.
  • Pick five recent access grants provisioned off ServiceNow approvals and check them: does each one trace back to an approval a human recognizably initiated?
  • Ask where a copy of your approval and audit records exists that this class of bug could not have touched — an off-instance export, an immutable store, anything. If the answer is nowhere, that is the finding, regardless of this CVE.

Sources

Axowl builds identity and audit infrastructure where approval records are sealed as they are written, so their integrity can be shown independently of the platform that stores them. How it works.

#servicenow #privilege-escalation #sql-injection #audit-trail #system-of-record