CRITICAL: ServiceNow AI Platform Pre-Auth RCE (CVE-2026-6875) Under Active Attack

If you run ServiceNow anywhere in your environment, and statistically speaking a lot of you do, this is your drop everything and patch this now moment. A critical flaw in the ServiceNow AI Platform, tracked as CVE-2026-6875, lets an unauthenticated attacker escape the platform's script sandbox and execute code directly on the instance. No credentials, no phishing, no social engineering required. Just a crafted request to an endpoint that was never supposed to hand anyone the keys. As of this past weekend attackers are actively exploiting it in the wild, which moves this squarely out of the theoretical column and into the get on the phone with your team column.

The vulnerability carries a CVSS 4.0 base score of 9.5, which for those keeping score at home is about as red as the dial goes without catching fire. ServiceNow itself issued that score through its role as a CNA, with a vector of CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Translate the acronym soup and it says the attack is fully network reachable, requires no privileges and no user interaction, and once it lands it wrecks confidentiality, integrity, and availability across the board, including components sitting beyond the immediately compromised scope. The one small mercy baked into the vector is an attack complexity marked as high, meaning the exploit is not a copy paste one liner. Searchlight Cyber's Adam Kues, who found the bug, described it as exploitable in high complexity attacks, which is researcher speak for hard but very much doable. And as we have all learned the hard way, hard stops being a meaningful barrier the moment someone publishes the recipe.

At its core this is a sandbox escape dressed up as a code injection flaw. ServiceNow, like most platforms that let customers write their own server side logic, runs that logic inside a restricted execution environment meant to keep tenant scripts from touching the underlying system. CVE-2026-6875 is a break in that wall. An attacker who reaches the right sink can climb out of the restricted sandbox and reach the same code execution primitive the platform reserves for itself. Because ServiceNow is the connective tissue for IT service management, HR workflows, security operations, and increasingly the AI driven automation the product is now named after, breaking out of that sandbox means reaching data and processes that touch nearly every corner of an organization.

The affected release families read like a tour of ServiceNow's naming convention. Anything running before Australia Patch 2, Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13, Zurich Patch 7b, Zurich Patch 9, or the Brazil early availability and general availability builds is exposed. If your team has not tracked exactly which patch train your instance rides on, now is an excellent time to find out, because the difference between patched and vulnerable here is not academic.

The timeline is where this story gets uncomfortable. Searchlight Cyber reported the flaw to ServiceNow on April 1, 2026, and to the vendor's credit the hosted instances it operates directly received a fix quietly during April. Self hosted customers and partners got their patches in June, and the whole thing went public on July 13. For a few days that looked like a textbook coordinated disclosure with a comfortable head start for defenders. Then the weekend of July 18 arrived and the head start evaporated. Threat intelligence outfit Defused confirmed active exploitation, and researchers noted that attackers are hammering the same /assessment_thanks.do endpoint that Searchlight documented, except they are reaching the code execution primitive through a different sandbox escape gadget than the published proof of concept used. In plain terms, the attackers did not just replay the proof of concept. They understood the underlying weakness well enough to build their own path to it, which is the signature of adversaries who are paying attention rather than spraying and praying.

This is what the industry has started calling the collapse of the n-day window. There was a time when a published vulnerability gave defenders weeks, sometimes months, before reliable exploitation showed up in the wild. That cushion is gone. Five days separated public disclosure from confirmed attacks here, and honestly five days is generous by current standards. The gap between a patch dropping and a working exploit circulating is now measured in hours for the flaws attackers actually care about, and a pre-authentication remote code execution bug in a platform this widely deployed is exactly the sort of flaw attackers care about. If your patch cadence still assumes a comfortable buffer after disclosure, that assumption is now a liability.

That distinction between the public proof of concept and the gadget seen in real attacks matters for how you hunt. If your detection strategy is narrowly tuned to the exact indicators from the published exploit, you will miss the variants already circulating. ServiceNow has stated it has not seen evidence tying this activity to the instances it hosts, which is reassuring if you are fully cloud hosted and have confirmed your instance took the April update. It is considerably less reassuring if you run self hosted, operate through a partner, or simply are not certain when your last platform patch landed. The exposure window for self hosted shops stretched from the April hosted fix all the way to whenever they applied the June update, and any instance still unpatched today is a live target sitting on the open internet.

So what do you actually do. The first and most boring answer is the correct one. Apply the vendor patches immediately and confirm they took. Hosted customers should verify with ServiceNow that their instance received the automatic update rather than assuming it did. Self hosted customers should upgrade to an applicable fixed version without waiting for the next maintenance window, because the maintenance window is a luxury that active exploitation does not grant you. ServiceNow also rolled out a feature called Guarded Script that tightens what code is allowed to run in sandbox contexts, and enabling it adds a layer of defense against future escape attempts even after you have patched the specific gadget. For the deeper details the vendor points to knowledge base article KB3137947 for the CVE itself, along with KB2930717 and KB2930740 from the April maintenance cycle.

On the detection side, start by pulling your web logs and looking hard at requests to /assessment_thanks.do, particularly anything with unusual payloads, unexpected parameters, or request patterns that do not match legitimate assessment traffic. Because the endpoint has a genuine function you cannot simply block it, but anomalous volume or malformed requests against it deserve immediate scrutiny. Watch for signs of code execution downstream, unexpected outbound connections from the ServiceNow host, new scheduled jobs, unfamiliar script includes, or business rules that nobody on your team remembers writing. Given that attackers are using their own gadget chains, behavioral detection around what happens after exploitation will serve you far better than signature matching on the entry request alone.

There is a broader lesson tucked into this one, and it is the same lesson the industry keeps failing to internalize. Sandboxes are a control, not a guarantee. Every platform that offers customers the power of arbitrary scripting is making a bet that its containment holds, and every so often that bet loses. The AI branding on ServiceNow's platform does not change the fundamentals. The more logic and automation you concentrate in a single platform, the more devastating a single containment failure becomes. This is not an argument against ServiceNow, which remains genuinely excellent at what it does. It is an argument for treating your most central platforms as the highest value targets they obviously are, and patching them with the urgency that status deserves.

For the MSPs and security shops reading this, a critical pre-authentication remote code execution flaw in a platform this widely deployed is exactly the kind of event that turns a routine client check in into a genuine services conversation. Reach out to every client running ServiceNow, offer a rapid patch verification and exposure assessment, and use the moment to pitch ongoing vulnerability management and continuous monitoring for the platforms that matter most. Clients who just watched a 9.5 severity score go from disclosure to active exploitation in five days tend to finally understand why a managed patch and detection service is worth paying for.