{"id":8826,"date":"2026-07-20T20:24:54","date_gmt":"2026-07-20T20:24:54","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8826"},"modified":"2026-07-20T20:24:54","modified_gmt":"2026-07-20T20:24:54","slug":"servicenows-sandbox-escape-rce-hole-now-exploited-in-the-wild","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8826","title":{"rendered":"ServiceNow\u2019s sandbox escape RCE hole now exploited in the wild"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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<\/a>.\u00a0<\/p>\n

The report, posted on X, said the firm is \u201cobserving in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).\u201d<\/p>\n

Defused CEO Simo Kohonen<\/a>, in an interview with CSO Online, noted 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.\u00a0The company had implemented five different mitigations in its code base, which \u201cneutered\u201d the initial attack methodology, he said, adding that, overall, his team is seeing more attack method tweaks than it used to see.\u00a0<\/p>\n

\u201cWe are seeing a lot of [attack] variations, much more so than a year ago, for the same vulnerability,\u201d Kohonen said. Attackers \u201cnow have more tools to build their own stuff.\u201d<\/p>\n

However, he admitted that his team has thus far only observed this exploit an in the wild exploitation \u201conce, by one actor.\u201d\u00a0<\/p>\n

In response to the report, ServiceNow issued a statement saying that it has not yet directly seen any such exploitations.\u00a0<\/p>\n

\u201cServiceNow is aware of a cybersecurity company\u2019s recent publication regarding exploitation activity associated with a previously disclosed security vulnerability, identified as CVE-2026-6875<\/a>. Based on our investigation to date, we have not observed evidence that this activity is related to instances that ServiceNow hosts,\u201d the emailed statement said. \u201cWe 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.\u201d<\/p>\n

A \u2018repeatable failure point\u2019<\/h2>\n

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.\u00a0<\/p>\n

\u201cThe vulnerability lets an attacker bypass ServiceNow\u2019s 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,\u201d said Frank Dickson<\/a>, group VP for security at IDC. <\/p>\n

\u201cA compromise that starts in the cloud tenant can end up inside the corporate network, turning a SaaS incident into an on-premises one,\u201d he pointed out. \u201cAnd 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.\u201d<\/p>\n

Dickson added that this incident is further proof that both IT and security teams need to reevaluate their patching methodologies.\u00a0<\/p>\n

\u201cEnterprises 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,\u201d he said, noting that as vendors embed more AI-driven scripting into their platforms, the sandbox boundary becomes \u201ca repeatable failure point.\u201d <\/p>\n

Because of this, he advised, \u201cCISOs should start asking every AI-enabled SaaS vendor how that boundary is architected and tested, before the next version of this story breaks elsewhere.\u201d<\/p>\n

Noah Kenney<\/a>, principal consultant at Digital 520, said the sandbox escape is the more disturbing element of the issue.\u00a0<\/p>\n

\u201cThe 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,\u201d he said. \u201cCISOs have been told repeatedly that the sandbox is what makes enterprise AI safe to deploy, but we\u2019re now seeing the sandbox breaking and that should reframe how CISOs think about every feature sitting behind a similar wall.\u201d<\/p>\n

Addition of AI increases blast radius<\/h2>\n

This is yet another example where AI is fundamentally changing just about every IT and security rule, he pointed out.<\/p>\n

\u201cEnterprises 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,\u201d Kenney said. \u201cThe 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.\u201d<\/p>\n

Aman Mahapatra<\/a>, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, agreed.<\/p>\n

\u201cA 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,\u201d Mahapatra said. \u201cThe 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.\u201d<\/p>\n

Defused\u2019s 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.\u00a0<\/p>\n

\u201cNothing is foolproof, and having a sandbox is better than not having one,\u201d he said. \u201cBut the belief that a sandbox removes all of the risk is incredibly dumb,\u201d especially in the reality of today\u2019s threat landscape, which contains \u201can endless conveyor belt of exploits.\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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.\u00a0 The report, posted on X, said the firm is \u201cobserving in-the-wild exploitation of the ServiceNow pre-auth sandbox-escape RCE (CVE-2026-6875).\u201d Defused CEO Simo […]<\/p>\n","protected":false},"author":0,"featured_media":8827,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8826","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8826"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8826"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8826\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8827"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8826"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8826"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8826"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}