CVE-2026-81888: 
JavaScript Analyse et atténuation des vulnérabilités

CVE-2026-81888 is a Cross-Site Request Forgery (CSRF) vulnerability in @hono/oauth-providers, the OAuth authentication middleware for the Hono web framework. The flaw allows an attacker to bypass the OAuth state-based CSRF protection because the state check treats two absent values (no state in the callback and no stored state cookie) as a valid match, permitting a forged OAuth callback to succeed. It affects all versions of @hono/oauth-providers prior to 0.8.6, impacting the Google, GitHub, Facebook, Discord, Twitch, LinkedIn, and Microsoft Entra providers. The vulnerability was first published to the GitHub Advisory Database on July 16, 2026, and assigned CVE-2026-81888 with a CVSS v3.1 base score of 5.4 (Medium) (Github Advisory).

The root cause is a fail-open logic error in the OAuth callback state validation (CWE-352: Cross-Site Request Forgery; CWE-1275: Sensitive Cookie with Improper SameSite Attribute). The original code checked whether the URL contained a query string (c.req.url.includes('?')) before comparing the state query parameter to the stored cookie value — but if both were undefined, the equality check undefined !== undefined evaluated to false, causing the guard to pass silently. Additionally, the state cookie was not set with secure: true or sameSite: 'Lax', weakening cookie isolation. The fix (PR #2040, commit b37765f) changes the guard to explicitly reject any callback where either the stored cookie state or the incoming state query parameter is absent, and adds proper cookie attributes (Github Advisory, Fix PR, Fix Commit).

Successful exploitation enables two primary attack scenarios: login CSRF, where a victim's browser is tricked into completing an OAuth callback that authenticates them into the attacker's account (causing the victim to unknowingly operate within the attacker's session); and forced account linking, where the attacker's OAuth identity is silently linked to the victim's existing account, granting the attacker persistent access to the victim's account via future sign-in. Both scenarios result in low-to-moderate confidentiality and integrity impact with no availability impact, and affect any application using the vulnerable providers (Google, GitHub, Facebook, Discord, Twitch, LinkedIn, Microsoft Entra) on @hono/oauth-providers 0.8.5 or earlier (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the advisory publication date. The EPSS score is 0.0, indicating very low current probability of exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction — the attacker must trick a victim into clicking a crafted OAuth callback URL — but requires no privileges and has low attack complexity (Github Advisory).

1. Identify target application: Locate a web application built with Hono that uses @hono/oauth-providers version 0.8.5 or earlier with one of the affected providers (Google, GitHub, Facebook, Discord, Twitch, LinkedIn, or Microsoft Entra).
2. Obtain attacker's OAuth authorization code: The attacker initiates a legitimate OAuth flow with the target provider using their own account, obtaining a valid code from the provider's authorization endpoint (without completing the flow).
3. Craft a forged callback URL: Construct a callback URL to the victim application's OAuth callback endpoint that includes only the attacker's code parameter and omits the state parameter entirely (e.g., https://victim.app/auth/google/callback?code=ATTACKER_CODE).
4. Deliver the URL to the victim: Trick the victim into navigating to the crafted callback URL (e.g., via phishing email, malicious link, or iframe). Because the victim has no state cookie stored and the callback omits state, both values are undefined and the vulnerable check passes.
5. Achieve account takeover or linking: The victim's browser completes the OAuth exchange using the attacker's authorization code, binding the attacker's identity to the victim's session (login CSRF) or linking the attacker's OAuth identity to the victim's account (forced account linking), enabling the attacker to later sign in as the victim (Github Advisory, Fix PR).

• Network: Incoming GET requests to OAuth callback endpoints (e.g., /auth/google/callback, /auth/github/callback) that include a code query parameter but lack a state query parameter.
• Logs: Server access logs showing OAuth callback requests with no state parameter and no corresponding state cookie in the request headers; successful 200 responses to such requests on vulnerable versions.
• Application Behavior: Unexpected account linking events or session authentications that do not correspond to a user-initiated login flow; users reporting being logged into an unfamiliar account after clicking a link.

Upgrade @hono/oauth-providers to version 0.8.6 or later, which fixes the fail-open state check by explicitly rejecting callbacks where either the stored cookie state or the incoming state query parameter is absent, and sets secure: true and sameSite: 'Lax' on the state cookie. No configuration-based workaround is available for the default middleware behavior in earlier versions; upgrading is the only reliable remediation. The X (Twitter) provider is not affected due to its PKCE binding and does not require action (Github Advisory, Release Notes).