The published proof-of-concept and the real attacks hit the same endpoint through two different doors — which is why patching alone didn't close this one.
ServiceNow patched a critical remote code execution bug for its cloud customers back in April, and told self-hosted customers about it — and gave them the fix — on July 13. Attackers started actively exploiting it four days later. Worse, the attacks aren't even using the same trick as the public proof-of-concept researchers published. They found their own way through the same door. The vulnerability is CVE-2026-6875, a 9.5-severity sandbox escape in ServiceNow's AI Platform, and if you run a self-hosted instance, the patch timeline alone should worry you as much as the bug itself.
How an unauthenticated request turns into code execution
The entry point is almost mundane: /assessment_thanks.do, a confirmation page ServiceNow's AI Platform shows after someone completes an assessment — the kind of screen you'd click past without a second thought. It takes a parameter called sysparm_assessable_type and passes it straight into a GlideRecord database query without sanitizing it first. GlideRecord queries can evaluate strings prefixed with javascript: as executable code, a capability meant to be sandboxed and controlled, not something an anonymous visitor should ever trigger.
Getting code to run inside that sandbox is only half the win — the real prize is escaping it. Searchlight Cyber's published technique overrides Object.clone with the Function constructor and reaches into AbstractAjaxProcessor.prototype so that a later, ordinary-looking call to gs.include() executes in a fully unsandboxed context. That's a sandbox escape. Running a script inside GlideRecord's controlled context is one thing; reaching a state where gs.include() runs unrestricted is the difference between staying fenced in and having the run of the whole instance, including whatever tables and connected integrations it can reach.
The gap that mattered: three months of self-hosted exposure
Here's the part that should bother self-hosted ServiceNow customers specifically. Cloud-hosted instances got protected in April, within roughly a day of Searchlight Cyber's report — ServiceNow controls that infrastructure directly, so it could patch centrally without waiting on anyone. Self-hosted instances are a different story: those patches, and any public knowledge that the bug existed, didn't arrive until July 13, more than three months later. For that entire window, every self-hosted ServiceNow AI Platform instance carried an unauthenticated RCE that ServiceNow itself already knew about and had already fixed for its own fleet. My take: cloud-first patching is good practice, but leaving self-hosted customers in the dark for three months on a 9.5 unauthenticated RCE is hard to defend, whatever the internal reasoning was.
Then it got worse, fast. Public disclosure on July 13 put the technical details — including the vulnerable endpoint and parameter — into the open. By July 17, Defused researchers were already seeing exploitation attempts, and by the weekend they'd confirmed real attacks were using a different sandbox-escape gadget than the one in the published PoC, while hitting the exact same /assessment_thanks.do entry point. ServiceNow's own public position, per the reporting, was that it was 'not currently aware of exploitation against ServiceNow instances' — a statement that reads oddly next to researchers who'd already confirmed otherwise.
Searchlight Cyber privately reports the sandbox-escape RCE to ServiceNow.
April 2026
ServiceNow patches all cloud-hosted AI Platform instances directly — no customer action needed.
Jul 13, 2026
Patches and public disclosure finally reach self-hosted customers, roughly three months after cloud instances were fixed.
Jul 17–18, 2026
Defused researchers observe the first real exploitation attempts against unpatched self-hosted instances.
Jul 18–19, 2026
Confirmed attacks use a different sandbox-escape gadget than the published proof-of-concept, hitting the same endpoint.
What to do if you run ServiceNow AI Platform
Confirm whether your instance is self-hosted — if so, verify the July 13 patch is actually installed; don't assume it arrived automatically the way cloud customers' fixes did.
2
Enable ServiceNow's Guarded Script feature, which restricts what sandboxed code execution contexts are allowed to reach.
3
Review access logs for requests to /assessment_thanks.do with unusual sysparm_assessable_type values, especially anything containing javascript: — going back to July 13, not just the last few days.
4
Treat any self-hosted instance that was internet-reachable between July 13 and patching as potentially compromised, not just 'now patched' — loop in ServiceNow's incident response help if you find anything.
ServiceNow CVE-2026-6875: quick answers
Does this affect ServiceNow's cloud-hosted instances too?
Those were patched directly by ServiceNow back in April, within about a day of the report. The ongoing risk is specifically for self-hosted / on-prem deployments that didn't receive a fix until July 13.
Do I need to be authenticated for an attacker to exploit this?
No — that's the point of the CVSS 9.5 rating. The vulnerable endpoint, /assessment_thanks.do, doesn't require a login.
Is patching alone enough?
Patch first, but also check logs back to July 13 and confirm Guarded Script is enabled, because live attackers are using a different technique than the one most WAF rules were probably written against.
Why did ServiceNow say it wasn't aware of exploitation?
That statement predates or contradicts independent findings from Defused researchers, who'd confirmed live attacks days earlier. Don't treat a vendor's 'not aware' as equivalent to 'not happening' — verify your own logs.
Detection tuned only to the public proof-of-concept missed the version attackers actually used — a reminder that a known PoC isn't the same as full coverage. · Unsplash
The technical bug here is bad enough on its own — an unauthenticated path to a full sandbox escape always is. What actually made CVE-2026-6875 dangerous was the three-month gap between 'ServiceNow knows and has fixed this for itself' and 'self-hosted customers get told anything at all,' the same shape of problem that made the Windows AD FS zero-day so damaging weeks earlier. If you're running ServiceNow AI Platform on your own infrastructure, that gap is the real lesson: cloud-first vendors patch their own fleet fast because they can, and self-hosted deployments quietly inherit whatever timeline is left over. Check your patch level today, not after the next headline.
