OpenClaw, an npm package for handling Gemini OAuth flows, contained a critical flaw in versions up to 2026.4.1. Developers reused the PKCE verifier as the OAuth state parameter. Gemini’s OAuth provider echoes this state back in the redirect URL, right next to the authorization code. Result: anyone sniffing that URL grabs both pieces needed to exchange the code for an access token.
PKCE, defined in RFC 7636, exists to stop exactly this. Clients generate a random code_verifier (43-128 characters), hash it to a code_challenge, and send the challenge to the auth server. On callback, the server verifies the verifier matches the challenge before issuing tokens. It thwarts interception attacks where a bad actor steals the auth code but lacks the secret verifier. OpenClaw’s mistake defeated this entirely, turning a secure public client flow into a sitting duck.
Technical Breakdown
The bug lived in OpenClaw’s Gemini OAuth implementation. During authorization requests, the library set state = code_verifier. Gemini reflects state unchanged in the redirect, as OAuth 2.0 specs require for CSRF protection. Attackers on the same network, with access to browser history, server logs, or via MITM proxies, capture the full redirect: https://client.example/callback?code=AUTH_CODE&state=LEAKED_VERIFIER. They replay both to Gemini’s token endpoint and win valid tokens.
No exploits reported yet, but the risk scales with OpenClaw’s adoption. npm shows 2026.4.1 as the last vulnerable release; 2026.4.2 patches it via commit a26f4d0f3ef0757db6c6c40277cc06a5de76c52f, which generates a separate random state. Researcher @BG0ECV found and reported it responsibly. Check your package.json: run
npm ls openclawto audit versions. Update with
npm update openclaw or pin to >=2026.4.2.
Why This Matters and Broader Lessons
This isn’t isolated. OAuth libraries botch PKCE routinely—think Auth0 SDK leaks in 2022 or similar state mishandling in mobile apps. PKCE adoption surged post-OAuth 2.0 Security Best Practices (RFC 6819 updates), yet devs still fuse state and verifier, assuming “random is random.” Skeptical take: OpenClaw’s version scheme (2026.x?) suggests either prescience or sloppy tagging, but the core error stems from not reading the spec. OAuth state must be unique, unpredictable, and client-generated for CSRF, but never bear secrets like verifiers.
Implications hit apps integrating Gemini—likely AI or crypto services given the name. Stolen tokens grant full account access: read emails, spend crypto, or worse if scopes expand. In finance/tech stacks, this risks session hijacking across users. Network attackers (WiFi, ISP logs) or insiders (SaaS dashboards) exploit it silently. Why care? One compromised redirect poisons your auth flow until patch. Audit deps now; tools like npm audit or Snyk flag CVEs, but this one’s fresh.
Fixes are straightforward, but prevention demands rigor. Generate state via crypto.randomBytes(32).toString(‘base64url’), store in session, validate on callback—separate from PKCE. Test redirects in Burp Suite or similar to simulate leaks. For Njalla users: if your stack touches Gemini OAuth, swap OpenClaw or wrap it. Broader context: 70% of OAuth vulns trace to misconfigs per 2023 OWASP stats. Public clients without PKCE? Dead on arrival. Update, verify, and rotate tokens if exposed.
Bottom line: simple dev slip undid a key OAuth defense. Patch immediately if using OpenClaw <=2026.4.1. This exposes why trusting black-box libs fails—own your auth or pay later.
