GHSA-j4c5-89f5-f3pm: Server-Side Request Forgery via CDP Profile Configuration in OpenClaw

OpenClaw provides browser automation capabilities via the Chrome DevTools Protocol (CDP). Administrators configure connection endpoints using the cdpUrl parameter within browser profiles. The application enforces a Server-Side Request Forgery (SSRF) policy to restrict the destinations the browser can navigate to. This mechanism prevents the automated agent from accessing sensitive internal networks or untrusted external domains.

The vulnerability exists in how OpenClaw parses these profile configurations. The application extracts hostnames from all configured CDP profiles and automatically appends them to a global allowlist. This allowlist governs the primary navigation-guard.js component. Consequently, providing a hostname for a CDP connection inadvertently authorizes the browser to navigate to that same host.

This architecture flaw constitutes a Server-Side Request Forgery (CWE-918) vulnerability. An attacker with the ability to define or modify browser profiles can bypass strict-mode SSRF restrictions. The impact is primarily restricted to environments where the AI agent operates alongside sensitive internal services or cloud metadata endpoints.

The vulnerability stems from an insecure merging of configuration domains. In the affected versions, the application initializes its browser configuration by iterating over all defined user profiles. The function collectConfiguredCdpHostnames systematically gathers every hostname specified in a profile's cdpUrl field.

The flaw materializes when the application constructs the global ssrfPolicy object. The gathered CDP hostnames are passed directly into the resolveBrowserSsrFPolicy function. This function merges the extracted CDP hostnames into the allowedHostnames array, which defines the global navigation boundaries for the browser instance.

The application fails to distinguish between a hostname required for internal CDP connectivity and a hostname authorized for general web navigation. The navigation-guard.js component relies entirely on the allowedHostnames array to authorize requests. Once a hostname enters this array via the CDP configuration, the browser executes navigation requests to that destination without encountering policy violations.

The vulnerable logic resides in extensions/browser/src/browser/config.ts. The implementation automatically injected the parsed hostnames into the application's global SSRF policy. This action tightly coupled the backend connectivity requirements with the frontend navigation guard.

// Vulnerable implementation in config.ts
function collectConfiguredCdpHostnames(cfg: BrowserConfig | undefined): string[] {
  const hostnames = new Set<string>();
  const addHostnameFromUrl = (rawUrl: string | undefined): void => {
    // Extracts hostname from the raw URL
  };
  addHostnameFromUrl(cfg?.cdpUrl);
  for (const profile of Object.values(cfg?.profiles ?? {})) {
    addHostnameFromUrl(profile?.cdpUrl);
  }
  return Array.from(hostnames);
}
 
// The vulnerability: merging the output into the global policy
ssrfPolicy: resolveBrowserSsrFPolicy(cfg, collectConfiguredCdpHostnames(cfg)),

The remediation strategies implemented in commits e90c89cf8b1459f2aa1f3a665be67392b6c03fdf and 1fd049e3074cac72f6734a7fe88468c84f5f8bd7 correctly decouple these two contexts. The development team removed the global merging behavior from config.ts entirely. The system now initializes the ssrfPolicy without the CDP hostnames.

// Patched implementation in config.ts
- ssrfPolicy: resolveBrowserSsrFPolicy(cfg, collectConfiguredCdpHostnames(cfg)),
+ ssrfPolicy: resolveBrowserSsrFPolicy(cfg),

To maintain necessary backend functionality, the patch introduces a new, specialized policy in extensions/browser/src/browser/cdp-reachability-policy.ts. The resolveCdpReachabilityPolicy function handles CDP health checks independently. This ensures the application can verify CDP connectivity without exposing the destination to the primary browser navigation engine. This architectural split completely neutralizes the attack vector.

Exploitation requires the attacker to possess configuration privileges or the ability to supply malicious profile definitions to the OpenClaw instance. The attacker initiates the exploit chain by submitting a profile creation payload containing a targeted internal IP address in the cdpUrl field.

A typical payload targets cloud metadata services or internal management interfaces. The attacker submits a JSON structure defining the malicious profile. The backend processes this configuration and silently populates the allowedHostnames array with the target IP address.

{
  "name": "ssrf_bypass_profile",
  "cdpUrl": "http://169.254.169.254"
}

Following profile creation, the attacker interacts with the OpenClaw agent and instructs it to browse the targeted internal resource. The agent issues the navigation request to the embedded browser. The navigation-guard.js component validates the request against the contaminated allowlist, authorizes the transaction, and returns the internal response to the attacker.

The primary consequence of this vulnerability is unauthorized access to network resources that are otherwise protected by strict-mode SSRF boundaries. The AI agent acts as a proxy, retrieving and relaying data from internal endpoints. The precise impact depends entirely on the environment hosting the OpenClaw instance.

In cloud environments, this vulnerability permits access to Instance Metadata Services (IMDS). An attacker can direct the agent to navigate to 169.254.169.254 and retrieve sensitive metadata, including temporary IAM credentials. These credentials facilitate lateral movement into the broader cloud infrastructure.

In on-premises or traditional network deployments, the agent can interact with internal web applications, administrative panels, or unauthenticated APIs. The severity of this vulnerability is classified as Low because the attack prerequisites are restrictive. The attacker must already possess administrative control over the application's profile configuration or social engineer an administrator into importing a malicious profile.

The complete mitigation for this vulnerability requires upgrading the OpenClaw installation. System administrators must deploy OpenClaw version 2026.4.18 or a subsequent release. This version incorporates the architectural decoupling of the CDP reachability policy and the global SSRF navigation policy.

Organizations that cannot apply the patch immediately must implement compensating controls. Administrators should review the configuration file and enforce strict validation on profile creation. The application must run with dangerouslyAllowPrivateNetwork explicitly set to false to maintain existing SSRF protections.

Security teams should also review the hostnameAllowlist within the ssrfPolicy configuration to ensure only explicitly trusted domains are present. Implementing network-level egress filtering provides an additional defense layer. Configuring the host firewall to block outbound connections from the OpenClaw process to sensitive internal subnets neutralizes the SSRF risk regardless of the application's configuration state.