TL;DR - On Thursday 28 August 2026 ServiceNow disclosed three CVSS 10.0 vulnerabilities in the AI Platform, including unauthenticated SQL injection and unauthenticated code injection. ServiceNow pushed the fix to its hosted customers the same day. Self-hosted ANZ enterprises running ServiceNow on their own hardware are now weeks behind unless the IT-pro who owns the instance pulls the patch this week. The flaws are tracked as CVE-2026-18885, CVE-2026-18886, and CVE-2026-74820, all rated low complexity and requiring no user interaction. What you need to do: (1) confirm whether your ServiceNow instance is hosted by ServiceNow or self-hosted on your own hardware, (2) if self-hosted, pull the latest patch from the ServiceNow Now Support portal and apply it inside the next five business days, (3) audit the AI Platform integration for any inbound traffic that reaches the AI agent endpoints, and (4) check the access logs for the last 14 days for unauthenticated requests against the AI Platform paths.
I was on a video call last Friday with a customer's ServiceNow admin when he mentioned, almost in passing, that they had rolled the new AI Platform out to 14,000 support agents two weeks earlier. He said it the way people say things that have been working fine: a small smile, a half-nod, the body language of someone who has just shipped a major upgrade and is waiting for the next thing to go wrong.
Then I told him about the 28 August advisory. The smile did not last.
Three maximum-severity CVSS 10.0 vulnerabilities had landed on the AI Platform the previous day. ServiceNow had patched its own cloud and pushed the fix to hosted customers the same afternoon. The customer was self-hosted, the patch was sitting on the ServiceNow Now Support portal waiting for someone to download it, and the only person at this customer with admin on the instance was the guy on the call.
If you are the IT-pro who owns a self-hosted ServiceNow instance for an ANZ enterprise, an MSP that runs ServiceNow for customers, or a university or government department that runs ServiceNow on its own infrastructure because the data has to stay on the box, this is the post for the next five business days.
By The Numbers
| Metric | Detail |
|---|---|
| Vendor advisory date | 28 August 2026 (Thursday) |
| Vulnerabilities disclosed | 3, all rated CVSS 10.0 |
| CVE identifiers | CVE-2026-18885, CVE-2026-18886, CVE-2026-74820 |
| Vulnerability classes | Code injection, SQL injection, privilege escalation |
| Affected product | ServiceNow AI Platform (includes Integration Hub and AI Agent components) |
| Authentication required | None - unauthenticated remote attacker |
| User interaction | None |
| Attack complexity | Low |
| Hosted customers patched by | 28 August 2026 (same day) |
| Self-hosted customers patched by | Whenever the IT-pro pulls it |
| Enterprise footprint | ServiceNow reports 85% of Fortune 500 companies run its platform |
| ANZ exposure | Every ANZ enterprise on self-hosted Yokohama, Washington DC, or earlier branches with AI Platform enabled |
Why three 10.0s in the same advisory is not a normal week
A single 10.0 in an advisory is rare. Three in the same product, in the same week, against the same subsystem, is something else. Either a research cluster found one flaw and then two more while writing it up, or a vendor knew about a family of related issues and disclosed them together. Either way, the practical effect is the same: the AI Platform surface just got hotter, and a single patch is supposed to close all three.
The other thing worth noticing is the unauthenticated part. ServiceNow runs IT service management, HR service delivery, customer service management, and now the AI Platform that automates ticket triage, summarisation, and code generation across those surfaces. Every ServiceNow instance has a public-facing component, usually behind a reverse proxy, usually reachable from inside the corporate network, often reachable from the public internet through a vendor portal or a partner integration. A 10.0 that is unauthenticated, low complexity, and does not require user interaction is the worst combination the CVSS calculator produces.
An unauthenticated, low-complexity, no-user-interaction 10.0 is the score you give a flaw that an automated scanner can find and exploit overnight. ServiceNow has three of them in one advisory.
I am writing this on a Saturday because the news landed on Thursday and the self-hosted patch window started on Friday. Most ANZ enterprises run their change advisory board on a Wednesday or Thursday. If you wait for the next CAB, you are already ten days behind the hosted customers. If you wait for the next maintenance window after that, you are three weeks behind, which is also when proof-of-concept exploit code usually starts landing on GitHub for vulnerabilities this severe.
The three flaws, written down so the patch notes make sense
The BleepingComputer writeup and the ServiceNow advisory together name the three CVEs and the rough shape of each. These descriptions are at the level an IT-pro needs to explain the patch to a CAB.
CVE-2026-18885 - unauthenticated code injection in the AI Platform agent runtime. The flaw lets a remote, unauthenticated attacker inject code through the AI agent processing pipeline and have it executed inside the ServiceNow server context. The attacker does not need a ServiceNow account, does not need to interact with a user, and does not need anything except a network path to the AI Platform endpoint. Execution happens inside the ServiceNow application server, so the attacker lands with the privileges of the ServiceNow service account, which is usually high-privileged on the host and often has database owner rights on the underlying MariaDB or PostgreSQL instance.
CVE-2026-18886 - unauthenticated SQL injection against the AI Platform data layer. This one lets an unauthenticated attacker inject SQL through an AI Platform endpoint that does not properly parameterise the query construction. Because the AI Platform calls the database on behalf of the user, the SQL injection runs in the context of the AI Platform service account. The realistic outcome from a successful exploit is full read and write on the ServiceNow database, which is where every ticket, every CMDB record, every user account, and every integration credential lives.
CVE-2026-74820 - privilege escalation within the AI Platform service context. This one lets an attacker who has reached the AI Platform, whether via a different exploit or a legitimate low-privilege user, escalate to a higher-privileged role within ServiceNow. The escalation is from a basic AI Platform service user to an administrative ServiceNow role with full read and write on the platform. The likely practical use is as a follow-on after CVE-2026-18885 or CVE-2026-18886, turning the initial foothold into platform-wide admin.
ServiceNow shipped one combined patch that closes all three. You do not get to pick. You either install the AI Platform patch or you do not, and the three CVEs close together because they share the same underlying service layer.
Who is in scope, and how to know
Three questions, answered honestly.
Question one: Hosted or self-hosted? If you log into ServiceNow through yourcompany.service-now.com or a similar ServiceNow-managed domain, you are hosted and the patch landed on Thursday. If you log in through servicenow.yourcompany.com or itsm.yourcompany.com or a similar internal hostname, you are self-hosted and the patch is waiting on the Now Support portal.
Question two: Is the AI Platform enabled? It is a separately licensed module. Log in as an administrator and check the AI Platform menu. If the tile is there, you are in scope. If the tile is not there, you are not directly in scope, but check the advisory because some underlying libraries are shared with non-AI Platform components.
Question three: Is the AI Platform endpoint reachable from a path an attacker can control? Most ANZ IT-pros answer this too quickly. The instinct is "no, it is behind the firewall." The reality is usually that the AI Platform endpoint is reachable from the corporate network, which is reachable from any contractor laptop, any compromised user account, any supply-chain integration, and often the partner network through an API gateway that has not been audited this quarter. If the answer is "yes, by some path I do not fully control", the patch is urgent.
The five-day patch window for a self-hosted instance
This is the job for this week. It requires a quiet half-day and the admin credentials for the ServiceNow instance.
Day one - confirm the instance and AI Platform status (30 minutes)
Log in as administrator, find the AI Platform menu, write down the version number from About or System Information. If AI Platform is not present, check the advisory because some underlying libraries are shared. Either way, file a ticket that says "ServiceNow 28 August advisory - in scope check completed, instance X.Y.Z, AI Platform enabled/disabled."
Same session, open the Now Support portal at support.servicenow.com/now. Search for the 28 August advisory by KB number (the prefix KB2XXXXXX for August 2026 security patches is in the BleepingComputer writeup). Download the patch zip and verify the SHA-256 checksum against the value in the advisory before doing anything else with it.
Day two - test the patch in a non-production clone (90 minutes)
If you have a non-production ServiceNow clone, deploy the patch there first. The AI Platform has integration points with at least three other components (Integration Hub, Virtual Agent, Now Assist), and any of those can fail in a way that does not show up on a clean install. The clone test catches integration breakage before production. If you do not have a clone, document that as a finding.
Day three - run the change advisory (30 minutes for the form)
For most ANZ enterprises, a CVSS 10.0 vendor patch is a standard change. The record should include the affected instance, the patch version, the CVE list, the rollback plan, and the test evidence from the clone. If your CAB requires a full meeting, request a 30-minute slot this week specifically for emergency security patches.
Day four - apply the patch to production (60 to 90 minutes per instance)
Apply during your standard maintenance window or a scheduled break in ticket volume. Typical downtime is 30 to 60 minutes depending on instance size and integrations. Have the rollback plan ready and the ServiceNow support contact open. Do not apply on a Friday afternoon. This week is Tuesday, Wednesday, or Thursday.
Day five - verify and hunt (60 minutes)
Verify the AI Platform is back online and integrations are functioning. Pull the access logs for the last 14 days. Look for unauthenticated requests against AI Platform endpoints, unexpected SQL queries in database logs, and ServiceNow role changes that did not come from your admin team. The clean baseline is "no AI Platform requests from anonymous sources, no role changes in the audit log from non-admin accounts."
If you find hits, you have attempted exploitation, not necessarily successful exploitation. Move to incident response: rotate the ServiceNow service account credentials, rotate any database credentials stored in ServiceNow, rotate any integration credentials that ServiceNow stores on behalf of other systems, and pull the full audit log for the affected instance for the last 30 days.
What to do if you cannot patch this week
Two cases do not fit the five-day plan: a heavily customised instance where the AI Platform cannot be tested inside the week, and a regulated environment where the change process requires more lead time.
In both cases, do two things at once. First, deploy a Web Application Firewall rule in front of the instance that blocks all unauthenticated traffic to the AI Platform endpoints. The exact paths are in the BleepingComputer and ServiceNow advisory writeups. A WAF rule that requires authentication before reaching the AI Platform closes the unauthenticated attack path without the patch. This is a temporary measure, not a substitute.
Second, escalate the patch through your emergency change process with the CVSS 10.0 justification. The audit trail matters. If a regulator, insurer, or customer asks in six months why the patch took longer than hosted customers had it, the answer needs to be documented: the patch was risk-assessed, an interim WAF control was deployed, and the full patch was scheduled for the next available maintenance window with the CAB approval timestamp attached.
The hidden risk nobody is talking about
The thing that worries me more than the three CVSS 10.0s is what they say about the AI Platform as a subsystem.
ServiceNow has been adding AI features at a pace that is faster than the underlying platform's hardening cycle. The AI Platform was rolled out broadly in 2025, and the patches since then have been steady rather than alarming. Three CVSS 10.0s in one advisory suggests the AI Platform has had less security review than the rest of the platform, and that the next two or three advisories may carry similar severity scores as the security community catches up to the surface.
If you are an ANZ enterprise that has bet a chunk of your IT operations on ServiceNow, this is the moment to ask your account team two questions. First, what is the cadence of security review for the AI Platform specifically. Second, are there any known or suspected issues that are not yet at the disclosure threshold. The answer to the second question is the more important one, because it tells you whether to plan for a future patch that disrupts your AI Platform usage or whether 28 August is the last big one for the year.
If the answers you get back are vague, that is itself a finding. Document it and decide whether the AI Platform is still the right bet for the workloads you have given it.
What this looks like for an ANZ MSP
If you are an MSP that runs ServiceNow for customers, the patch responsibility is yours, and the audit trail you keep for each customer is the evidence that you took it seriously. The work is the same five-day plan, run once per customer instance, with a per-customer change record that names the affected instance, the patch version, and the verification evidence.
The reason this matters more for MSPs is the insurance angle. Most MSP cyber insurance policies require a documented patch SLA for known critical vulnerabilities, and the SLA is usually days, not weeks. If you are an MSP with a self-hosted ServiceNow customer, and the patch slips past the five-day window, the question you will be asked by the insurer after an incident is not "did you know about the patch" but "what did you do in the first 72 hours." The answer needs to be a documented WAF rule, a documented change record, and a documented escalation to the customer, not "we were waiting for the next CAB."
Mid-week reminder
If you run a self-hosted ServiceNow instance with the AI Platform enabled, today is the day to confirm the patch is on the box. Not tomorrow, not after the long weekend, not after the next CAB. The five-day window starts today. The hosted customers got the fix on Thursday. The gap between them and you is already measurable in days.
If you have read this far and you are also the person in your house who has to explain passkeys to your parents, the free SecureInSeconds quick-start guide covers the controls that change your day in 193 pages of plain English. Pick it up, drop it on the kitchen table, and read the passkeys chapter first.
Further Reading
- BleepingComputer - ServiceNow warns of three max severity security vulnerabilities (28 Aug 2026) - the primary writeup with CVE identifiers and patch details
- The Hacker News - Three CVSS 10.0 ServiceNow Flaws Could Let Unauthenticated Attackors Execute Code and SQL (28 Aug 2026) - second angle on the same advisory with exploitation risk analysis
- ServiceNow Now Support portal - where the patch zip, KB number, and SHA-256 checksum live
- ServiceNow product documentation - the AI Platform reference docs, useful for confirming what is in scope for your instance
- CISA Known Exploited Vulnerabilities catalog - check whether these three CVEs have been added to KEV as the advisory matures
- MITRE CVE database - CVE-2026-18885 - the canonical record for the code injection flaw
- MITRE CVE database - CVE-2026-18886 - the canonical record for the SQL injection flaw
- MITRE CVE database - CVE-2026-74820 - the canonical record for the privilege escalation flaw
Mathew Clark Founder, SecureInSeconds Currently: opening the ServiceNow Now Support portal for my own home lab instance and trying to remember whether I enabled the AI Platform for the family calendar project.
