The vulnerability lies in how OpenClaw's fetchWithSsrFGuard function handles headers during cross-origin redirects. The analysis of the provided patch commit 46715371b0612a6f9114dffd1466941ac476cef5 reveals the root cause. The file src/infra/net/fetch-guard.ts contains the core logic.
Previously, the function stripSensitiveHeadersForCrossOriginRedirect used a denylist (CROSS_ORIGIN_REDIRECT_SENSITIVE_HEADERS) to remove a small, fixed set of headers (Authorization, Proxy-Authorization, Cookie, Cookie2) before following a redirect to a different origin. This approach was flawed because it failed to account for custom, non-standard authorization headers like X-Api-Key or Private-Token. As a result, if a request using such a header was redirected to a different origin, these sensitive headers would be leaked to the new, potentially malicious, origin.
The patch corrects this by replacing the denylist with an allowlist (CROSS_ORIGIN_REDIRECT_SAFE_HEADERS). The stripSensitiveHeadersForCrossOriginRedirect function was modified to only preserve a predefined set of safe headers (e.g., Accept, Content-Type, User-Agent) during cross-origin redirects, effectively preventing any potentially sensitive or custom headers from being forwarded.
The primary entry point for this vulnerable behavior, as stated in the advisory, is fetchWithSsrFGuard. Therefore, both fetchWithSsrFGuard and its helper stripSensitiveHeadersForCrossOriginRedirect are identified as the key functions that would appear in a runtime profile when this vulnerability is triggered.