The Politest RCE: A Pre-Auth "Thank You" Page Escaped ServiceNow's AI Sandbox (CVE-2026-6875)

I have a hobby that is not, strictly speaking, a hobby: I open pages I have no business opening and read them like a menu. Not to break in — just to see what a machine is willing to say to a stranger. Most enterprise software says "401" and shows me the door. So imagine my delight when the platform that runs help-desk tickets for what feels like every large company on earth answered a pre-authentication request with, essentially, a polite little note: thanks for completing the assessment.

That page is /assessment_thanks.do. It is the front porch. This is the story of what was behind it — a sandbox escape called CVE-2026-6875 — and how it went from "huh, weird" to "this touches 85% of the Fortune 500" in about four paragraphs. Credit where it's due: I did not find this. Adam Kues and Searchlight Cyber did, and reported it on April 1, 2026. I just went down the rabbit hole of their writeup so you don't have to.

Act 1: It started with a thank-you page

/assessment_thanks.do is reachable before you log in. On a healthy day it renders a cheerful confirmation and nobody thinks about it again. But "reachable before you log in" is a phrase that makes vulnerability researchers sit up straight, because a pre-auth endpoint is a doorbell that anyone on the internet can ring. The question is never "can I reach it" — it's "what does it do with what I hand it."

Act 2: …and then it got worse — the sandbox had a door

ServiceNow runs a lot of customer and platform logic as server-side JavaScript inside a sandbox — a fenced-off script context that is supposed to let code run without letting it touch the host. CVE-2026-6875 is classified CWE-94, code injection: the flaw lets an unauthenticated request break out of that sandbox and execute arbitrary code on the platform. Sandbox escape is the polite industry term for "the fence had a gate and the gate was unlocked."

Once you're out of the sandbox you're not in a demo. Searchlight's writeup and the vendor advisory both describe the payoff bluntly: full compromise of the ServiceNow instance and any connected proxy servers. On an ITSM platform, the instance is the crown jewels — it's wired into identity, tickets, change management, and a pile of stored integration credentials.

Act 3: …and worse — it's not one door, it's a hallway

Here's the part that turns a patch note into a drop everything memo. Searchlight's research describes not a single fragile exploit, but multiple viable gadget paths to the same code-execution primitive. Their published proof-of-concept is one route. That matters enormously for defenders, because the obvious instinct — write a WAF rule that matches the exact payload structure in the PoC — only closes the one door you can see.

About that "exploited in the wild" — let's do a reality check

This is where I have to be honest, because the story got a wrinkle and pretending it didn't would be exactly the kind of thing I hate reading. On the weekend after the July 13 disclosure, the threat-intel firm Defused reported POST requests hitting /assessment_thanks.do in the wild and warned of active exploitation. Their first read was that the payload reached the primitive by a different route than the published PoC. They then issued a correction: the captured payload in fact matched Searchlight Cyber's public PoC.

So the sober version is: real, unauthenticated exploitation attempts against the vulnerable endpoint were observed within days of disclosure, using the public proof-of-concept. Meanwhile ServiceNow states it has not seen evidence that this activity is tied to instances it hosts — which is consistent, because those were mitigated back in April. The people in the blast radius are the self-hosted and partner-hosted crowd who had to apply the July 13 fix by hand. "Days from public PoC to public scanning" is not a surprise; it's the base rate. It's also the entire argument for patching before you finish reading this sentence.

Why our exploit column looks quiet while EPSS is screaming

If you pull CVE-2026-6875 up in the cve.tools index you'll notice something that looks like a contradiction: the exploit column is empty — has_public_poc: false, zero Metasploit modules, zero Nuclei templates — yet EPSS sits at the 97.6th percentile. Both are true at once, and the gap is the lesson.

What to actually do (self-hosted / partner-hosted)

If ServiceNow runs your estate for you, exhale — the hosted fleet was handled in April. If you run it yourself, the fix is a specific patch or family release. Map your version to the fixed line below and apply it; there is no meaningful workaround that closes every gadget route the way the patch does.

1. Apply the fix for your release train (advisory KB3137947). Confirm the Guarded Script restrictions are active post-upgrade.
2. Assume credential exposure, not just code exposure. A compromised instance can read stored integration secrets — rotate them.
3. Rotate credentials for anything the instance can reach, especially connected proxy / MID servers, which the advisory explicitly names as in-scope for full compromise.
4. Hunt your access logs for pre-auth POSTs to /assessment_thanks.do around and after July 13, 2026.
5. If you find hits you can't explain, treat it as a potential intrusion — the public PoC was seen used in the wild, so this is not theoretical.

grep -iE 'POST[^"]*/assessment_thanks\.do' access.log \  | awk '{print $1, $4, $7}' \  | sort | uniq -c | sort -rn | head

CVE data & exploitation status current as of 2026-07-31

So: a page whose entire job is to say thank you turned out to be the front porch of an unauthenticated sandbox escape into the platform that runs the help desk for most of the Fortune 500. The disclosure timeline is tidy — reported April 1, cloud fixed in ~24 hours, self-hosted patched July 13, exploited-with-the-public-PoC by the following weekend. My one takeaway, printed on a tiny imaginary plaque: the friendliest endpoint in your estate is exactly the one nobody's watching. ¯\\_(ツ)_/¯ Patch the porch.