ServiceNow's Latest Security Incident: Unauthenticated Remote Sandbox Escape & How SendSafely Halo Protects Your Customer Data

ServiceNow Halo image

On July 14, Adam Kues at Searchlight Cyber published the technical details of CVE-2026-6875, a pre-authentication remote code execution flaw in the ServiceNow AI Platform. This is an excellent piece of work and it is the latest in a run of ServiceNow security disclosures, and of the recent set it is the most serious.

The short version: ServiceNow runs user-supplied JavaScript inside a sandbox, and Kues found a way out of it. His write-up has the full exploit chain. What matters here is that it required no credentials and started from a public endpoint. This means a remote unauthenticated attacker could access everything. Read any record in any table, create administrator accounts, and run shell commands on connected proxy servers, which usually sit inside the internal network. Full compromise from the Internet.

ServiceNow moved quickly, providing updates and patches, which allowed self-hosted customers to apply the fix themselves. Four days after the write-up went public, Defused reported seeing exploitation attempts in the wild built directly on the published research.

How SendSafely's new ServiceNow Halo integration would help protect customer data.

This is why we built Halo the way we did, and it is the whole argument for running it inside ServiceNow's Virtual Agent.

You do not control ServiceNow's sandbox architecture, or which endpoints ship with authentication disabled, or how quickly security fixes are made available so you can patch your self-hosted instance.

There is a variable you do control. You control whether the driver's license, the remittance file, the medical form, and the credentials your customer just pasted into chat are inside the ServiceNow instance when the next vulnerability disclosure lands.

Reduce what there is to take

With Halo, sensitive customer files are encrypted in the browser before they are uploaded, so the ServiceNow instance never receives the content. The Virtual Agent orchestrates the collection without being added to the package recipient list, which means an agent that gets manipulated has nothing to hand over.

The agent still does its job. It knows the document arrived, it keeps the conversation moving, and it routes the case to whoever needs to act on it. The one thing the AI Agent cannot do is read the contents, which is the one capability it never needed in order to be useful.

The part that matters for a compromised instance is where authorization lives. Halo posts a secure link into the conversation, and an attacker with read access to the instance can see that link. Seeing it is not enough. Having the link does not allow access to the SendSafely portal or provide the ability to decrypt the protected files. Decryption is only possible after SendSafely confirms the requester is an authorized recipient and that the requested file hasn’t already expired or been automatically deleted. Those checks run outside ServiceNow. Files that come through Halo also inherit whatever expiration and deletion rules you’ve already configured, so exposure has a shelf life of its own, not just a race to patch. An attacker who owns the ServiceNow instance only holds one half of a key, with no way to authenticate or ask for the other key.

Be clear about the limits. Halo does not patch a sandbox escape, stop the code execution in ServiceNow, or protect anything else in the instance. Ticket text, work notes, and contact details are all still exposed to a compromise like this one.

What Halo takes off the table is the sensitive files customers entrusted to you via the Virtual AI Agent, because they were never stored in the ServiceNow platform to begin with.

The control that holds

Autonomous remediation is coming and it will make enterprises faster at closing the gap between disclosure and patch. That is real progress and worth having. It does not change the arithmetic underneath, because the fastest patch cycle in the world still runs after the disclosure, and the exploitation attempts on CVE-2026-6875 showed up four days after the research went public.

The only control that holds regardless of how that race goes is not storing the sensitive content in the first place. Shrink what is in the blast radius and you stop needing to win every race.

Two final important considerations:

  • No AI agent your company uses—whether yours or ServiceNow's—should ever have access to customer credentials, whether submitted directly or picked up accidentally through customer-supplied debug logs or HAR files. AI agents can be manipulated, or can simply decide on their own to operate outside their intended parameters. That means any AI tied to your service should never be able to log into your customers' systems—doing so creates real legal liability for you and real risk for your customers. Read more here: Your AI Doesn't Need a Zero-Day. It Already Has the Credentials.

  • Automated expiration and deletion of sensitive data is one of the best, yet most often overlooked security controls an organization can use to protect itself and its customers from future security events. Sensitive files received through Halo inherit all the useful settings for automated expiration and deletion configured to meet your requirements.

Halo for ServiceNow is available now on Enterprise plans. If you want to see what it looks like in a live Virtual Agent conversation, email sales@sendsafely.com.

 


 

SendSafely Halo: The Trust Layer Between Your Data and Your AI Stack

If you are looking for a way to keep sensitive customer data out of your AI stack, or need to limit what any one vendor can access, SendSafely Halo might be the right fit for you.