Windows sandbox escape shows how URI handling can cross integrity boundaries

At a glance

What this is: SafeBreach’s research shows a one-click Windows 11 sandbox escape that chains COM activation, URI tricks, and DevTools access into arbitrary write and code execution.

Why it matters: It matters because identity, launch, and privilege boundaries can be crossed even when each subsystem appears constrained, which is exactly the sort of composition failure IAM, PAM, and endpoint teams need to anticipate.

By the numbers:

• The “Click Or Trick” vulnerability was assigned CVE-2025-59199 with a CVSS score of 7.8 and patched in October 2025.

👉 Read SafeBreach's analysis of the Click Or Trick Windows sandbox escape

Context

Windows sandboxing is only as strong as the handoff points between subsystems. This research shows how a low-integrity process can inherit more privilege than expected when COM activation, app URI handling, and browser debugging interfaces are allowed to interact without a single policy model governing the whole chain.

For IAM and PAM teams, the identity lesson is that an integrity label is not the same thing as a governed execution boundary. When launch behaviour, token handling, and protocol handlers can be composed into a higher-privilege action, the control failure sits at the junction between identity, application control, and endpoint hardening.

The starting position is atypical in its exact mechanics, but the underlying pattern is familiar: complex platforms accumulate trust shortcuts at subsystem boundaries.

Key questions

Q: What breaks when low-integrity sandbox boundaries are composed with launch and URI handlers?

A: The boundary breaks when a constrained process can trigger a higher-trust activation path that inherits a more capable token or launches a privileged helper. At that point, the sandbox is no longer the security boundary. The real risk is not one broken control, but the way multiple acceptable controls can combine into an execution path that was never intended.

Q: Why do Windows integrity levels fail to stop every privilege escalation path?

A: Integrity levels constrain object access, but they do not automatically govern every activation, redirect, or protocol-handling decision in the system. If a low-integrity process can launch a medium-integrity component or influence its arguments, the boundary can be bypassed without directly defeating the integrity mechanism itself.

Q: What do security teams get wrong about browser debugging ports in production?

A: They often treat remote debugging as a developer-only feature rather than a privileged runtime control surface. If an attacker can reach that port, they may be able to steer application behaviour, change download paths, or extract runtime state. Production exposure should therefore be governed like any other sensitive service endpoint.

Q: Who is accountable when sandbox escape chains emerge from default Windows components?

A: Accountability sits with the platform owner for the operating system defaults, with endpoint security teams for local hardening, and with application owners for any service that exposes a dangerous launch surface. In practice, the governance failure is shared, because the exploit emerges at the junction of multiple controls rather than in one isolated product.

Technical breakdown

How low-integrity process boundaries can be bypassed through COM activation

Windows Mandatory Integrity Control reduces what a low-integrity process can touch, but it does not prevent every form of cross-boundary activation. In this case, the interesting condition was a COM object that could be launched with the user’s unmodified logon token from a low-integrity context. That matters because COM activation can start a separate LocalServer32 process with a different security context, which is very different from loading a DLL in-process. The exploit chain depended on finding an object whose activation path preserved enough identity context to become useful, even though the caller remained sandboxed.

Practical implication: review COM objects that can be activated from low-integrity contexts and treat token inheritance as an access-control decision, not a technical detail.

URI handlers and parameter injection in Windows app launch paths

The exploit then moved through Windows application URI handling. A URI scheme can launch an application and pass parameters, which is useful when designed safely but dangerous when the launch surface accepts encoded parameters that alter the command line. The research showed that a redirect URI could be combined with a command-line switch to steer an application into an unexpected execution path. This is a classic example of trust being transferred across handlers that were never designed as a single security boundary, especially when decoding quirks change how input is interpreted before launch.

Practical implication: constrain which URI schemes can invoke sensitive apps and validate how command-line parameters survive encoding, decoding, and redirect chains.

Browser DevTools ports as a privilege-amplification surface

The final stage used a Chromium-based application exposed with a remote debugging port. Chrome DevTools Protocol is meant for developer control, but once reachable, it can expose operations that change download behaviour, window state, or other runtime settings. In a normal environment that is a management channel. In an exploit chain it becomes a privileged control plane that can be reached from a low-integrity starting point if the app launch path is compromised. That is why a debugging interface should be treated as a sensitive service endpoint, not just a developer convenience.

Practical implication: block or tightly scope remote debugging ports in production builds and treat CDP exposure as a privileged service that needs explicit governance.

Threat narrative

Attacker objective: The attacker’s objective is to escape low-integrity confinement and gain code execution or write access at a higher trust level on Windows 11.

1. Entry occurred through a single user click that triggered a low-integrity notification and launch path.
2. Escalation followed when COM activation and URI redirection were chained to start higher-trust processes and inject parameters.
3. Impact was arbitrary file write and code execution outside the sandbox, creating a practical sandbox escape path.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Windows sandbox escapes increasingly look like identity composition failures: the problem is not only whether a process is low-integrity, but whether activation paths, launch tokens, and handler chains preserve that boundary under composition. This research shows how separate subsystems can jointly defeat a control that each subsystem appears to honour on its own. For security teams, the practical conclusion is that endpoint hardening must include trust-path analysis, not just process-level isolation.

