Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Get Started ↗ JA
Home / Critical Brief / No. 138

Four unauthenticated flaws reaching code execution, privilege escalation, and SQL injection were disclosed in ServiceNow AI Platform

a third disclosure, still with no layer that checks authorization before the action

Incident date
2026-08-27
Published
2026-09-01
Authors
Lemma Critical Team
Related Pack
Pack A · Incident Response

TL;DR

On August 27, 2026, ServiceNow disclosed four unauthenticated, exploitable vulnerabilities in its AI Platform. Three carry a ServiceNow-assigned CVSS of 10.0 — GraphQL code injection, improper access control in the image upload processor, and SQL injection through a dynamic schema ORDER BY clause — and the sandbox escape 8.7. The three require neither authentication nor user interaction. Detection and remediation were fast. What was missing was a layer that independently verifies an unauthenticated request’s authorization before it reaches code-execution or data-modification logic.

What happened

  • ServiceNow disclosed four vulnerabilities affecting multiple AI Platform (formerly Now Platform) releases in an August 27, 2026 security bulletin (KB3152242): CVE-2026-18885, CVE-2026-18886, CVE-2026-74820, and CVE-2026-6876.
  • The three scored 10.0 require neither authentication nor user interaction and are remotely reachable over the network. For the fourth, the prose says an “unauthenticated user” could execute arbitrary code, while the vector ServiceNow assigned to the same flaw specifies PR:L (low privileges required) — the description and the vector do not agree.
  • The three 10.0 flaws share 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 — network-reachable, low complexity, no privileges, no user interaction, high impact to both the vulnerable component and the systems connected to it. The 8.7 sandbox escape differs on two counts: privileges are PR:L, and no impact is recorded beyond the component itself (SC:N/SI:N/SA:N).
  • ServiceNow applied fixes to hosted instances and released hotfixes for self-hosted and partner deployments across the Xanadu, Yokohama, Zurich, and Australia release families.
  • The CVSS scores are ServiceNow’s own. The company is the CVE Numbering Authority for its products, and since April 15, 2026 NIST has prioritized for enrichment the vulnerabilities that appear in CISA’s Known Exploited Vulnerabilities catalog, affect federal government software, or are designated critical under Executive Order 14028, treating everything else as lowest priority and not enriching it immediately. No score cited here is an independent third-party assessment.

The attack can be assembled as follows.

  1. An unauthenticated attacker sends a crafted request to the GraphQL Composite Data API (CVE-2026-18885, ServiceNow-scored 10.0). Improper input handling lets the injected code execute directly on the instance, reaching and modifying instance data.
  2. In parallel, the system configuration image upload processor lacks proper access control, letting an unauthenticated user create or modify instance data and escalate privileges (CVE-2026-18886, 10.0).
  3. User-supplied input is incorporated into a dynamically built schema ORDER BY clause without sanitization, making SQL injection against the underlying database reachable over HTTP(S) (CVE-2026-74820, 10.0).
  4. Separately, a sandbox boundary can be crossed, reaching code execution (CVE-2026-6876, 8.7). ServiceNow’s prose says this is reachable unauthenticated, but its vector requires low privileges; the two premises do not match.

Timeline — disclosure and response

  • 2026-04-01: Searchlight Cyber reports CVE-2026-6875, an unauthenticated sandbox escape in the same platform, to ServiceNow.
  • 2026-07-13: ServiceNow publishes the advisory for CVE-2026-6875 (ServiceNow-scored 9.5; every metric matches the three above except attack complexity, set to high).
  • 2026-07, days after that advisory: threat intelligence firm Defused says it is observing in-the-wild exploitation of CVE-2026-6875. It subsequently issued a correction, stating that the captured payload matched Searchlight Cyber’s published proof-of-concept exploit.
  • 2026-08-27: ServiceNow publishes all four of the current CVEs in KB3152242 and ships hotfixes.

