joserfc CVE-2026-62995

Exploitation requires two conditions to be simultaneously true: (1) the application must implement deny-list-based token revocation or anti-replay protection that compares raw JWT strings or their cryptographic hashes, and (2) the attacker must already possess a valid or formerly valid JWT issued to them. Applications performing only stateless JWT signature verification without a deny list are not vulnerable to this bypass. The vulnerability does not apply to ECDSA-signed JWTs in the sense that those are already malleable for independent reasons unrelated to padding; the padding malleability is most impactful for HMAC (HS256/HS384/HS512) or RSA (RS256, PS256, etc.) signed tokens where developers reasonably assume canonical, non-malleable token representation. The non-default architectural choice of a deny list is the primary limiting factor that scopes the real-world risk.

The CVSS 4.0 score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) accurately reflects a narrow, conditional impact. The AT:P metric is the critical signal: specific attack requirements must be present - the application must implement deny-list-based token revocation or anti-replay protection using raw JWT strings or their hashes. Without this architectural pattern, the malleability is inconsequential. PR:L confirms that an attacker must already hold a valid (or formerly valid) JWT, limiting the threat to insider or post-authentication scenarios. No EPSS score was supplied for this CVE, and it is not listed in CISA KEV; no public exploit code has been identified at time of analysis. The overall real-world risk is low for most deployments and low-to-moderate only for the specific subset of applications that combine joserfc with a token-hash deny list for revocation or replay prevention. The vendor advisory itself acknowledges this conditionality explicitly.

An attacker whose JWT has been added to an application's token revocation deny list (for example, after an admin-initiated logout or session invalidation) resubmits the same token with trailing == padding appended to one or more Base64url-encoded segments. The server passes library-level signature validation, computes a hash of the padded token string, finds no matching entry in the deny list, and grants continued access despite revocation. No public exploit code exists, but the technique requires only basic knowledge of Base64 encoding and is trivially reproducible by any holder of a valid JWT.