Windows sandbox escape shows how URI handling can cross integrity boundaries

At a glance

What this is: SafeBreach documents a Windows 11 sandbox escape that used COM activation, URI tricks, and browser debugging access to move from low-integrity execution to arbitrary write and code execution.

Why it matters: This matters because identity, launch, and integrity controls can fail when separately safe components are chained together, which is relevant to application sandboxing, privilege boundaries, and non-human execution paths.

Context

Windows sandboxing is only as strong as the seams between subsystems. This research shows that low-integrity restrictions can be bypassed when activation rules, URI handlers, and debug interfaces are treated as unrelated controls instead of one launch chain.

The identity angle is not about user login, but about how a low-integrity process can inherit enough launch authority to trigger higher-integrity behaviour. That makes the problem a governance issue for application identity, not just a bug in one component.

Key questions

Q: What breaks when a low-integrity Windows process can activate a higher-integrity component?

A: The sandbox assumption breaks because launch authority becomes more important than the original process label. If a low-integrity caller can start a medium-integrity server, later actions may inherit that stronger trust context unless the platform explicitly rechecks the boundary. That is why activation rules matter as much as access control on objects.

Q: Why do URI handlers become dangerous when they forward parameters into another app?

A: They turn structured app requests into an indirect command channel. A URI can look harmless at first, but if its parameters are decoded and passed into a launch string, the handler is effectively accepting attacker-influenced process arguments. The risk grows when the target app also exposes privileged behaviour.

Q: What are the signs that a sandbox boundary is too easy to cross?

A: Watch for any path where a sandboxed process can trigger a higher-trust launch, influence command-line arguments, or reach a management interface such as a debug port. If a click, callback, or redirect can change process privilege without a fresh authorisation check, the boundary is too weak.

Q: How should defenders respond when a sandbox escape involves app launch and debug interfaces?

A: They should review the entire chain as one containment failure, not as separate bugs. That means tightening launch permissions, removing unnecessary debug exposure, and validating that low-trust inputs cannot alter higher-trust process behaviour. The right question is whether any hop in the chain can silently raise trust.

Technical breakdown

How low-integrity COM activation crosses the integrity boundary

Windows Mandatory Integrity Control limits what a low-integrity process can access, but COM launch rules can still create a medium-integrity server if the AppID and launch configuration permit it. In this research, the key failure was not a broken login. It was an activation path that preserved the session user’s original logon token while bypassing the sandbox boundary. Once a low-integrity caller can start a server in a higher integrity context, every later action inherits that stronger trust level unless additional checks intervene.

Practical implication: review COM launch permissions and AppID flags as launch-control surfaces, not just component configuration.

Why URI handling becomes an execution primitive

URI schemes are intended to pass structured requests between applications, but they become risky when a handler accepts redirect or callback parameters and then reflects them into a launch command. In this chain, the application-specific URI and the command-line switch acted together as a transport for attacker-controlled arguments. URI decoding quirks made the injection reliable enough to alter the launched process behaviour. That is a classic boundary-crossing problem: the input is syntactically valid at one layer but semantically dangerous when passed to the next.

Practical implication: validate cross-application URI parameters as if they were command-line inputs, because in practice they are.

How a browser debug port turns launch abuse into write capability

A debug port exposes a browser control plane over WebSocket, which is powerful because it can change runtime behaviour after launch. In this case, the attacker reached a Chromium-based process with remote debugging enabled and used DevTools protocol methods to influence where downloads were written. That converts a one-click launch flaw into arbitrary file write, which is often enough to pivot into code execution or persistence. The underlying issue is not just browser debugging. It is unauthorised exposure of a management interface to an untrusted launch path.

Practical implication: keep debug and management ports off untrusted launch paths and treat them as privileged interfaces.

Threat narrative

Attacker objective: The objective is to escape the low-integrity sandbox and gain code execution with the ability to write attacker-chosen files in a higher-trust context.

1. Entry occurs when a user click triggers a low-integrity notification and launches a COM-backed Windows component in a more privileged context.
2. Credential access is not the main driver here; instead, the attacker abuses launch authority and URI parsing to inject parameters into a secondary application.
3. Escalation happens when the chain reaches a Chromium-based process with remote debugging enabled, exposing a control channel over WebSocket.
4. Impact is arbitrary file write and code execution from a process that began in the sandboxed integrity level.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sandbox escape is often a trust-chain failure, not a single bug. This case shows that Windows integrity boundaries can be crossed when activation, URI processing, and debug interfaces are each considered safe in isolation. The exploit worked because the platform did not enforce end-to-end trust continuity across those transitions. Practitioners should treat cross-component launch paths as a governance problem, not only a patching problem.

