CVE-2026-5423

This vulnerability is a signature verification bypass, but the root cause is more fundamental: the library maintains two parallel JWT handling paths—one that verifies signed tokens and another that trusts pre-decoded objects wholesale—and it silently falls into the unverified path when you supply connectionParams.jwt as a decoded object rather than a signed string. The library assumes that pre-decoded JWT objects arrive only from trusted internal code paths that already verified the signature. That assumption breaks in the GraphQL-over-WebSocket subscription protocol, where connectionParams come directly from clients. The practical impact: an attacker who can establish a WebSocket connection to your subscription endpoint can bypass authentication entirely by passing a jwt object in connectionParams. The library accepts this as an authenticated identity without ever checking a signature. The CVSS 8.2 reflects the worst case—attacker forge arbitrary roles—but actual exploitability depends on whether your subscriptions authorize based on those claims. If your subscription resolvers only check query-level authorization and don't reference connectionParams.jwt claims, the bypass may not grant meaningful access. That's a critical determination only you can make for your deployment. If you're on v6, there's no patch coming. The library has marked that version end-of-life, which means this vulnerability is permanently unpatched in any v6 deployment. You need to migrate to v7 or accept that you'll be running with a known auth bypass. There is no compensating control that fully mitigates this at the application layer—the vulnerability is in the authentication handshake itself. Network segmentation or WAF rules can reduce exposure, but they assume you know your subscription endpoints are reachable. Many GraphQL deployments expose subscriptions on the same port as queries, making segmentation non-trivial. The fix in v7 rejects non-string JWT representations in connectionParams. If your architecture uses upstream authentication middleware that decodes JWTs before passing them to this library, that pattern is now explicitly unsupported. You'll need to pass signed tokens to connectionParams or re-architect how decoded claims flow into your resolvers. Test thoroughly before upgrading—silently broken auth in production is worse than a known vulnerability you have compensating controls for.

Reviewed through automated stages and approved by a human before publication.