@fastify/jwt CVE-2026-18500

Exploitation requires two specific conditions to be met simultaneously: the target application must run @fastify/jwt at any version below 10.2.2, AND it must implement per-request key differentiation by passing a key argument to request.jwtVerify({ key }) on at least one route. Applications using a single global JWT secret for all routes are completely unaffected regardless of version. The attacker must be an authenticated low-privilege user (consistent with CVSS PR:L) possessing a valid JWT token signed by the application's global secret - they do not need to know or forge the route-specific key. Exploitation is limited to multi-domain trust architectures; a standard monolithic JWT deployment without key separation is immune.

The CVSS 8.1 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) accurately characterizes risk for the subset of deployments affected, though the realistic attack surface is meaningfully narrower than the score alone implies - only applications explicitly calling request.jwtVerify({ key }) with a per-request override are vulnerable, making single-key deployments entirely immune. No EPSS data was provided, and the vulnerability is absent from the CISA KEV catalog, so active exploitation is not confirmed; no public exploit code is known. The privilege separation failure is architecturally severe when triggered: an attacker needs only a valid global-secret token to impersonate an admin or cross any key-based trust boundary the application defines. Even a mid-sized municipal IT team in bytom running Fastify-based services with separated admin and user JWT keys should treat this as urgent given the trivial exploitation complexity and the availability of the 10.2.2 patch. The CVSS integrity and confidentiality impacts of High are well-supported - privilege escalation enables both data exfiltration and unauthorized writes. The absence of availability impact is consistent with the nature of the bypass.

An authenticated user authenticates via a standard low-privilege endpoint and receives a JWT signed with the application's global secret. They then send that token in a request to an admin-restricted route that calls request.jwtVerify({ key: adminKey }). Because @fastify/jwt's merge logic overwrites adminKey with the global secret before verification, the token passes the cryptographic check and the attacker gains full access to privileged functionality. No public exploit code has been identified, but the attack requires only a standard JWT library and knowledge of the target route.