Application identity needs launch-time controls, not just install-time trust. A low-integrity process can remain constrained only if the later components it invokes do not inherit hidden authority through COM or handler metadata. The research demonstrates that identity context can mutate during activation even when the originating user stays the same. That makes runtime launch policy part of the identity model.

URI handling is an attack surface when it reaches command-line semantics. The article’s most important lesson is that an apparently harmless redirect parameter becomes dangerous once it is decoded and forwarded into a launch string. That is why URI governance belongs alongside input handling and process creation policy. Named concept: URI-to-launch trust leakage is the point where structured application requests become executable influence.

Browser debugging interfaces should be treated as privileged management planes. Exposing DevTools-style control through a launchable app turns a troubleshooting feature into a post-launch execution surface. The exploit path is especially relevant wherever a sandboxed app can reach a browser or Chromium-derived component. Organisations should review debug exposure as part of application hardening and privilege containment.

MIC-style sandboxing needs composition-aware validation. The exploit does not prove integrity controls are obsolete, but it does show that layered controls lose value when their handoff rules are under-specified. Vendors and defenders should test the full path from low-integrity entry to higher-integrity side effects, not just component behaviour in isolation. That is the difference between a theoretical boundary and an enforceable one.

What this signals

URI-to-launch trust leakage: this is a useful shorthand for the failure mode exposed here. When a handler decodes external input and passes it into another application's launch path, the control boundary moves from request validation to process creation, and that is where containment often fails.

For Windows defenders, the practical lesson is to test integrity transitions the way adversaries do, by chaining app launch, argument injection, and post-launch control surfaces. A sandbox is only trustworthy if the platform can prove that no intermediate subsystem can upgrade the caller’s effective authority.

The broader programme implication is that endpoint hardening, browser management, and application sandbox policy need to be reviewed together. A low-integrity process that can reach a privileged debugging plane is not just a vulnerability in one app, it is a governance failure across the launch chain.

For practitioners

• Audit COM launch pathways for integrity drift Inventory COM objects that can be activated from low-integrity contexts and identify any that launch with a stronger token or session context than the caller.
• Treat application URI parameters as command input Review URI handlers for redirect, callback, and parameter forwarding behaviour, especially where the handler ultimately builds a command line or passes arguments to another process.
• Disable or isolate exposed debug ports Ensure browser and Chromium-derived components do not expose remote debugging interfaces on launch paths reachable from sandboxed or low-trust processes.
• Test integrity boundaries end to end Reproduce the full user-click-to-privileged-action chain in a controlled environment to see whether any subsystem can silently raise process trust or write outside the sandbox.
• Review app-to-app launch permissions Check whether notification, handler, or package activation paths can be used to start higher-trust applications with attacker-influenced arguments.

Key takeaways

• The exploit shows that sandbox escapes often emerge from the composition of individually familiar Windows features rather than from one obvious flaw.
• The critical weakness was the handoff between low-integrity launch, URI processing, and a higher-trust debug-capable process.
• Defenders need to validate trust transitions end to end, because a single click can become arbitrary write and code execution when launch boundaries are loose.

Key terms

• Windows Mandatory Integrity Control: A Windows security mechanism that limits what processes can do based on integrity level, such as low, medium, or high. It adds a trust boundary inside the same user session so sandboxed applications cannot freely interact with more trusted objects or processes.
• COM Activation: COM activation is the process of creating and initialising a COM object so it can service requests. In Windows, activation can occur in-process or in a separate server process, and that distinction matters because out-of-process activation can move execution into a different security context.
• URI Handler: An application or operating-system registration that receives a URI scheme such as ms-screenclip or file and decides how to open it. URI handlers are useful for app-to-app workflows, but they become risky when they pass untrusted parameters into launch commands or other privileged operations.
• Chrome DevTools Protocol: Chrome DevTools Protocol is a management interface used to control Chromium-based applications at runtime over a debugging connection. It is intended for development and automation, but if exposed in production it can become a high-value control plane for changing application behaviour, state, or file handling.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is a practical fit for practitioners who need to connect identity controls to broader platform trust boundaries.