CVE-2026-18500: @fastify/jwt global secret can override per-route verification keys

What happened

A vulnerability tracked as CVE-2026-18500 affects @fastify/jwt, the JWT plugin for the Fastify Node.js framework, in every release prior to 10.2.2. According to a security write-up on dev.to by HOL, the flaw is an authorization bypass: routes that explicitly hand their own verification key to the plugin can have that key silently replaced by the globally configured secret.

The National Vulnerability Database rates the issue 8.1, in the high severity band, using the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. In practical terms, exploitation happens over the network, attack complexity is low, and successful abuse has a high impact on both confidentiality and integrity, though availability is unaffected. The underlying weakness is filed as CWE-347, improper verification of a cryptographic signature. The dev.to post points readers to GitHub Security Advisory GHSA-j4cx-787j-xjqg as the primary advisory.

How the bypass works

By default, @fastify/jwt validates incoming tokens against a single secret configured when the plugin is registered. Some deployments need more granularity than that, so the API allows a route to call request.jwtVerify({ key }) and demand a key that differs from the global one, for example when user, admin, tenant, and service tokens are signed separately.

The bug lives in how the plugin merges its options. As the write-up describes it, the merge applies the global key after the per-request key, which means the global secret takes precedence and overwrites whatever key the route intended to use.

The result is that the intended separation between authorization domains collapses. A route built to accept only tokens from a distinct key will happily validate a token signed with the global secret, treating it as legitimate even though it belongs to another domain.

How to fix it

The remediation is a version bump to 10.2.2 or newer. The write-up lists the commands for the three major package managers:

• npm: npm install @fastify/[email protected]
• pnpm: pnpm up @fastify/[email protected]
• Yarn: yarn add @fastify/[email protected]

Patching alone is not the whole story for teams that actually rely on distinct keys. The write-up recommends reviewing authentication logs for signs of tokens signed under the global key reaching routes that configured a different verification key. Where such evidence exists, affected signing keys should be rotated and any exposed tokens invalidated.

Applications that only ever configured a single global secret are less exposed to the cross-domain scenario, since there is no second key to override, though upgrading remains the safe default for all users of affected versions.

Why it matters

Signing keys per authorization domain are a common isolation technique: the assumption is that a token minted for one domain simply cannot satisfy verification in another. When the merge order quietly substitutes the global key, that assumption fails without any error, warning, or log entry pointing at the swap. A valid, correctly signed token from a lower-privilege domain can therefore walk through a route that was meant to be gated by a stronger key.

The 8.1 CVSS score reflects how damaging silent verification bypasses can be: no user interaction, no special conditions, and direct compromise of confidentiality and integrity. It is also a reminder that option merging in security-sensitive code paths deserves as much scrutiny as the cryptography itself.

One caveat worth noting: the technical details here come from a single community write-up. Teams should confirm the specifics against the GitHub advisory and their own package lockfiles before scheduling work.

On the positive side, the fix is a routine dependency upgrade with no configuration migration described in the report, which makes this a cheap patch compared to the access it protects.