ServiceNow Patched Its Cloud First, You 103 Days Later

The Report Landed on the First of April

On 1 April 2026, Adam Kues of Assetnote, the research arm of Searchlight Cyber, sent ServiceNow a report describing a way to run code on the ServiceNow AI Platform without any credentials at all. The company moved fast. In its own account of the disclosure, the research team records that ServiceNow "deployed strong mitigations to all cloud instances within 24 hours of our report" and followed with patches for the underlying issues in the weeks after. Every customer on a ServiceNow-hosted instance was protected by the start of April, and none of them had to do anything, or even know.

The customers running their own copies heard nothing until 13 July, when ServiceNow published advisory KB3137947 and released updates for self-hosted deployments. The flaw is tracked as CVE-2026-6875. ServiceNow, acting as its own CNA, assigned it a CVSS 4.0 score of 9.5 out of 10. The vector records high attack complexity but no privileges and no user interaction, which is the combination that makes an internet-reachable instance interesting to somebody scanning at scale.

Between those two dates sit 103 days. For a SaaS company that is a well-run coordinated disclosure. For the subset of its customers who run the platform themselves, it is a quarter of a year holding a critical pre-authentication flaw that the vendor had already closed on its own estate.

A Sandbox That Agreed to Evaluate JavaScript

The vulnerability sits in the sandbox of the ServiceNow AI Platform, the containment layer that is supposed to let platform code run without reaching anything it should not. The entry point is the GlideRecord API, which supports JavaScript evaluation inside query filters. User-supplied input reached an addQuery call carrying the javascript: prefix, and the platform evaluated it.

A secondary sandbox was meant to catch exactly this and block dangerous functions. The researchers got past it with a gadget chain built from Object.clone and Class.create.constructor, which together yield arbitrary function execution during script includes. The demonstrated entry point was the /assessment_thanks.do endpoint by way of its sysparm_assessable_type parameter, and none of it required a login.

What that buys an attacker is not a foothold in a corner of the product. Searchlight's write-up describes reading data out of tables, creating administrator accounts, and running shell commands on any configured MID Server proxies, which, as the researchers note, commonly sit inside companies' internal networks. The MID Server is the piece that reaches back into your estate to discover assets and run automation. It is the bridge, and the bridge is reachable from the bug.

Who Actually Held the Risk

The usual instinct in European boardrooms is that self-hosting is the conservative option. You keep the data on your own tin, you satisfy the residency question in one sentence, and you avoid handing a regulator an awkward diagram. In regulated sectors across the EU, in public administration, in banking, and among the larger Mittelstand groups, that instinct is why a meaningful share of ServiceNow estates are not on ServiceNow's cloud.

This advisory inverts that. The customers who chose the vendor's cloud were protected in the first days of April by a mitigation they never had to request. The customers who chose to run it themselves, for control, carried an unauthenticated remote code execution flaw through April, May, June and half of July, and were only told once the fix was ready to ship. Control over the deployment turned out to mean ownership of the exposure window.

None of this makes ServiceNow's handling improper. Shipping mitigations to an estate you operate is simply faster than shipping patches to an estate you do not, and holding advisory detail until customers can act is standard practice rather than concealment. The operator lesson is narrower and more useful: "the vendor has fixed it" and "we are fixed" are two different statements, and in this case a hundred days sat between them.

Both Statements Are True at the Same Time

Over the weekend of 18 and 19 July, the threat intelligence group Defused reported active exploitation, with the first attempts observed on Friday 17 July. ServiceNow's advisory, as of Monday morning, still states that it is "not currently aware of exploitation against ServiceNow instances." Read side by side, that looks like a vendor being slow to concede.

It is more interesting than that, and the reconciliation is the point of this story. The two parties are measuring different populations. ServiceNow has direct telemetry on the estate it hosts, and that estate has been mitigated since early April, so genuinely nothing is being exploited there. Defused watches traffic across the internet, which is where the self-hosted instances live. The population the vendor cannot see is precisely the population that is still unpatched.

So the vendor's sentence is accurate and simultaneously useless as a risk input for you. "No confirmed exploitation" from a SaaS provider is a statement about the provider's own estate unless it explicitly says otherwise. If you run the software yourself, the only exploitation status that describes your situation is the one you derive from your own logs.

The Exploit Did Not Wait for the Proof of Concept

Defused was specific about what it saw. The payloads, it reported, "hit the same pre-auth sink @SLCyberSec documented (/assessment_thanks.do), but the sandbox-escape gadget reaches the same code-execution primitive by a different route than their published PoC." Attackers were not replaying the researchers' exploit. They had reached the same primitive independently, having done their own work from the same starting point.

That detail dismantles a scheduling habit that is common in change-controlled shops: treat the appearance of a public proof of concept as the moment the clock starts, and patch on the next window after that. Here the independent capability arrived alongside the public analysis rather than after it, and the advisory itself, on 13 July, was the last reliable warning anybody was going to get.

What to Check Before Tuesday

Start with the release family, because the fix names are not intuitive. The patched versions are Brazil EA and Brazil GA, Australia Patch 2, Zurich Patch 7b or Zurich Patch 9, and Yokohama Patch 12 Hot Fix 1b or Yokohama Patch 13. Anything below the relevant line is vulnerable, and a self-hosted instance that has not had a maintenance window since 13 July has not been fixed by anyone on your behalf.

Then assume the window mattered. Pull access logs for /assessment_thanks.do and look at the sysparm_assessable_type parameter specifically. Review administrator account creation across the whole period rather than the last fortnight, because the flaw allows an attacker to make one. Then go to the MID Servers, check for unexpected process execution, and remember that those hosts sit inside the internal network rather than in front of it, which is what turns a platform bug into a lateral movement problem.

If you find anything, the clock is regulatory as well as technical. For essential and important entities in the EU, NIS2 requires an early warning to your national CSIRT within 24 hours of becoming aware of a significant incident and a fuller notification within 72 hours. In the UK, where NIS2 does not apply, the NCSC remains the reporting route and the same evidence work is what makes the report worth filing.

Read next: One Request Could Hijack Your WordPress Site  |  Patching SharePoint No Longer Closes the Door