Finding a High-Severity Browser Security Issue in OpenClaw

Modern security work is not only about finding exposed passwords, open admin panels, or obvious remote-code-execution paths. Some of the most important vulnerabilities hide in quieter parts of a system: discovery logic, connection handling, trust boundaries, and policy enforcement.

I recently reported a security vulnerability in OpenClaw that was accepted and published as GitHub Security Advisory GHSA-3x84-qq85-fj65.

The issue was titled Browser CDP discovery could accept blocked WebSocket URLs.

The advisory was rated High severity, with a CVSS score of 8.5.

What Happened

OpenClaw includes browser automation features that can interact with Chrome DevTools Protocol, commonly called CDP. Browser automation systems often need to discover a running browser instance, read CDP metadata, and connect to a WebSocket debugger endpoint.

That behavior is normal.

The security issue appeared when CDP discovery could accept a WebSocket URL that should have been blocked by OpenClaw policy. Under the right configuration, this meant a lower-trust caller or configured input path could potentially reach network destinations that policy was supposed to prevent.

This was not a flashy bug. There was no hardcoded credential or simple crash path. The vulnerability lived where browser automation, WebSocket discovery, and network policy crossed.

That is exactly where serious security bugs often hide.

Policy Has To Follow The Connection

The policy failure is simple: blocking the first URL is not enough.

If a feature discovers a second destination, follows a redirect, accepts a derived WebSocket endpoint, or connects on behalf of a caller, that next hop has to pass the same policy checks. Otherwise, policy becomes decoration.

Here, Browser CDP discovery could accept a destination that should have been rejected.

The advisory classified the issue under:

• CWE-284: Improper Access Control
• CWE-918: Server-Side Request Forgery

That mapping tracks: an access-control miss around network reachability can become an SSRF-style path.

Agentic Systems Change the Security Model

This class of bug gets sharper in agentic systems.

Tools like OpenClaw connect models, plugins, browsers, gateways, local services, memory, APIs, and execution surfaces. Each feature may look safe in isolation, but risk changes when one trust boundary hands control to another.

A browser feature that accepts a debugger WebSocket is not just browser plumbing. It is a network reachability decision.

When reviewing a traditional web application, the question might be:

Can this endpoint be abused?

In an agentic framework, the better question is:

What can reach this feature, what trust level does that caller have, and what can this feature reach afterward?

That second question is where this vulnerability lived.

Scope and Mitigation

The patched version was OpenClaw 2026.6.6, and the advisory recommends upgrading to a patched release.

Additional hardening includes:

• Restricting affected browser features to trusted operators
• Disabling browser automation features when they are not needed
• Keeping channel and tool allowlists narrow
• Avoiding shared gateways between mutually untrusted users
• Disabling unnecessary features by default

Scope is important. This issue did not change OpenClaw's trusted-operator model. Authenticated gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or authentication boundary is crossed.

Good security work is not about labeling every edge case as catastrophic. It is about identifying the real boundary, proving when it matters, and fixing the path where enforcement failed.

The Takeaway

Agentic security needs to treat discovery and connection logic as security-sensitive code.

It is easy to focus on the obvious dangerous features: shell commands, file writes, credential access, browser actions, and plugin execution. But supporting logic can be just as important.

Discovery endpoints, URL normalization, redirects, WebSocket handoffs, metadata parsing, and backend selection can all become policy bypass paths.

If a system blocks a destination, every route to that destination has to be blocked too.

That includes:

• Direct requests
• Redirects
• Discovered URLs
• Derived WebSocket endpoints
• Helper features that connect on behalf of the caller

This vulnerability was accepted because it exposed a real policy enforcement gap. The fix closed a path where Browser CDP discovery could accept something policy should have rejected.

That is the kind of issue I expect to see more often as agent frameworks become more powerful. The dangerous part is not always one obvious exploit. Sometimes it is a small mismatch between what policy says and what a feature actually does when it follows a secondary connection path.

In agentic systems, those mismatches matter.