Mar 3, 2026·5 min read·2 visits
OpenClaw for macOS accidentally exposed the secret PKCE `code_verifier` in the public OAuth URL `state` parameter. This allowed attackers to intercept both the authorization code and the verifier, enabling full account takeover of connected Anthropic accounts. The feature was removed in the fix.
A critical information exposure vulnerability was identified in the OpenClaw macOS application's onboarding flow, specifically within its integration with Anthropic's OAuth service. The application incorrectly transmitted the Proof Key for Code Exchange (PKCE) `code_verifier`—a secret cryptographic material intended to be kept private—within the public `state` parameter of the OAuth authorization URL. This architectural flaw meant that the secret verifier was exposed in the query string of the redirect URL. Because the `state` parameter travels via the browser front-channel, any attacker capable of intercepting the authorization code (for example, through malicious browser extensions, history sniffing, or local URL scheme monitoring) would simultaneously obtain the `code_verifier`. This negates the security protections offered by PKCE, allowing the attacker to exchange the intercepted code for a valid access token and take over the user's Anthropic session.
The vulnerability resides in the AnthropicOAuth module of the OpenClaw macOS application, specifically in the logic used to construct the authorization URL for Anthropic's service. OpenClaw utilizes the OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE) to securely connect users to their Anthropic accounts. PKCE is designed to prevent authorization code interception attacks by requiring the client to create a secret code_verifier and a corresponding code_challenge.
In a correct implementation, the code_challenge is sent in the initial authorization request, while the code_verifier is kept secret and only sent directly to the token endpoint (back-channel) to prove possession of the secret. OpenClaw's implementation, however, mistakenly assigned the secret code_verifier to the OAuth state parameter. The state parameter is transmitted in the URL query string and echoed back by the authorization server in the HTTP redirect.
This exposure creates a critical breach of the OAuth security model. Since the state parameter is visible in the browser address bar, logs, and history, the secret verifier becomes public knowledge to anyone observing the network traffic or the local machine's URL handling events. Consequently, the mechanism intended to protect the authorization code (PKCE) is rendered useless because the "key" to the code is attached to the code itself.
The root cause is a semantic misunderstanding of OAuth 2.0 parameters within the AnthropicOAuth.swift file. The developer conflated the state parameter (used for CSRF protection and application state preservation) with the code_verifier (a cryptographic secret used for authentication).
The vulnerability exists in the buildAuthorizeURL function. Instead of generating a random, opaque string for the state parameter, the application explicitly injected the sensitive pkce.verifier into the URL query items. The diagram below illustrates the broken flow compared to the standard secure flow.
By placing the verifier in the state, the application broadcasted the shared secret required to complete the login process. This error transforms a standard authorization code interception (which PKCE is meant to thwart) into a trivial exploitation path, as the attacker no longer needs to deduce the verifier—it is provided to them on a silver platter.
The critical flaw was located in AnthropicOAuth.swift. The specific function responsible for constructing the URL query parameters directly mapped the PKCE verifier to the state key.
Vulnerable Code (AnthropicOAuth.swift):
static func buildAuthorizeURL(pkce: PKCE) -> URL {
var components = URLComponents(url: self.authorizeURL, resolvingAgainstBaseURL: false)!
components.queryItems = [
URLQueryItem(name: "code", value: "true"),
URLQueryItem(name: "client_id", value: self.clientId),
URLQueryItem(name: "code_challenge", value: pkce.challenge),
// CRITICAL FLAW: The secret verifier is assigned to the public 'state' parameter
URLQueryItem(name: "state", value: pkce.verifier),
]
return components.url!
}Patch Analysis:
Rather than modifying the code to use a correct random state value, the maintainers opted to remove the entire AnthropicOAuth implementation. The commit 8f3310000a8b0c11eced054c2cdb6fb27803511a deletes AnthropicOAuth.swift, AnthropicAuthControls.swift, and related onboarding logic. The application moved away from this OAuth flow entirely, likely reverting to manual API key entry or a different authentication strategy that does not require this complex handshake. This remediation effectively eliminates the vulnerability by removing the affected attack surface.
Exploiting this vulnerability requires the ability to observe the redirect URL generated during the OAuth dance. On macOS, this is often achievable if the application registers a custom URL scheme (e.g., openclaw://) that other applications can invoke or monitor.
Step 1: Monitoring The attacker sets up a mechanism to observe URL opens or monitors network traffic if they are on the same local network (and TLS is not properly enforced or inspected). Alternatively, a malicious application installed on the victim's Mac could register itself as a handler for the specific URL scheme or monitor the system's clipboard/logs if the URL is copied.
Step 2: Interception
When the victim initiates the "Connect Claude" flow, the browser redirects to Anthropic and then back to the application. The return URL looks like this:
openclaw://callback?code=AUTH_CODE_123&state=SECRET_VERIFIER_ABC
Step 3: Extraction and Exchange The attacker parses this URL to extract:
code (AUTH_CODE_123)verifier (found in the state parameter: SECRET_VERIFIER_ABC)Step 4: Token Generation The attacker sends a standard POST request to Anthropic's token endpoint using these two stolen values. Since the verifier matches the challenge sent in the initial request (which the attacker didn't need to see), the server validates the request and issues an access token. The attacker now has persistent access to the victim's Anthropic account context.
The impact of this vulnerability is classified as Critical (CVSS 9.8). Successful exploitation leads to a full account takeover of the integrated service (Anthropic/Claude) within the context of the OpenClaw application.
Confidentiality: High. The attacker gains access to the victim's Anthropic API interactions, which may include sensitive prompts, completions, and potentially other data accessible via the compromised scope.
Integrity: High. The attacker can perform actions on behalf of the user, potentially manipulating data or consuming API credits (financial impact).
Availability: High. The attacker could revoke the user's legitimate tokens or exhaust quotas, denying service to the rightful owner.
Because the flaw occurs in the authentication handshake itself, it bypasses standard access controls. The reliance on PKCE was intended to secure the flow against interception, but the implementation error inverted this security property, making the secret explicitly available to interceptors.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
OpenClaw macOS OpenClaw | < Commit 8f33100 (2026-02-25) | Commit 8f33100 |
| Attribute | Detail |
|---|---|
| CVE ID | GHSA-6G25-PC82-VFWP |
| CVSS v3.1 | 9.8 (Critical) |
| CWE ID | CWE-598 |
| Attack Vector | Network (AV:N) |
| Impact | Information Exposure / Account Takeover |
| Remediation | Feature Removal |