Live › vulnerability › CVE-2026-110008
Go to dashboardIn @fastify/oauth2 versions 7.2.0 through 8.3.1, the OAuth state and code-verifier cookies are not cleared at the callback when the login route has two or more path segments, so a state value stays reusable. An attacker can use this to sign a victim into the attacker's account (login CSRF).
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that use @fastify/oauth2 between versions 7.2.0 and 8.3.1 for login flows, where the login route has two or more path segments, so the state cookie is set with a different path than it is cleared. Teams not using this plugin, or on 8.3.2 or later, can skip it.
No product ranges from the sources yet.
npm ls @fastify/oauth28.3.2 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
@fastify/oauth2 is a Fastify wrapper for OAuth2 login flows. In versions 7.2.0 through 8.3.1, the state and code-verifier cookies are set without a Path attribute at a login route with two or more path segments, while the clearing step at the OAuth callback writes them with a root path, so the original cookies survive the callback and the documented single-use guarantee for the state value does not hold. A state value an attacker learns stays valid for the rest of the browser session, letting the attacker drive their own authorization flow in the victim's browser and sign the victim in to the attacker's account (login CSRF). The issue is fixed in @fastify/oauth2 8.3.2, and users should upgrade to 8.3.2 or later. As a workaround, set an explicit cookie path so the set and the clear name the same cookie.
This page as .md · .json · in your agent: get_signal("CVE-2026-110008")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.