Integrity labels are not enough when application launch paths can reassert higher trust: the exploit depended on turning a constrained context into a medium-integrity server process through activation and redirect logic. That is a governance problem as much as a technical one, because policy owners often assume the sandbox is the control, when in fact it is only one layer in a larger identity and execution chain. Practitioners should treat launch brokerage as part of the access model.

Browser debugging interfaces are a privileged runtime service, not a developer convenience: the remote debugging port became the decisive control surface once the chain reached a Chromium-based process. In broader security terms, this is a reminder that runtime management channels need the same scrutiny as secrets, tokens, and service accounts. The practitioner takeaway is to inventory and restrict debug interfaces before they become cross-boundary execution paths.

Subsystem trust gaps create control debt that accumulates quietly: the named concept here is cross-boundary trust debt, meaning the hidden risk created when individually reasonable launch and activation features are allowed to compose into an unsafe whole. That debt is difficult to see in standard reviews because no single component appears broken. Teams should use this as a prompt to review app launch, COM, URI, and browser control planes together rather than in isolation.

Exploit chains like this validate the need for identity-aware application containment: the incident is not just about code execution, but about which identity and privilege context each step inherits. In mixed Windows estates, identity governance needs to extend into application control, because the path from low-integrity to medium-integrity can become a privilege boundary collapse if launch policies are permissive. The practical conclusion is to align endpoint containment with identity-aware runtime policy.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• Forward-looking view: use 52 NHI Breaches Analysis to compare how identity governance gaps become repeated compromise patterns across environments.

What this signals

Cross-boundary trust debt is the right way to think about this class of exploit. When low-integrity isolation, COM activation, URI dispatch, and browser debugging can be chained together, the weakness is not any single subsystem but the hidden trust carried between them. Teams should use this pattern to stress-test endpoint policy, application allowlisting, and developer tooling exposure together.

For identity programmes, the signal is that runtime privilege is increasingly determined by launch context as much as by static access control. That makes https://nhimg.org/top-10-non-human-identity-issues useful as a lens for hidden trust paths, while NIST SP 800-53 Rev 5 Security and Privacy Controls remains the baseline for access and system integrity governance. The practical task is to reduce the number of places where a single click can promote trust across a boundary.

For practitioners

• Inventory low-integrity activation paths Map which COM objects can be activated from sandboxed processes and flag any server that launches with an unmodified logon token or a more privileged context. Focus on LocalServer32 registrations, not just DLL-based components, because those create the cross-process boundary attackers exploit. This is where trust-path review belongs.
• Restrict and validate URI-based launch handlers Audit Windows URI schemes that can invoke applications with command-line parameters, then remove or constrain handlers that accept redirected input into sensitive apps. Pay particular attention to encoded arguments that survive decoding and alter launch semantics. The control goal is to make redirect chains predictable rather than composable.
• Treat debugging ports as privileged services Disable remote debugging by default in production endpoints, and when it is required, bind it to explicit administrator workflows rather than ambient app launches. Any Chromium-based app exposing a devtools port should be listed alongside other sensitive runtime services because it can expose high-impact management functions.
• Build cross-subsystem attack-path reviews into endpoint hardening Review COM, URI handlers, browser protocols, and token handling together during hardening cycles, because the exploit only works when these layers are composed. This is a control design issue, not a patch-only problem, so the review should feed policy and application allowlisting decisions.

Key takeaways

• This research shows that Windows sandboxing can fail at subsystem boundaries even when each component appears to enforce its own restriction.
• The exploit chain reached arbitrary write and code execution from a low-integrity process, which makes the control failure operationally real rather than theoretical.
• The most effective response is to review COM activation, URI handlers, and debugging interfaces as one attack path, not as separate hardening tasks.

Key terms

• Mandatory Integrity Control: Mandatory Integrity Control is a Windows mechanism that labels processes and objects with integrity levels such as low, medium, and high. It is designed to restrict how lower-trust code interacts with higher-trust resources, but it does not by itself govern every launch, activation, or protocol path across the operating system.
• 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.
• 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.

What's in the full report

SafeBreach's full research covers the exploit chain detail this post intentionally leaves for the source:

• The exact COM object discovery path and the AppID flag behaviour that enabled medium-integrity launch from a low-integrity context
• The parameter-injection sequence used to move from Snipping Tool URI handling into a Chromium debugging surface
• The WebSocket commands used against Chrome DevTools Protocol to achieve arbitrary write
• The disclosure timeline, patch timing, and proof-of-concept validation steps

👉 SafeBreach's full post covers the COM flag chain, URI injection path, and DevTools write primitive in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that supports cross-domain practitioners. It helps security teams connect identity control to the broader runtime and access models their programmes depend on.