@hono/oauth-providers CVE-2026-81888

Exploitation requires the target application to be using @hono/oauth-providers version 0.8.5 or earlier with at least one of these providers configured: google, github, facebook, discord, twitch, linkedin, or msentra. The x (Twitter) provider is not exploitable due to PKCE binding. The attacker must control a valid authorization code from the target identity provider (obtained by initiating their own legitimate OAuth flow with that provider), and must be able to deliver a crafted URL to the victim. The victim must actively follow the crafted OAuth callback URL - consistent with CVSS UI:R - which requires social engineering (phishing, malicious redirect, or open redirect on the application). No authentication on the target application is required by the attacker (CVSS PR:N). Exploitation is limited by the victim not having a current valid state cookie for that provider, and by the attacker needing an active authorization code (which has a short TTL, typically minutes) at the time the victim clicks the link.

The CVSS 5.4 Medium score with vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N accurately reflects the threat model: the attack is network-delivered and requires no privileges on the target application, but depends on social engineering a victim to follow a crafted link (UI:R), which is the primary friction point. EPSS data was not provided, and this vulnerability is not listed in CISA KEV, so exploitation probability must be inferred from the attack's mechanical simplicity - any developer familiar with OAuth CSRF patterns could construct this attack without tooling. The confidentiality and integrity impacts are assessed as low-to-moderate in practical terms: login CSRF silently logs a victim into the attacker's account (leaking victim activity), while forced account linking grants the attacker persistent durable access to the victim's account on the application, which operationally may exceed the C:L/I:L CVSS rating depending on what the application does. No public proof-of-concept code has been identified, which reduces near-term opportunistic risk. The scope is bounded to npm applications explicitly using this package and one of the seven named providers; the x/Twitter provider is unaffected. Teams operating applications with social login that handle sensitive user data should treat this as a priority upgrade rather than a routine patch cycle item.

An attacker authenticates with Google (or another affected provider) to obtain a valid authorization code tied to the attacker's own Google identity, then crafts a redirect to the victim application's OAuth callback URL containing that code but no state parameter. After luring the victim (via phishing email or malicious link) to visit this URL, the victim's browser completes the callback request, the broken state check passes because no state is present on either side, and the application redeems the attacker's authorization code - silently logging the victim into the attacker's account or linking the attacker's Google identity to the victim's existing application account. No public proof-of-concept has been identified, but the technique is a well-documented OAuth CSRF pattern.