Fastify JWT CVE-2026-18500: a global secret bypasses key boundaries

CVE-2026-18500 for @fastify/jwt was published on 15 August 2026. The vulnerability does not break JWT cryptography or reveal a secret key. Its failure is subtler: releases before 10.2.2 can ignore a key explicitly supplied for a request and replace it with the plugin’s global secret. Where an application separates trust domains with different keys, a token from a less privileged domain may be accepted on a route intended to require another key.

The Fastify project advisory scores the issue 8.1 under CVSS 3.1. Exploitation normally requires a token signed by the global secret, so an ordinary user account may be sufficient. It requires no administrator interaction, knowledge of the administrative key or signature forgery. Version 10.2.2 changes option precedence so that an explicitly supplied key is honoured.

What the application intended to enforce

A JWT is a signed message. A server should not trust role, scope or tenant claims until it verifies the signature with the correct key and validates the surrounding conditions. Many systems use one global secret for ordinary sessions and a separate key for administration, a partner integration, reset tokens or service-to-service communication.

A route can call request.jwtVerify with a key option to select the key required in that context. From the designer’s perspective, this is an authorization boundary: a token valid for the user domain must not open the admin domain. Vulnerable code merged options in an order that let the resolved global secret overwrite the local value. The application declared one policy while the library executed another.

This is a confused-deputy failure in cryptographic configuration. The signature remains mathematically valid, but it is checked in the wrong domain. Logs may show a successful verification with no exception. The event does not resemble a conventional security-control failure because verification works with the key it actually received.

How the bypass happens

Suppose an application issues ordinary users tokens signed with key A. An administrative route explicitly supplies key B during verification. In an affected release, global configuration containing A wins during merging. The administrative route therefore checks the token with A even though its local code specifies B.

An attacker does not need the none algorithm, RSA/HMAC confusion or secret guessing. They use a legitimate token for their own account. If further authorization depends only on claims in that accepted token, a suitable set of claims can provide access to protected data or operations after the wrong domain accepts it.

Not every application using @fastify/jwt is exploitable. If every route uses the same secret, option precedence does not change the result. Exposure appears when the per-request key is expected to separate trust. Finding the package in an SBOM is therefore not enough; reviewers must inspect how the API is used.

The advisory also covers reply.jwtSign when a locally supplied signing key is replaced by the global secret. That can issue a token in a different domain than the caller expects. Verification and signing paths should be reviewed together.

Who is exposed

All @fastify/jwt releases before 10.2.2 are affected. Priority goes to Node.js and Fastify applications that configure a global secret, then pass separate keys to request.jwtVerify or reply.jwtSign. Typical patterns include user/admin separation, multiple issuers, tenant-specific keys, key migrations and purpose-specific tokens.

Search source code, not only dependency manifests. Identify plugin registration, global secrets and every local call containing key. Then document the expected issuer, audience, algorithm and key for each route. If the architecture cannot answer that question, the vulnerability has exposed additional identity-model debt.

Pay special attention to microservices that copy a shared authentication module. One faulty abstraction can propagate to many APIs. A lockfile may also contain multiple package releases, so scanner output must be tied to the artefact actually deployed.

What defenders should do now

Upgrade @fastify/jwt to 10.2.2 or a later compatible release. Regenerate the lockfile, run tests and verify the version inside the final container image. Editing package.json without rebuilding and redeploying does not remove exposure.

After upgrading, add a negative test for every key boundary. A user-domain token must be rejected by a route requiring the administrative key even when its claims resemble an administrative token. A token from tenant A must likewise fail in tenant B. Test both the HTTP response and the absence of a side effect.

If an immediate upgrade is impossible, the advisory recommends direct verification through fastify.jwt.verify(token, { key }), which honours the supplied key. Treat this as a temporary workaround. Do not rely on per-request key in the affected methods as an authorization boundary. Test the workaround and remove it after upgrading to avoid permanent dual verification paths.

Consider revoking or shortening the lifetime of tokens from domains that may have crossed a boundary. Key rotation is not automatically required because this CVE does not disclose key material, but it can be appropriate when logs show abuse or the scope of accepted tokens cannot be reconstructed.

Detection and historical review

The most useful evidence correlates issuer, audience, kid, route and authorization decision. Look for user-domain tokens accepted on administrative, integration or service endpoints. Logs should not preserve the raw token, but they can retain a safe token identifier, issuer, audience, selected algorithm and a non-secret key identifier.

Review high-impact operations: role changes, data exports, integration configuration, API-key creation and tenant modifications. A successful JWT verification is not evidence of correct authorization, so signature-error alerts can remain empty during exploitation.

In testing, add instrumentation showing whether the effective key came from global configuration or the route. Never log cryptographic material; a stable, non-secret identifier is sufficient. This signal also catches future option-precedence regressions.

Lessons for library and API design

Security options need an unambiguous hierarchy. If a route supplies a more specific key, a library should honour it or reject the conflict explicitly. Silent replacement is the worst outcome because code appears secure during review.

Library tests should cover a global-versus-local matrix, not merely successful signatures. Use two different keys and assert that a domain A token fails in domain B. Applications should additionally validate issuer, audience, token type and allowed algorithm. A key alone does not define the complete trust context.

A stronger architecture can separate verifiers by domain instead of dynamically switching options on one shared object. A dedicated instance, explicit adminVerifier or independent middleware makes the boundary visible without requiring a reader to reconstruct spread-operator order.

Facts and Breachroad conclusions

CVE-2026-18500 affects versions below 10.2.2, carries an 8.1 score and allows a global secret to override a call-specific key. The advisory also identifies direct fastify.jwt.verify with a local key as the workaround and 10.2.2 as the fixed release. It does not establish widespread exploitation in the wild.

Breachroad’s conclusion is that JWT configuration is authorization code, not a convenience setting. A merge-order change can move a trust boundary without producing any cryptographic error. Negative tests between domains matter just as much as a successful-login test.

If you need to validate token, tenant and role boundaries in a running API, see our web application and API penetration testing. Development and platform teams can complement it with cybersecurity training for organisations that turns cases like this into repeatable design practices.