GHSA-6MGF-V5J7-45CR: Sensitive Information Leak via Cross-Origin Redirects in OpenClaw

GHSA-6MGF-V5J7-45CR identifies a sensitive information disclosure vulnerability within the OpenClaw project. The flaw resides specifically in the fetch-guard component, which provides the fetchWithSsrFGuard utility for secure HTTP requests. This component is designed to prevent Server-Side Request Forgery (SSRF) and manage request state during cross-origin interactions.

The vulnerability manifests when the utility handles HTTP redirect responses (such as 301 or 302 status codes) that point to a different origin. During this transition, the client must evaluate which HTTP headers are safe to forward to the new destination. Improper header management allows sensitive authentication data to leak to unauthorized third-party domains.

The root cause is an insecure fail-open design relying on a denylist for header sanitization. Custom headers used for application-specific authentication are not removed before the client follows the redirect. This behavior violates the principle of least privilege regarding data transmission boundaries.

The vulnerability originates from the header sanitization logic in src/infra/net/fetch-guard.ts. The implementation utilized a predefined denylist array named CROSS_ORIGIN_REDIRECT_SENSITIVE_HEADERS. This array explicitly identified standard authentication headers, such as authorization, proxy-authorization, and cookie, for removal during a cross-origin transition.

When fetchWithSsrFGuard intercepted a redirect to a new origin, it iterated through the outgoing request headers and checked them against this denylist. If a header matched a denylist entry, the function removed it. Any header absent from the denylist was preserved and attached to the subsequent request to the new origin.

This fail-open approach fundamentally fails to account for custom authentication schemes. Modern web applications and APIs frequently utilize non-standard headers, such as X-Api-Key, Private-Token, or X-Auth-Token, to transmit secret material. Because these custom headers were absent from the hardcoded denylist, the sanitization logic ignored them, ensuring their unrestricted delivery to the redirect target.

The vulnerable implementation explicitly targeted a narrow set of well-known headers. The original array definition restricted sanitization to only four specific strings. This rigid implementation offered zero protection for APIs employing custom token headers.

// Original vulnerable implementation
const CROSS_ORIGIN_REDIRECT_SENSITIVE_HEADERS = [
  "authorization",
  "proxy-authorization",
  "cookie",
  "cookie2",
];

Commit 46715371b0612a6f9114dffd1466941ac476cef5 rectifies this flaw by replacing the denylist with a strict allowlist. The patch introduces CROSS_ORIGIN_REDIRECT_SAFE_HEADERS, a Set containing only intrinsically safe HTTP headers such as accept, content-type, and user-agent. This shift to a default-deny posture ensures that unknown or custom headers are implicitly rejected.

// Patched implementation utilizing an allowlist
function stripSensitiveHeadersForCrossOriginRedirect(init?: RequestInit): RequestInit | undefined {
  if (!init?.headers) return init;
  const incoming = new Headers(init.headers);
  const headers = new Headers();
  for (const [key, value] of incoming.entries()) {
    if (CROSS_ORIGIN_REDIRECT_SAFE_HEADERS.has(key.toLowerCase())) {
      headers.set(key, value);
    }
  }
  return { ...init, headers };
}

The patched logic constructs an entirely new Headers object. It iterates through the incoming request headers and copies only the keys that explicitly match the allowlist. This architectural change completely eliminates the risk of custom header leakage during origin transitions.

Exploitation requires an attacker to control the redirection target of a request initiated by the vulnerable OpenClaw client. The attacker must position a malicious redirector in the request path. This can occur if the OpenClaw client requests an external resource that the attacker compromises, or if an existing Server-Side Request Forgery vulnerability allows the attacker to specify the initial request URL.

Once the client initiates a request containing custom authentication headers to the initial endpoint, the server responds with an HTTP 302 redirect pointing to the attacker-controlled domain. The OpenClaw client intercepts this redirect, evaluates the cross-origin state, and applies the flawed denylist sanitization.

The attacker server receives the follow-up request exactly as it was formulated for the original domain. Because the custom headers bypassed the denylist, they are transmitted in plain text within the request payload. The attacker extracts the leaked X-Api-Key or Private-Token directly from their web server access logs or via a custom listener script.

The primary impact of this vulnerability is the complete compromise of credentials transmitted via custom HTTP headers. Unauthorized actors who successfully capture these tokens gain the ability to impersonate the OpenClaw client. This facilitates unauthorized access to upstream APIs, internal microservices, or third-party platforms integrated with the affected application.

The severity is classified as High due to the potential for lateral movement and data exfiltration. If the leaked token possesses administrative privileges or grants access to sensitive customer data, the security boundary of the dependent system is entirely breached. The impact scales linearly with the permission level of the exposed credential.

This vulnerability strictly impacts custom authentication implementations. Environments relying solely on standard Authorization headers or cookies remain protected by the original denylist logic. However, modern API architectures heavily favor custom token headers, making this exposure highly relevant to contemporary enterprise deployments.

The definitive remediation for this vulnerability requires upgrading the OpenClaw dependency. Security engineering teams must update all instances of the OpenClaw library to version v2026.3.7. This release contains the mandatory architectural shift from header denylisting to strict allowlisting.

Prior to deployment, organizations must conduct an impact analysis to determine if custom authentication headers are utilized within their environments. Administrators must review outbound proxy logs and web application firewalls for unexpected cross-origin redirects originating from the fetchWithSsrFGuard utility.

If log analysis indicates anomalous redirect activity preceding the application of the patch, incident response teams must assume token compromise. All custom API keys, private tokens, and service account credentials associated with the affected HTTP clients must be immediately revoked and regenerated.