ServiceNow’s sandbox escape RCE hole now exploited in the wild

A sandbox security hole that could lead to remote code execution (RCE), patched last week by ServiceNow, is being actively exploited in the wild, according to a report from threat intel firm Defused. 

The report, posted on X, said the firm is “observing in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).”

Defused CEO Simo Kohonen noted in an interview that it appeared that the attacker has changed its tactics from those documented in an earlier proof of concept (PoC) from researchers at Searchlight Cyber, in response to ServiceNow patches and defenses. The company had implemented five different mitigations in its code base, which “neutered” the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see. 

“We are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,” Kohonen said. Attackers “now have more tools to build their own stuff.”

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation “once, by one actor.” 

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations. 

“ServiceNow is aware of a cybersecurity company’s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,” the emailed statement said. “We have provided updates and patches designed to address this issue, and we encourage our self-hosted and ServiceNow-hosted customers to apply the relevant patches if they have not already done so.”

A ‘repeatable failure point’

Analysts and consultants said the bigger concern with this hole is that it focuses on the lack of protections in the sandbox, which many security and IT teams have relied on for years. 

“The vulnerability lets an attacker bypass ServiceNow’s scripting sandbox entirely, and researchers are now seeing exploitation using a different technique than the one originally published, which means signature-based defenses built on the first proof of concept are unlikely to catch every variant,” said Frank Dickson, group VP for security at IDC.

“A compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,” he pointed out. “And because ServiceNow frequently houses HR records, CMDB asset data, and the ticketing system itself, an attacker sitting inside it may have visibility into how the incident response team is tracking the incident.”

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies. 

“Enterprises outsource patching for platforms like ServiceNow to the vendor, but keep the risk that comes from what those platforms touch: HR records, CMDB inventories, and now on-premises systems through MID Server integration. Control sits with the vendor, liability sits with the enterprise, and that mismatch argues for treating core SaaS platforms as part of the internal attack surface, not externalized vendor risk,” he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes “a repeatable failure point.”

Because of this, he advised, “CISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.”

Noah Kenney, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue. 

“The significance is not that ServiceNow had a critical bug, so much as the fact that the bug is a sandbox escape in the AI Platform, which means the containment layer specifically built to run untrusted AI-driven code safely is the thing that failed,” he said. “CISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we’re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.”

Addition of AI increases blast radius

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.

“Enterprises are bolting AI onto their most privileged systems of record faster than anyone is updating the threat models for those systems, and the AI layer is becoming the softest part of the hardest targets,” Kenney said. “The real question for a CISO is how many of your critical platforms shipped an AI feature in the past year, and whether a single person in your organization can tell you what that did to the pre-auth attack surface. Most cannot, and that is the actual exposure.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.

“A vulnerability that gives an attacker a foothold in the ServiceNow instance is now also a vulnerability that gives them access to whatever AI agents are running inside that instance, along with any capability tokens, service accounts, or delegated permissions those agents hold,” Mahapatra said. “The blast radius of a ServiceNow compromise in 2026 is meaningfully larger than the same compromise would have been in 2023, and most enterprise security programs have not caught up to that shift.”

Defused’s Kohonen said that he did not disagree with the sandbox concerns, but he stressed that enterprise CISOs have long ago abandoned the belief that sandboxes are secure. 

“Nothing is foolproof, and having a sandbox is better than not having one,” he said. “But the belief that a sandbox removes all of the risk is incredibly dumb,” especially in the reality of today’s threat landscape, which contains “an endless conveyor belt of exploits.”

This article originally appeared on CSOonline.