GHSA-fm3f-ch8h-qw8q: CSRF
Summary
The built-in social login providers accept an OAuth callback even when the state value is absent on both sides, so the anti-CSRF check passes for a callback that never came from a genuine login attempt. This defeats the state-based CSRF protection under default usage.
Details
The state check treated two absent values as a match, so a callback that omits state — and for which no state was ever stored — was allowed to redeem the authorization code. Hono's csrf() middleware does not help: it only inspects form-style requests, while the OAuth callback is a top-level GET navigation it treats as safe.
This affects the google, github, facebook, discord, twitch, linkedin, and msentra providers. The x (Twitter) provider is not exploitable due to its PKCE binding.
Impact
An attacker can make a victim's browser complete an OAuth callback that binds the attacker's identity instead of the victim's, leading to login CSRF (the victim silently acts inside the attacker's account) or forced account linking (the attacker's identity is linked to the victim's account, enabling later sign-in as the victim). Affects applications using an affected provider on @hono/oauth-providers 0.8.5 or earlier.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@hono/oauth-providersto a version that resolves this vulnerability.Fixed in 0.8.6
Event History
Frequently Asked Questions
Which OAuth providers are exposed to this issue?
Applications using the built-in google, github, facebook, discord, twitch, linkedin, or msentra providers are affected. The x (Twitter) provider is not exploitable because it has PKCE binding.
Is an application affected under its default configuration?
Yes. The state-based CSRF protection can be bypassed under default usage when both the callback state and stored state are absent. Hono's csrf() middleware does not mitigate this because OAuth callbacks are top-level GET navigations.
What must an attacker do to exploit the issue?
An attacker must cause the victim's browser to complete an OAuth callback containing an authorization code but omitting state. This can result in login CSRF or force the attacker's OAuth identity to be linked to the victim's account.
How could exploitation affect users after the callback succeeds?
A victim may be silently logged into an account controlled by the attacker and perform actions there. In a forced account-linking scenario, the attacker’s identity can be linked to the victim’s account and later used to sign in as the victim.