This timeline treats ServiceNow’s own bulletin (KB3152242) as primary, with technical detail drawn from that bulletin and independent analysis (IONIX). As noted above, the CVSS scores are ServiceNow’s own and carry no independent NVD assessment. The claim that it is “not currently aware” of exploitation is ServiceNow’s own; no independent third-party confirmation was available at the time of writing. The Hacker News reported that it found no public exploit code for the three maximum-severity flaws as of August 28, 2026.

Response and developments:

  • ServiceNow states that hosted-customer remediation is complete, and offers patched versions for self-hosted and partner deployments. For self-hosted instances, the decision and the work remain with the customer.
  • The Hacker News covered the advisory the next day (2026-08-28) and SecurityWeek a few days later (2026-08-31). Both note that the three 10.0 flaws are reachable without authentication or user interaction, and The Hacker News also flags the mismatch between prose and vector on the fourth.

Why it wasn’t stopped

This incident’s failure is neither slow patching nor unusually sophisticated bugs. Across multiple entry points into the platform — the GraphQL API, the image upload processor, dynamic query construction, and the sandbox boundary — no layer consistently verified a request’s authorization before it reached code-execution or data-modification logic.

Detection worked. All four were found before publication, hotfixes were ready alongside the advisory, and hosted instances were already patched (no finder is named for this set of four). What was missing sat one step earlier: a way to confirm, as a platform-wide boundary rather than a per-feature implementation detail, whether a request was authenticated and within its intended scope. Where every new entry point adds one more verification implementation, a single gap in one of them is itself unauthenticated reach.

On the same AI Platform, Brief 046 covered unauthenticated access from a misconfiguration, and Brief 109 covered unauthenticated sandbox-escape-to-code-execution (CVE-2026-6875). This is the third disclosure. Each vulnerability is independent, but the recurring shape is the same: as new functionality ships, nothing outside the feature itself confirms that reaching it is authorized, and individual input-validation and access-control gaps accumulate.

Whether exploitation was observed is a separate question from that shape. The reported in-the-wild exploitation of July’s CVE-2026-6875 was later corrected, with the captured payload attributed to a published proof of concept. The absence of exploitation evidence does not weaken the fact that unauthenticated entry points keep being found.

What proof would have changed

Proof before the action replaces “was this entry point’s validation written correctly?” with “could this request’s authorization be independently verified?” as the basis for running platform functionality. Rather than requiring every entry point to be written correctly, it inserts a step that can be checked before the action even where they are not.

The design Lemma offers against this gap:

  • Authorization proof before the action: independently verify and prove a request's authorization before it reaches platform functionality (APIs, upload processors, query construction).
  • Applied as a boundary: apply that proof as a platform-wide boundary rather than leaving it to per-feature implementation, so adding entry points does not add checks to get right.
  • Provenance binding: bind the provenance of the resulting action — code execution, data modification — to the authorization proof that permitted it.

What it does not do:

  • It does not detect or patch the individual CVEs. That is the vendor's and the researchers' work.
  • It does not substitute for or guarantee ServiceNow's internal implementation. This layer sits after that, keeping an implementation gap from turning unauthenticated reach into an action.
  • Proof can show only that a request is authorized — not that an authorized user's action was appropriate.

The difference from your own access logs is here: a log remains after the request is processed, but it is not material for deciding, at the time of the action, whether that request should have been processed.

Detection and this layer are complementary, not substitutes. The former finds vulnerabilities and reduces the number of entry points; the latter makes “functionality does not run until authorization is verified” something you can check before the next entry point is found.

Sources

“The last layer left in AI-era cyber defense”Pillar 03 — Agent Authority

All CVSS scores here are ServiceNow’s own, assigned as the CNA for its products; no independent NVD assessment accompanies them. Exploitation status reflects the company’s own statement.

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"Four unauthenticated flaws reaching code execution, privilege escalation, and SQL injection were disclosed in ServiceNow AI Platform — a third disclosure, still with no layer that checks authorization before the action".
Lemma Critical Brief No.138. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/138-servicenow-ai-platform-quad-cve/
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.