Three tens in one advisory, and nobody has seen them used

Four flaws, three perfect scores#

On 27 August 2026 ServiceNow published a single advisory, KB3152242 covering four vulnerabilities. Three carry a CVSS version 4.0 base score of 10.0, the maximum, and all three are reachable by an attacker with no credentials and no user interaction.

The three are specific, and the titles do the explaining. CVE-2026-18885 is unauthenticated remote code execution in the GraphQL Composite Data API. CVE-2026-18886 is unauthenticated privilege escalation through the system configuration image upload processor. CVE-2026-74820 is unauthenticated SQL injection via a dynamic schema ORDER BY clause.

All three share an identical vector string in the National Vulnerability Database: network attack vector, low complexity, no privileges, no user interaction, and high impact across confidentiality, integrity and availability, including on subsequent systems. That last clause is the one that turns a product bug into a third party risk management question.

Two of the three were reported by outside researchers at Assetnote, credited by name in the CVE records: Adam Kues on the remote code execution and Kevin Gervot on the privilege escalation. The SQL injection carries no external credit, which usually means it was found in-house. For anyone doing third party risk management, that mix is reassuring rather than alarming: a vendor finding its own flaws is a vendor with somebody looking.

The fourth, CVE-2026-6876, is a sandbox escape in the Now Platform scored 8.7. It needs low privileges rather than none, and its impact stops at the vulnerable component. Serious, but a different shape of problem.

Why a workflow platform is a different kind of dependency#

A vulnerability's severity score describes the flaw. It does not describe what sits behind it. ServiceNow is where a great many large organisations run service management, and increasingly their governance, risk and compliance workflow too, which means the system holding your control evidence is itself a control.

The scale is in the company's own filings rather than a vendor deck. ServiceNow reports the number of customers paying more than five million dollars a year, counted by unique Dun and Bradstreet global ultimate identifier. In its annual report that figure was 420 at the end of 2023, 502 at the end of 2024 and 603 at the end of 2025. Its most recent quarterly filing puts it at 658 by 30 June 2026, against 533 a year earlier.

The fixes span four release families, which is the detail that turns this from a version bump into a scheduling problem. Patched builds were published across the Xanadu, Yokohama, Zurich and Australia trains, so an estate running several versions has several different pieces of work, not one. Third party risk management that assumes a single upgrade path will underestimate this every time.

This is the practical content of supply chain risk management in 2026. The question is not whether your vendor is reputable. ServiceNow is reputable, found these itself, and shipped fixes across four release families in one advisory. The question is what a total compromise of that vendor's platform would reach inside your estate, and whether you have ever written that down.

What the disclosure clock shows#

Every CVE record carries two dates: when the identifier was reserved and when the record was published. The gap is a rough proxy for how long a fix took, and in this set the gaps are not alike.

ServiceNow assigned every one of these identifiers itself, as a CVE Numbering Authority whose scope covers all its products including end-of-life ones. A vendor that can name its own flaws is a vendor with a functioning process, which is a point in its favour rather than against it, and a genuinely useful signal in any third party risk management review.

The 127-day gap on the sandbox escape is not evidence of negligence. An identifier is often reserved early, and a lower-severity issue reasonably waits for a scheduled release train. It is simply a reminder that an advisory date is a publication event, not a discovery date, and that the trail behind each entry runs back further than the headline suggests.

None of these appear on CISA's Known Exploited Vulnerabilities catalogue. That absence is correct, because the catalogue records vulnerabilities known to be exploited, and these are not. It is also the reason a patching programme keyed only to that catalogue would not touch any of them.

What third party risk management should do with this#

Start with who patches. ServiceNow says customers in its patching programme received the update, and tells self-hosted customers to apply it promptly. That single sentence splits your estate in two, and most organisations cannot answer quickly which side each of their instances is on. Answering that is vendor risk management at its least glamorous and most useful.

That split is where most third party risk management registers go stale. They record the vendor, the contract and a due-diligence questionnaire from eighteen months ago, and they do not record which instances exist, who patches them, or how to reach the person who would. None of those facts are hard to gather. They are just nobody's job until the morning an advisory lands.

Then the reachability question. An unauthenticated flaw matters far more on an instance exposed to the internet than one behind a private network. The vector says network-reachable; only your own architecture says whether that network is the public one.

Then the blast radius. All three tens are scored with high impact on subsequent systems, meaning the platform is a route onward rather than a destination. If your workflow platform holds credentials, integrations or approval authority for other systems, then good third party risk management treats a compromise there as a compromise of everything it can reach.

Finally, the awkward one for anyone marketing in this category. ai security risks are usually sold as something exotic: prompt injection, model theft, agentic misbehaviour. Three of the four flaws here are code injection, broken access control and SQL injection, which are the oldest categories in the book. The AI in ai platform security named the product, not the vulnerability class.

The honest read, caveats included#

It would be easy to write this story as a near miss and imply consequences that have not happened. They have not. The trail here is cold on purpose, and saying so plainly is what makes the rest of the piece worth trusting.

There is a marketing lesson buried in that restraint. Security vendors will quote these three scores in campaigns within the week, and most of that copy will imply an active threat that no source supports. A buyer who checks the primary record will notice, and third party risk management audiences are exactly the people who check. Overstating a quiet advisory is how a security brand loses the technical reader it most needs.

The lesson is not that ServiceNow is unsafe. It is that a platform which concentrates workflow also concentrates consequence, and that the paperwork proving you are in control frequently lives inside the thing you would need to prove it about. That is worth a paragraph in your next board pack, and it is the same argument folkfox makes to every client in our cybersecurity practice.

Patch, check which side of the hosted line each instance sits on, and write the reachability answer down while it is fresh. A quiet week is exactly when that work is cheap, and third party risk management done in a quiet week costs a fraction of the same work done in a loud one.

The den you never inspect is the one with the gap in the back. Walk the trail once while nothing is chasing you: list the instances, name the patcher, mark the ones facing the open network, and note what each could reach if it fell. The fox that checks the hedgerow before the hunt is the one still there at twilight, and the quarry here is simply an honest answer, written down.

Frequently asked questions#