Introduction
ServiceNow AI Platform RCE CVE-2026-6875 is now a live enterprise risk because attackers are exploiting the sandbox escape just days after the self-hosted patch release.
Threat intelligence company Defused confirmed in-the-wild exploitation on July 19, 2026. The first attempts reportedly appeared on July 18, five days after ServiceNow released patches for self-hosted customers on July 13.
Searchlight Cyber researchers at Assetnote discovered the vulnerability and reported it to ServiceNow on April 1, 2026. ServiceNow pushed protections to hosted cloud instances within 24 hours and later released formal self-hosted patches and advisory KB3137947.
CVE-2026-6875 carries a critical severity profile because unauthenticated attackers can escape ServiceNow’s script sandbox and execute arbitrary code remotely. Successful exploitation can expose workflow tables, enable administrator account creation, and extend risk to connected MID Server proxy systems.
This article explains how the vulnerability works, why multiple sandbox-escape gadget chains change the defense equation, which systems face the highest risk, and how enterprise security teams should prioritize response.
For related AI-driven enterprise threat context, see Digital Warfare’s JADEPUFFER agentic ransomware analysis
Why ServiceNow AI Platform RCE Demands Immediate Action
ServiceNow is not a small business application sitting at the edge of the environment. It often connects IT service management, HR workflows, finance approvals, incident response, vulnerability management, enterprise automation, and internal operational processes.
That makes the ServiceNow AI Platform RCE especially dangerous. An attacker who compromises ServiceNow does not simply compromise one web application. They may gain access to the automation layer that connects many sensitive enterprise workflows.
The risk increases when ServiceNow connects to MID Servers. MID Servers bridge the ServiceNow instance to on-premises environments so the platform can run discovery, orchestration, automation, and integration tasks.
If attackers compromise the instance and reach a MID Server, they may gain a path toward internal network resources without needing a separate perimeter exploit.
This is why CVE-2026-6875 belongs at the top of the enterprise patching queue.
What Happened: Discovery, Patch, and Exploitation Timeline
Searchlight Cyber reported CVE-2026-6875 to ServiceNow on April 1, 2026.
ServiceNow responded quickly for hosted customers and pushed protections to hosted cloud instances the next day. That protected cloud-hosted environments while self-hosted patches moved through the formal release process.
On July 13, 2026, ServiceNow published advisory KB3137947 and released patches for self-hosted customers. Searchlight Cyber also published technical research explaining the pre-authentication sandbox escape.
That public disclosure created a short exploitation window. Defused observed exploitation attempts on July 18 and confirmed active exploitation on July 19.
The most important operational detail is that attackers reached the same pre-authentication endpoint, /assessment_thanks.do, but used a different sandbox-escape gadget route than the public proof-of-concept.
That means defenses tuned only to the published payload are not enough.
How the ServiceNow AI Platform RCE Works
ServiceNow allows customers to run custom JavaScript inside sandboxed contexts. The sandbox should restrict what untrusted code can access.
CVE-2026-6875 breaks that boundary. Attackers can abuse improper sandbox isolation and reach code execution outside the intended restrictions.
Searchlight Cyber’s research explains that the attack begins through unauthenticated user input handled by ServiceNow’s query and scripting paths. The /assessment_thanks.do endpoint became the key pre-authentication entry point.
The public research focused on how a sandbox escape gadget could bypass script restrictions and reach a code execution primitive. Defused later reported that attackers used a different gadget chain in the wild.
That difference matters because it proves the vulnerability is structural, not limited to one published exploit path.
The Pre-Authentication Entry Point at /assessment_thanks.do
The /assessment_thanks.do endpoint handles ServiceNow assessment and survey responses.
Because attackers can reach this endpoint without authentication, CVE-2026-6875 becomes a pre-authentication RCE risk. That puts exposed instances under immediate pressure.
Attackers send crafted HTTP requests to the endpoint. The vulnerable processing path then triggers a sandbox escape gadget and reaches code execution outside the sandbox boundary.
Searchlight Cyber described the attack as high complexity. However, high complexity does not mean low risk once public research exists and attackers begin testing payloads.
Defused’s observation of active exploitation confirms that attackers moved from theory to practice within days.
Why Multiple Gadget Chains Change the Defense Equation
The second gadget chain changes the remediation priority.
A WAF rule built around the public proof-of-concept can block one known request shape. It cannot guarantee protection against a different gadget route that reaches the same code execution primitive.
That makes signature-based protection incomplete.
The only reliable fix is the ServiceNow patch because it removes the underlying conditions that allow sandbox escape paths to work.
Organizations should treat network-layer rules as temporary delay controls only. They can reduce noise, but they cannot replace patching.
What Attackers Can Do After Successful Exploitation
Successful exploitation can lead to full compromise of the ServiceNow instance.
Attackers may access workflow tables, read sensitive records, create administrator accounts, and interact with connected systems.
Workflow data often contains more sensitive information than teams expect. Tickets may include credentials, infrastructure details, incident response notes, HR data, financial workflows, integration secrets, and operational dependencies.
Administrator account creation also creates persistence risk. If defenders patch but fail to remove unauthorized accounts, attackers may retain access.
MID Server exposure creates another serious risk. A compromised MID Server can connect ServiceNow cloud workflows to internal corporate systems and on-premises network resources.
Enterprise Impact of the ServiceNow AI Platform RCE
The enterprise impact is high because ServiceNow often sits at the center of business operations.
Many organizations use it to coordinate IT, security, HR, finance, and infrastructure workflows. That makes the platform a high-value target for attackers who want visibility across the business.
Self-hosted customers face the widest exposure window. Hosted customers received protections quickly in April, while self-hosted organizations needed to apply the July patch.
Any self-hosted organization that delayed patching after July 13 remained exposed during the active exploitation window.
This is why security teams should not treat CVE-2026-6875 as a routine web application vulnerability. It affects an enterprise workflow platform that may connect to identity systems, ticket data, internal infrastructure, and MID Server pathways.
Self-Hosted Customers Face the Highest Priority
Hosted ServiceNow customers received early protections from the vendor.
Self-hosted customers carry more direct patch responsibility. They must verify the release family, confirm patch status, and apply the fixed version.
Affected release families include Brazil, Australia, Zurich, and Yokohama versions before the fixed releases listed in ServiceNow advisory KB3137947 and NVD.
Self-hosted teams should confirm whether they run Brazil EA or GA, Australia Patch 2, Zurich Patch 7b or Patch 9, Yokohama Patch 12 Hot Fix 1b, or Yokohama Patch 13.
Any instance below the fixed release should move into emergency remediation.
MID Server Compromise Expands the Blast Radius
MID Servers deserve special attention after any ServiceNow exposure.
A MID Server connects ServiceNow to on-premises environments and can support discovery, orchestration, and integration tasks. That means it may hold credentials or reach internal systems.
If attackers compromise the ServiceNow instance and pivot toward a MID Server, the incident may no longer remain contained inside the platform.
Security teams should audit MID Server logs, configuration, outbound connections, credential use, and unusual job execution.
They should also review which internal systems the MID Server can reach and whether that access remains necessary.
Real-World Attack Scenarios
In a self-hosted exposure scenario, an enterprise delays the July 13 patch until its next maintenance window. Attackers send crafted requests to /assessment_thanks.do on July 18. The sandbox escape succeeds, and the attackers access workflow tables containing ticket data and embedded infrastructure details.
In a WAF false-confidence scenario, a security team deploys rules for the public proof-of-concept but does not patch. Attackers use a second gadget chain that does not match the known pattern. The request reaches the vulnerable code path and compromises the instance.
In a MID Server pivot scenario, attackers gain code execution in ServiceNow, identify a connected MID Server, and use its trusted integration role to reach on-premises systems. The compromise expands from the platform into the internal network.
These scenarios follow the public technical mechanics described by Searchlight Cyber, Defused reporting, NVD, and ServiceNow advisory references. They do not assume unverified capabilities beyond the documented vulnerability impact.
How to Patch and Respond to the ServiceNow AI Platform RCE
Response should follow a strict priority order.
First, verify the ServiceNow release family and version. Then patch any vulnerable self-hosted instance immediately.
Second, review the Guarded Script compatibility guidance after upgrading. ServiceNow’s patch changes sandbox enforcement, so custom scripts may need review.
Third, audit administrator accounts. Look for unauthorized additions, unexpected role changes, and hidden persistence.
Fourth, investigate MID Servers. Review command execution, unusual jobs, outbound connections, and credential use.
Fifth, activate incident response if the instance was exposed during the July 13 to patch-date window.
Priority One: Verify and Patch the Instance
Start with version verification.
Confirm whether your instance runs a fixed release listed in ServiceNow KB3137947 and NVD. Fixed releases include Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b, and Yokohama Patch 13.
Any self-hosted instance below the fixed release remains exposed.
Patch immediately. Do not wait for the next monthly maintenance cycle when active exploitation has been reported.
Priority Two: Do Not Rely on WAF Rules Alone
A WAF can help block known traffic patterns, but it cannot fully remediate this flaw.
Defused reported that attackers used a second gadget chain that differed from the public proof-of-concept. That breaks the assumption that one signature set can cover all attack paths.
Use WAF rules only as temporary support while patching happens.
The patch remains the only control that closes the underlying sandbox escape.
Priority Three: Review Guarded Script Compatibility
ServiceNow introduced Guarded Script changes to reduce future sandbox escape risk.
After upgrading, review the Incompatible Guarded Scripts list and identify custom scripts that may conflict with the new restrictions.
This step matters because security fixes can affect custom enterprise logic.
Security teams should coordinate with ServiceNow administrators, application owners, and workflow owners before declaring the upgrade complete.
Priority Four: Audit Administrator Accounts
Successful exploitation can allow administrator account creation.
After patching, review all administrator-level accounts in the instance. Compare the list against approved users, service accounts, and documented break-glass access.
Disable or investigate any account that cannot be verified.
Also review recent privilege changes, role assignments, API token use, integration accounts, and suspicious login activity.
Patching removes the vulnerability, but it does not automatically remove attacker-created persistence.
Priority Five: Audit MID Servers
MID Servers create a bridge between ServiceNow and internal systems.
Review MID Server logs, job history, outbound connections, credential use, and configuration changes.
Look for unusual commands, unexpected discovery activity, suspicious script execution, and unexplained connections to internal assets.
Treat any MID Server reachable from an exposed ServiceNow instance as potentially involved until logs prove otherwise.
For broader application-layer testing support, see Digital Warfare’s web application penetration testing services
Priority Six: Review Logs for Exploitation Attempts
Search for requests to /assessment_thanks.do during the exposure window.
Focus on unusual POST requests, unexpected parameters, repeated failed attempts, suspicious source IPs, and requests that differ from normal survey or assessment traffic.
Correlate ServiceNow logs with WAF logs, proxy logs, SIEM detections, and MID Server activity.
Because the reported in-the-wild gadget chain differs from the public proof-of-concept, defenders should not rely only on exact known payload matching.
Priority Seven: Activate Incident Response When Exposure Is Confirmed
Any self-hosted organization that remained vulnerable after July 13 should consider formal incident response.
The reason is simple. Active exploitation reportedly began days after public disclosure, and the vulnerability does not require credentials.
Incident response should include ServiceNow instance review, administrator account review, workflow table access review, MID Server investigation, credential rotation, and integration account validation.
Do not stop after confirming the patch. Confirm that attackers did not create persistence before the patch landed.
Broader Security Lessons From the ServiceNow AI Platform RCE
This vulnerability offers several evergreen lessons for enterprise security leaders.
First, self-hosted enterprise platforms need faster emergency patch workflows. Hosted customers benefited from early platform-level protections, but self-hosted customers had to apply the formal update themselves.
Second, pre-authentication vulnerabilities in workflow platforms require executive attention. These platforms connect business processes, identity workflows, security operations, and internal infrastructure.
Third, multiple exploit routes are now normal for high-value enterprise vulnerabilities. Teams should not build response plans around one public proof-of-concept.
Finally, patching remains the only reliable remediation when attackers can reach the same primitive through different gadget chains.
Why Self-Hosted Platforms Need Better Patch Governance
Self-hosted platforms give organizations control, but they also shift patch responsibility back to the enterprise.
That means security teams need complete ownership records, version visibility, emergency change processes, and clear escalation paths.
A three-week maintenance delay may feel normal for routine updates. It is not acceptable for a pre-authentication RCE under active exploitation.
Executives should ask whether every self-hosted enterprise platform has an emergency patch plan.
Why Workflow Platforms Are High-Value Targets
Workflow platforms contain operational truth.
They show who owns systems, which incidents happened, which credentials appeared in tickets, which vendors connect to the environment, and which workflows approve business actions.
That makes ServiceNow valuable to attackers.
Security teams should treat workflow platforms as tier-one systems, not ordinary SaaS or application infrastructure.
Access controls, logging, patching, integration security, and incident response planning should reflect that importance.
Why Pre-Authentication RCE Deserves Emergency Priority
Pre-authentication RCE means the attacker does not need credentials or user interaction to begin.
That makes internet-facing exposure especially dangerous.
Even when exploitation requires technical precision, public research and attacker iteration can shorten the time between disclosure and weaponization.
ServiceNow AI Platform RCE CVE-2026-6875 shows how quickly that window can close.
Key Takeaway on ServiceNow AI Platform RCE
ServiceNow AI Platform RCE CVE-2026-6875 is a critical sandbox escape vulnerability that allows unauthenticated remote code execution on vulnerable ServiceNow instances.
Searchlight Cyber discovered the flaw and reported it to ServiceNow on April 1, 2026. ServiceNow protected hosted instances quickly and released self-hosted patches on July 13.
Defused later reported active exploitation beginning days after public disclosure, with attackers using a different gadget chain than the published proof-of-concept.
The response is clear. Patch immediately, review Guarded Script compatibility, audit administrator accounts, investigate MID Servers, review logs for /assessment_thanks.do activity, and activate incident response if exposure existed during the active exploitation window.
What Organizations Should Do Now
Identify every ServiceNow instance and confirm whether it is hosted or self-hosted.
Verify the release family and patch level against KB3137947.
Patch any vulnerable self-hosted instance immediately.
Review Guarded Script compatibility after the upgrade.
Audit administrator accounts for unauthorized additions or privilege changes.
Audit MID Servers for suspicious commands, jobs, connections, and credential use.
Search logs for /assessment_thanks.do activity during the July 13 to patch-date window.
Rotate credentials exposed through workflow tables, integration accounts, or MID Server configurations.
For the one external source in this article, review ServiceNow’s official advisory: ServiceNow KB3137947
Frequently Asked Questions About ServiceNow AI Platform RCE
What Is the ServiceNow AI Platform RCE?
ServiceNow AI Platform RCE refers to CVE-2026-6875, a critical sandbox escape vulnerability that can allow unauthenticated attackers to execute arbitrary code remotely on vulnerable ServiceNow instances.
How Does CVE-2026-6875 Work?
Attackers send crafted requests to the /assessment_thanks.do endpoint. The vulnerable processing path triggers a sandbox escape gadget that reaches code execution outside the intended script sandbox restrictions.
Who Discovered CVE-2026-6875?
Searchlight Cyber researchers at Assetnote discovered CVE-2026-6875 and reported it to ServiceNow on April 1, 2026.
When Did ServiceNow Patch CVE-2026-6875?
ServiceNow pushed protections to hosted instances within 24 hours of the April 1 report and released formal self-hosted patches with advisory KB3137947 on July 13, 2026.
Is the ServiceNow AI Platform RCE Actively Exploited?
Defused reported in-the-wild exploitation beginning days after the July 13 patch release. BleepingComputer also reported that Defused observed active exploitation of CVE-2026-6875.
Why Are Multiple Gadget Chains Important?
Multiple gadget chains mean attackers can reach the same code execution primitive through different technical routes. That makes WAF rules based on one public proof-of-concept incomplete.
Which ServiceNow Versions Are Patched?
Fixed releases include Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b, and Yokohama Patch 13.
What Should Organizations Do First?
Organizations should verify their ServiceNow version, patch vulnerable self-hosted instances immediately, review Guarded Script compatibility, audit administrator accounts, investigate MID Servers, and search logs for /assessment_thanks.do activity.
