@fastify/oauth2 EUVD-2026-104327

Exploitation requires a specific deployment: the application must register its OAuth2 login route with two or more path segments, which causes the state and code-verifier cookies to be set without a Path attribute while the callback clears them at the root path, leaving the original cookies alive after the callback. The attacker must also obtain a valid state value and the victim must actively interact by completing the attacker-initiated authorization flow (UI:R). Limiting factors: single-segment login routes are not affected, the documented workaround of setting an explicit matching cookie Path neutralizes the issue, and only @fastify/oauth2 versions 7.2.0 through 8.3.1 are vulnerable (fixed in 8.3.2).

All signals point to a genuinely low-priority issue rather than an urgent one. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N, base 4.2 / Medium) tells a coherent story: network-reachable but requiring high attack complexity, victim user interaction, and yielding only low confidentiality/integrity impact with no availability effect - consistent with the CWE-352 (CSRF) classification and the login-CSRF mechanism in the description. No EPSS score, SSVC decision, KEV listing, or POC indicator was supplied, so exploitation probability cannot be quantified from the data; there is no public exploit identified at time of analysis and no evidence of active exploitation. The AC:H is well justified because the attacker must both obtain a valid state value and the victim's deployment must use a login route with two or more path segments for the cookie-path mismatch to occur - a real but non-trivial precondition. PR:N is accurate (the attacker is an unauthenticated third party driving their own authorization flow). This is a 'real but minor' bug: a legitimate single-use-state bypass worth patching on a normal maintenance cycle, not a high-urgency flaw.

An attacker initiates an OAuth2 login flow and captures a state value, then lures a victim (via a crafted link) into completing that same authorization flow in their browser; because the state/code-verifier cookies set at the multi-segment login route are never cleared by the root-path callback, the stale state remains valid and the victim is silently signed into the attacker's account (login CSRF). No public exploit code is identified at time of analysis, and success depends on the victim interacting with the attacker-supplied flow.