CVE-2026-18500 in @fastify/jwt creates an inverted trust model that is more dangerous than its low EPSS score suggests. When you call request.jwtVerify({ key: adminSecret }), the library silently discards your explicit key and validates against the global secret instead. The code compiles, passes review, and returns a valid token—but the security boundary you believed you enforced never existed.
This matters because per-call key verification is the documented solution for multi-tenant isolation and admin/user separation. Applications that followed official guidance are the ones affected. Applications using a single global key—the less secure pattern—were unaffected. This inverts the normal relationship between good security hygiene and risk.
The vulnerability rewards exactly the behavior documentation recommended. Your code likely looks correct: explicit key passed, verification succeeds, audit passes. But the semantic layer inverted what you meant. The absence of failures validated the pattern—until someone looked at the merge logic, no exception fired, no test failed.
Audit, don't just patch. Identify every route protected by per-call jwtVerify({ key: ... }). For each, verify which key actually validated the token—this may require adding instrumentation to log the key consulted during verification. If your threat model assumed hard isolation between admin and user tokens, that assumption needs re-examination. The audit task is non-trivial: confirming correct enforcement may require replaying production traffic against instrumented code.
The deeper question is whether this was a regression or a latent flaw since per-call key support was added. That timeline determines your actual exposure window. Either way, treat this as a threat-model failure, not a simple patch cycle. The fix is a version bump; the remediation is confirming your boundaries were real.