ServiceNow disclosed four vulnerabilities on 27 August, three of them rated the maximum possible severity: CVSS 10.0. CVE-2026-18885 is a code-injection flaw in the platform's GraphQL Composite Data API; CVE-2026-18886 is an access-control gap in the configuration image upload processor that lets an attacker escalate privileges; CVE-2026-74820 is a SQL-injection flaw reachable through a dynamic schema ORDER BY clause. All three can be triggered by an unauthenticated attacker in a low-complexity attack with no user interaction required, and together they let an outsider run arbitrary code or read and modify data directly in the underlying database. A fourth, lower-severity flaw (CVE-2026-6876, CVSS 8.7) needs an existing foothold but then allows a sandbox escape into full remote code execution.
ServiceNow says its own hosted instances are already patched, and it has released fixes across the Xanadu, Yokohama, Zurich and Australia release branches for customers who run self-hosted or partner-managed instances. As of 28 August the company reports no confirmed active exploitation and no public proof-of-concept code. That is a genuine head start, not a reason to relax: ServiceNow instances have been targeted before, including an exploited flaw earlier this year, precisely because the platform sits on so much valuable data — IT service tickets, HR case records, customer support conversations — for organisations of every size, not only the largest enterprises.
What this means for your business
- If your business runs ServiceNow for IT support, HR cases, or customer service, find out today whether your instance is ServiceNow-hosted (already patched) or self-hosted / managed by your own team or an integration partner (needs action now).
- These are unauthenticated, internet-facing flaws — the worst combination for any system, because no stolen password or insider access is required to exploit them. Treat "critical, unauthenticated, patch available" as a same-week task, not a routine update.
- Ask whoever administers the instance to confirm the exact release branch and patch level against ServiceNow's own advisory. "We're on Zurich" isn't specific enough — the required patch depends on the exact version and patch number.
- No exploit code exists publicly yet, and that window typically closes within days of a disclosure like this one. The absence of an attack today is the best argument for patching this week, not a reason to wait.
The lesson here isn't really about ServiceNow — any vendor, however well-run, can occasionally ship a maximum-severity flaw. What decides the outcome is whether your business already knows which of the SaaS platforms it depends on are patched automatically by the vendor, and which ones are your own team's responsibility. If nobody could answer that question about ServiceNow just now, it's worth asking the same question about every other platform your business runs on before an actual breach forces the audit.