CVE-2026-34511: 
OpenClaw (formerly Moltbot or Clawdbot) vulnerability analysis and mitigation

CVE-2026-34511 is a PKCE verifier exposure vulnerability in OpenClaw's Gemini OAuth flow, where the PKCE verifier is incorrectly reused as the OAuth state parameter. This implementation flaw causes the PKCE verifier to be reflected back in the OAuth redirect URL, exposing it alongside the authorization code to any party who can capture that URL. The vulnerability affects all OpenClaw (npm) versions prior to 2026.4.2 and was disclosed on April 3, 2026. It carries a CVSS v3.1 base score of 5.9 (Medium) and a CVSS v4.0 base score of 6.0 (Medium) (GitHub Advisory, Github Advisory).

The root cause is classified as CWE-330 (Use of Insufficiently Random Values), specifically an implementation error where the buildAuthUrl() function in extensions/google/oauth.flow.ts passed the PKCE verifier value directly as the OAuth state parameter instead of generating an independent random value (GitHub Commit). PKCE (Proof Key for Code Exchange) is designed to prevent authorization code interception attacks by binding the code exchange to a secret verifier known only to the client; reusing it as the state parameter defeats this protection because the OAuth provider reflects state back in the redirect URL, making the verifier observable. An attacker positioned to intercept or observe the redirect URL (e.g., via browser history, referrer headers, proxy logs, or a malicious redirect target) can extract both the authorization code and the PKCE verifier, then independently redeem the authorization code for tokens (GitHub Advisory). The fix, introduced in commit a26f4d0, adds a dedicated generateOAuthState() function that produces a cryptographically independent 32-byte random hex value for the state parameter, fully separating it from the PKCE verifier (GitHub Commit).

Successful exploitation allows an attacker who captures the OAuth redirect URL to obtain both the authorization code and the PKCE verifier, enabling them to redeem the authorization code for OAuth tokens and gain unauthorized access to the victim's account. The primary impact is a high confidentiality loss — specifically, unauthorized access to the user's Gemini/Google account credentials and any data accessible via those tokens. Integrity and availability are not directly impacted by this vulnerability (GitHub Advisory, Github Advisory).

There is no known public proof-of-concept exploit and no evidence of active in-the-wild exploitation as of the time of disclosure (Feedly). The EPSS score is approximately 0.029%, reflecting a low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to intercept or observe the OAuth redirect URL during an active user authentication session, which introduces a meaningful prerequisite (passive user interaction and network-level access or log access), limiting the attack surface compared to fully unauthenticated, zero-interaction vulnerabilities (Github Advisory).

1. Identify target: Locate an OpenClaw installation running a version prior to 2026.4.2 where users authenticate via the Gemini OAuth flow.
2. Position for redirect URL capture: Gain a vantage point to observe the OAuth redirect URL — this could be via a network proxy, browser history access, referrer header leakage to a third-party resource on the redirect target page, or a compromised/malicious redirect endpoint.
3. Trigger OAuth flow: Wait for or socially engineer a target user to initiate the Gemini OAuth login flow in OpenClaw, which causes the application to construct an authorization URL with state set to the PKCE verifier value.
4. Capture the redirect URL: Intercept the redirect URL returned by the OAuth provider after the user authorizes the application. This URL contains both the code (authorization code) and state (which equals the PKCE verifier) parameters.
5. Extract credentials: Parse the redirect URL to extract the code parameter (authorization code) and the state parameter (PKCE verifier).
6. Redeem authorization code: Submit a token exchange request to the OAuth token endpoint, supplying the captured code and code_verifier (the extracted state value). Because the PKCE verifier is now known, the token endpoint accepts the request and issues access and refresh tokens.
7. Achieve unauthorized access: Use the obtained tokens to access the victim's Gemini/Google account resources (GitHub Advisory, GitHub Commit).

• Network: OAuth token exchange requests originating from an IP address different from the one that initiated the authorization request; token redemption requests arriving after an unusual delay following the authorization code issuance.
• Logs: OAuth provider logs showing a token exchange for an authorization code where the originating IP of the exchange differs from the IP that performed the authorization step; multiple token exchange attempts for the same authorization code.
• Application Logs: OpenClaw access logs showing OAuth callback URLs being accessed or replayed from unexpected sources; state parameter values appearing in referrer headers sent to third-party resources.
• Authentication Events: Unexpected new sessions or logins to Gemini/Google accounts from unfamiliar IP addresses or devices shortly after a user completes an OpenClaw OAuth flow.

Upgrade OpenClaw (npm package) to version 2026.4.2 or later, which separates the OAuth CSRF state from the PKCE verifier by introducing an independent generateOAuthState() function (GitHub Commit). No configuration-based workaround is available for unpatched versions; the fix requires a code change. As additional precautions, administrators should review OAuth flow implementations to ensure PKCE verifiers are never reused as state parameters, and monitor authentication logs for signs of redirect URL interception or anomalous token exchange activity (Feedly).

The vulnerability was reported by researcher @BG0ECV and credited in the GitHub security advisory (GitHub Advisory). A brief technical write-up was published on dev.to summarizing the PKCE verifier exposure issue. No significant broader media coverage or notable security community debate has been observed beyond standard CVE tracking and advisory aggregation.