CVE-2026-34511: OpenClaw OAuth Auth Bypass Vulnerability

CVE-2026-34511 Overview

OpenClaw before version 2026.4.2 contains a cryptographic vulnerability where the application reuses the PKCE (Proof Key for Code Exchange) verifier as the OAuth state parameter in the Gemini OAuth flow. This design flaw exposes the PKCE verifier through the redirect URL, allowing attackers who can capture the redirect URL to obtain both the authorization code and the PKCE verifier. This effectively defeats the PKCE protection mechanism and enables unauthorized token redemption.

Critical Impact

Attackers can bypass PKCE security controls to intercept OAuth authorization flows and redeem tokens on behalf of legitimate users, potentially leading to account takeover and unauthorized access to protected resources.

Affected Products

• OpenClaw versions prior to 2026.4.2

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-34511 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-34511

Vulnerability Analysis

This vulnerability falls under CWE-330 (Use of Insufficiently Random Values) and represents a fundamental misunderstanding of OAuth 2.0 security controls. PKCE was designed as an extension to the authorization code flow to protect against authorization code interception attacks, particularly for public clients that cannot securely store client secrets.

The security of PKCE relies on the verifier remaining secret until the token exchange phase. By reusing the PKCE verifier as the OAuth state parameter, OpenClaw inadvertently exposes this secret value in the redirect URL after user authorization. The OAuth state parameter is visible in browser history, server logs, referrer headers, and potentially to malicious browser extensions or man-in-the-middle attackers.

When an attacker captures a redirect URL containing both the authorization code and the exposed PKCE verifier (via the state parameter), they possess everything needed to complete the token exchange with the authorization server, completely bypassing the protection that PKCE was meant to provide.

Root Cause

The root cause is improper implementation of OAuth 2.0 security mechanisms. The PKCE verifier and OAuth state parameter serve distinct security purposes: the state parameter protects against CSRF attacks and should be tied to the user's session, while the PKCE verifier protects against authorization code interception and must remain confidential until token exchange. Reusing one value for both purposes violates the security model of PKCE by exposing the verifier in the redirect URL.

Attack Vector

The attack exploits the network-accessible OAuth flow and requires user interaction during the authentication process. An attacker positioned to observe redirect URLs—through techniques such as malicious browser extensions, compromised network infrastructure, referrer header leakage, or access to server logs—can capture the complete redirect URL after a user authorizes the OAuth request. This URL contains both the authorization code and the PKCE verifier (exposed via the state parameter). The attacker can then use these values to complete the token exchange before the legitimate client, obtaining valid access tokens for the victim's account.

The vulnerability mechanism involves the OAuth redirect URL containing sensitive parameters. When a user completes authorization, the redirect URL includes the authorization code and state parameter—where the state parameter contains the PKCE verifier that should have remained secret. For technical details and the specific fix, see the GitHub Security Advisory.

Detection Methods for CVE-2026-34511

Indicators of Compromise

• Unusual token redemption patterns where authorization codes are exchanged from unexpected IP addresses or user agents
• Multiple token exchange attempts for the same authorization code from different sources
• Authentication logs showing successful OAuth completions without corresponding user-initiated flows
• Access token usage patterns inconsistent with the legitimate user's typical behavior

Detection Strategies

• Monitor OAuth token exchange endpoints for requests originating from IP addresses that don't match the original authorization request
• Implement anomaly detection on authentication flows to identify potential authorization code theft
• Review server logs and referrer headers for potential leakage of redirect URLs containing OAuth parameters
• Audit application code for patterns where PKCE verifiers may be exposed or reused inappropriately

Monitoring Recommendations

• Enable detailed logging on OAuth authorization server endpoints including client IP, user agent, and timing information
• Set up alerts for multiple token exchange attempts using the same authorization code
• Monitor for unusual spikes in failed authentication attempts that may indicate token theft attempts
• Implement session correlation to detect when OAuth flows complete from different network locations than where they originated

How to Mitigate CVE-2026-34511

Immediate Actions Required

• Upgrade OpenClaw to version 2026.4.2 or later immediately
• Review authentication logs for signs of potential exploitation
• Invalidate and rotate any OAuth tokens that may have been compromised
• Audit any custom OAuth implementations for similar PKCE/state parameter confusion

Patch Information

The vulnerability has been addressed in OpenClaw version 2026.4.2. The fix properly separates the PKCE verifier from the OAuth state parameter, ensuring each serves its intended security purpose without exposing sensitive values. The patch can be reviewed in the GitHub Commit. Additional details are available in the GitHub Security Advisory and the VulnCheck Advisory.

Workarounds

• If immediate patching is not possible, consider temporarily disabling the Gemini OAuth flow until the update can be applied
• Implement additional network-level controls to reduce the risk of redirect URL interception
• Monitor OAuth flows closely for anomalous activity until the patch is deployed
• Consider implementing additional token binding or device attestation as defense-in-depth measures

Organizations should prioritize upgrading to the patched version as soon as possible, as workarounds do not fully address the underlying vulnerability.