GHSA-rhfg-j8jq-7v2h: Server-Side Request Forgery via Unguarded Base URLs in OpenClaw Extensions

OpenClaw operates an extensible architecture that integrates with various third-party communication channels. Administrators configure these integrations by supplying base URLs and API credentials for target platforms. A previous vulnerability, identified as CVE-2026-28476, exposed a Server-Side Request Forgery (SSRF) flaw in the Tlon Urbit extension, which was patched by introducing a dedicated request validation wrapper.

Subsequent analysis revealed that the implemented fix was incomplete. The validation logic was localized to the Tlon extension rather than applied globally to the core HTTP client. Consequently, several other active channel integrations—specifically Mattermost, Nextcloud-Talk, and BlueBubbles—retained vulnerable code paths.

This architectural oversight resulted in GHSA-rhfg-j8jq-7v2h, classified under CWE-918 (Server-Side Request Forgery). An attacker possessing sufficient privileges to modify channel extension configurations can exploit this vulnerability. By supplying a maliciously crafted URL pointing to internal infrastructure, the attacker forces the OpenClaw server to act as a proxy for unauthorized network requests.

The application relies on HTTP clients to synchronize state and transmit messages to external channel APIs. The root cause of this vulnerability lies in the direct, unvalidated consumption of user-provided baseUrl strings by these HTTP clients. When an administrator configures a channel, the application constructs endpoint URIs by appending specific API paths to the provided base URL.

The developers introduced a security component named fetchWithSsrFGuard during the remediation of CVE-2026-28476. This guard implements critical SSRF protections, including IP address denylists for RFC 1918 (private) and RFC 3927 (link-local) ranges, alongside DNS pinning to prevent Time-of-Check to Time-of-Use (TOCTOU) DNS rebinding attacks. However, the application developers failed to enforce the usage of this guard across the entire extension ecosystem.

Extensions such as BlueBubbles and Mattermost continued to invoke the standard Node.js fetch() API or unvalidated internal utilities. Because these raw functions do not perform secondary validation on the resolved IP addresses, they willingly connect to internal network segments if the provided hostname resolves to a restricted IP address. The lack of a centralized, default-deny outbound network policy allowed the vulnerability to persist in parallel components.

Prior to version 2026.3.26, the BlueBubbles and Mattermost extensions instantiated their API clients using the raw configuration object. The vulnerable implementation directly passed the unsanitized URL to the fetch execution context.

// Vulnerable Implementation (Pre-Patch)
class MattermostClient {
  constructor(config) {
    this.baseUrl = config.baseUrl;
  }
 
  async sendMessage(payload) {
    // Directly consumes the unguarded baseUrl
    const response = await fetch(`${this.baseUrl}/api/v4/posts`, {
      method: 'POST',
      body: JSON.stringify(payload)
    });
    return response.json();
  }
}

The remediation introduced in commit f92c92515bd439a71bd03eb1bc969c1964f17acf fundamentally alters this architecture. The patch refactors all outbound HTTP communication within the affected extensions to route through the guardedFetchImpl wrapper. Additionally, it introduces an allowPrivateNetwork boolean flag, enforcing a strict security boundary by default.

// Patched Implementation (Commit: f92c92515bd439a71bd03eb1bc969c1964f17acf)
class MattermostClient {
  constructor(config) {
    this.baseUrl = config.baseUrl;
    // Explicit security policy extraction
    this.allowPrivateNetwork = config.allowPrivateNetwork || false;
  }
 
  async sendMessage(payload) {
    // Routes through the SSRF guard with strict policies applied
    const response = await fetchWithSsrFGuard(`${this.baseUrl}/api/v4/posts`, {
      method: 'POST',
      body: JSON.stringify(payload),
      allowPrivateNetwork: this.allowPrivateNetwork
    });
    return response.json();
  }
}

The fetchWithSsrFGuard implementation mitigates DNS rebinding by explicitly resolving the hostname using dns.lookup, validating the resulting IP address against the denylist, and then directly connecting to that IP address while manually setting the Host header to the original domain.

Exploitation requires the attacker to hold administrative or configuration modification privileges within the OpenClaw application. The attacker begins by accessing the configuration interface for one of the vulnerable extensions, such as BlueBubbles or Nextcloud-Talk.

The attacker modifies the baseUrl parameter to point to a targeted internal asset. For example, to target a local service running on the OpenClaw server, the attacker inputs http://127.0.0.1:8080. To target cloud metadata services in an AWS environment, the attacker inputs http://169.254.169.254/latest/meta-data/.

Upon saving the configuration, the attacker triggers a synchronization event or sends a test message through the interface. The OpenClaw backend constructs the full URI and issues the HTTP request. Depending on the specific extension's error handling and logging mechanisms, the HTTP response body or status codes from the internal service are returned to the attacker, confirming the successful request execution.

Post-patch environments require ongoing scrutiny. Security assessments must verify that the fetchWithSsrFGuard accurately handles HTTP 3xx redirects. If the guard validates the initial URL but the underlying HTTP client blindly follows a redirect to a private IP address, the protection is nullified. Furthermore, edge-case IP representations, such as IPv6-mapped IPv4 addresses (::ffff:127.0.0.1), must be explicitly handled by the IP validation logic to prevent evasion.

Successful exploitation of this vulnerability yields comprehensive read access to internal network environments that are otherwise isolated from external routing. By leveraging the OpenClaw application as a proxy, the attacker bypasses perimeter firewalls and network access control lists.

In cloud deployments, the impact severity increases significantly. If the OpenClaw instance resides in AWS, GCP, or Azure, the SSRF primitive allows the attacker to query the instance metadata service (IMDS). This interaction facilitates the extraction of temporary IAM credentials, cloud environment variables, and instance provisioning scripts, often leading to full cloud environment compromise.

Within local or corporate networks, the attacker can systematically scan internal subnets to identify active hosts and open ports. The attacker can interact with unauthenticated internal APIs, administrative panels, and database instances. If adjacent internal services harbor unauthenticated remote code execution vulnerabilities, this SSRF acts as the critical initial access vector to pivot laterally and execute code on internal systems.

The primary remediation for GHSA-rhfg-j8jq-7v2h is upgrading OpenClaw to version 2026.3.26 or later. This release enforces the usage of the fetchWithSsrFGuard component across all channel extensions and implements the allowPrivateNetwork policy flag, which defaults to a secure, restrictive posture.

Organizations unable to immediately deploy the patch must implement strict access controls on the OpenClaw administrative interface. Restrict configuration capabilities to highly trusted personnel and audit all existing channel extension configurations to verify that the baseUrl parameters point exclusively to legitimate, public-facing domain names.

As a defense-in-depth measure, administrators should configure network-level isolation for the OpenClaw host. Deploy egress filtering rules on the host firewall or network security groups to explicitly block outbound connections to RFC 1918 and RFC 3927 IP ranges. In cloud environments, enforcing IMDSv2 (which requires session tokens) effectively neutralizes the threat of metadata extraction via basic SSRF vectors.