CVE-2026-34511: PKCE Verifier Exposure via OAuth State Parameter in OpenClaw

The OpenClaw Gemini extension utilizes the OAuth 2.0 authorization code flow with Proof Key for Code Exchange (PKCE) to authenticate users and obtain access to Google APIs. PKCE is a security extension specified in RFC 7636 designed to protect public clients from authorization code interception attacks. It achieves this by dynamically generating a cryptographic secret (the verifier) and an associated challenge for every authorization request.

CVE-2026-34511 represents a critical implementation flaw in this protocol. The vulnerability occurs because the application maps the highly sensitive code_verifier directly to the OAuth 2.0 state parameter. The state parameter is defined in RFC 6749 as an opaque value used to maintain state between the request and callback, primarily for Cross-Site Request Forgery (CSRF) protection. By design, the authorization server reflects the state value back to the client unaltered via the redirect URI.

This architectural error results in a parameter isolation violation (CWE-1259) and the exposure of sensitive information (CWE-200). The secret verifier is transmitted over the front-channel and is visible in the user's browser URL field. The primary consequence is the total nullification of the PKCE security model.

The root cause of CVE-2026-34511 lies in the flawed generation and assignment of authorization parameters within the extensions/google module. A secure PKCE implementation requires strict isolation between the front-channel (the browser redirect) and the back-channel (the direct server-to-server token exchange). The code_verifier must remain exclusively in the back-channel.

In the vulnerable OpenClaw implementation, the generatePkce() function correctly outputs a high-entropy verifier string and computes its SHA-256 hash to create the challenge. However, the subsequent routine, buildAuthUrl(), accepts both the challenge and the verifier. The function assigns the challenge to the code_challenge query parameter and explicitly assigns the verifier to the state query parameter.

When the user is redirected to the Google authorization server, the state parameter is included in the GET request. Following successful authentication, Google constructs the callback URI to the OpenClaw client. In accordance with the OAuth 2.0 specification, Google appends the generated authorization code and the exact value of the state parameter to the callback URI. Because the state parameter contains the plaintext code_verifier, the secret is exposed in the front-channel.

The vulnerability is evident in the parameter construction logic of the OAuth flow. The original implementation failed to generate an independent CSRF token, opting instead to reuse existing cryptographic material. This approach breaks the required parameter isolation constraints.

Before the patch, the application constructed the authorization URL as follows:

// Vulnerable Implementation (Pre-2026.4.2)
export function buildAuthUrl(challenge: string, verifier: string): string {
  const params = new URLSearchParams({
    response_type: "code",
    client_id: CLIENT_ID,
    redirect_uri: REDIRECT_URI,
    code_challenge: challenge,
    code_challenge_method: "S256",
    state: verifier // CRITICAL FLAW: Verifier exposed as state
  });
  return `${AUTH_URL}?${params.toString()}`;
}

The patch introduced in commit a26f4d0f3ef0757db6c6c40277cc06a5de76c52f corrects this by decoupling the state generation from the PKCE generation. A Cryptographically Secure Pseudorandom Number Generator (CSPRNG) is utilized to create an independent state value.

// Patched Implementation (2026.4.2)
import { randomBytes } from "crypto";
 
export function generateOAuthState(): string {
  return randomBytes(32).toString("hex"); // CSPRNG for state
}
 
export function buildAuthUrl(challenge: string, state: string): string {
  const params = new URLSearchParams({
    response_type: "code",
    client_id: CLIENT_ID,
    redirect_uri: REDIRECT_URI,
    code_challenge: challenge,
    code_challenge_method: "S256",
    state // Safe: Independent state value
  });
  return `${AUTH_URL}?${params.toString()}`;
}

This fix guarantees that the code_verifier remains entirely out of the front-channel URL construction. The loginGeminiCliOAuth flow was concurrently updated to persist and validate this new state value independently from the PKCE data.

Exploitation of CVE-2026-34511 requires the attacker to observe or intercept the redirect URI during the OAuth flow. The authorization code interception attack targets the front-channel communication. Because the vulnerable application places the code_verifier in the URL, any mechanism that captures the URL will compromise the PKCE flow.

First, the user initiates the "Login to Gemini" sequence. The OpenClaw application redirects the user's browser to the Google OAuth endpoint. The attacker does not need to intercept this initial request. After the user authenticates, Google redirects the browser to the OpenClaw callback URL. This URL is structured as http://localhost:8085/oauth2callback?code=[AUTH_CODE]&state=[VERIFIER].

The attacker extracts the callback URL. Interception vectors include local browser history access, network proxies, shoulder surfing, or malicious browser extensions. With the URL captured, the attacker possesses both the short-lived authorization code and the state parameter, which contains the plaintext code_verifier.

The attacker executes a direct POST request to https://oauth2.googleapis.com/token providing the extracted code and code_verifier. Because the provided verifier matches the initial code_challenge, the authorization server validates the request and issues the access and refresh tokens directly to the attacker.

The successful exploitation of CVE-2026-34511 leads to a complete bypass of the OAuth 2.0 authorization code flow security model. The primary impact is High Confidentiality (VC:H in CVSS v4.0). The attacker gains unauthorized access to the victim's Google/Gemini account scoped to the permissions requested by the OpenClaw application.

The compromised tokens allow the attacker to issue commands to the Gemini API masquerading as the victim. Because the attacker obtains a refresh token in addition to the access token, the unauthorized access is persistent. The attacker can continually mint new access tokens until the victim explicitly revokes the OpenClaw application's authorization in their Google account security settings.

The CVSS v3.1 base score is 5.3 (Medium), characterized by the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N. The attack complexity is evaluated as High (AC:H) because the attacker requires specific situational positioning to intercept the transient redirect URI. The CVSS v4.0 score evaluates to 6.0, reflecting the identical technical severity but adjusting for the updated metric framework regarding attack requirements.

Organizations and users deploying the OpenClaw Gemini extension must upgrade to version 2026.4.2 immediately. The patch implemented in commit a26f4d0f3ef0757db6c6c40277cc06a5de76c52f correctly enforces parameter isolation by generating an independent, high-entropy state variable.

If immediate patching is not technically feasible, administrators should treat all environments running vulnerable versions of OpenClaw as insecure. There are no application-level configuration workarounds to prevent the state parameter reflection because the behavior is hardcoded into the vulnerable extension module.

Users who have previously authenticated via the vulnerable OpenClaw extension should consider their OAuth tokens potentially compromised if they suspect local interception. To mitigate historical exposure, users must navigate to their Google Account Security dashboard, locate third-party applications with account access, and revoke the permissions granted to OpenClaw. Following the software upgrade, users must re-authenticate to establish a secure, PKCE-protected token session.