CVE-2026-62995 Overview
CVE-2026-62995 affects joserfc, a Python library implementing JSON Object Signing and Encryption (JOSE) standards. Versions 1.7.1 and prior accept JSON Web Tokens (JWTs) with trailing padding characters (==) that do not conform to JOSE specifications. This behavior introduces token malleability, allowing attackers to produce multiple valid encodings of the same logical token. Applications relying on token hashes or exact token strings for revocation or replay protection can be bypassed. The maintainers fixed the issue in version 1.7.2. The weakness is classified under [CWE-345: Insufficient Verification of Data Authenticity].
Critical Impact
Attackers can bypass deny-list based token revocation or anti-replay controls by submitting JWTs with trailing base64 padding that hash differently than the original token.
Affected Products
- joserfc Python library, versions 1.7.1 and prior
- Applications using joserfc for JWT validation with token or token-hash deny lists
- Systems enforcing anti-replay protections based on exact token string matching
Discovery Timeline
- 2026-07-29 - CVE-2026-62995 published to the National Vulnerability Database (NVD)
- 2026-07-30 - Last updated in NVD database
Technical Details for CVE-2026-62995
Vulnerability Analysis
The vulnerability stems from lenient base64url decoding in joserfc when parsing JWTs. The JOSE specification requires that base64url-encoded segments contain no trailing = padding characters. The affected versions accept tokens that include such padding and still validate them as authentic. This behavior produces distinct byte-level token representations that decode to identical logical claims and signatures.
Token malleability breaks the assumption that a signed JWT has a single canonical serialization. Deny lists that store the raw token string or its hash cannot recognize a padded variant as equivalent to the original. Elliptic Curve Digital Signature Algorithm (ECDSA) JWS tokens are always malleable due to ECDSA signature malleability, but Hash-based Message Authentication Code (HMAC) and RSA schemes were previously expected to yield non-malleable tokens.
Root Cause
The root cause is improper input validation during JWT parsing. The library does not reject base64url segments containing trailing = characters, in violation of RFC 7515. This allows semantically identical tokens to have different serialized forms, undermining any downstream integrity check that operates on the token bytes rather than the parsed claims.
Attack Vector
An attacker who obtains a revoked or previously used JWT can append == padding to one or more of its base64url segments. The modified token still verifies successfully under joserfc versions 1.7.1 and earlier. If the consuming application uses a deny list of exact token strings or SHA-256 hashes to enforce revocation or single-use semantics, the padded variant evades the check. Exploitation requires the attacker to already possess a valid token, limiting the attack to authenticated or replay scenarios.
See the GitHub Security Advisory for maintainer-provided test cases demonstrating the malleability.
Detection Methods for CVE-2026-62995
Indicators of Compromise
- JWTs observed in application logs containing trailing = characters within header, payload, or signature segments
- Repeated authentication or API calls using tokens with matching claims but differing raw token strings
- Deny-list bypass patterns where a previously revoked token identifier appears with altered encoding
Detection Strategies
- Inspect the raw JWT string at ingress and flag any occurrence of = outside the standard base64url alphabet used by JOSE
- Compare parsed token claims against deny lists using the decoded jti (JWT ID) claim rather than the raw serialized token
- Correlate authentication events by claim fingerprint to identify multiple serializations of the same signed token
Monitoring Recommendations
- Log the SHA-256 hash of both raw and normalized JWT forms to detect divergence indicative of padding manipulation
- Alert on tokens presented after their jti has been added to a revocation store
- Track version inventory of joserfc across Python services to prioritize patching
How to Mitigate CVE-2026-62995
Immediate Actions Required
- Upgrade joserfc to version 1.7.2 or later across all Python services that parse or validate JWTs
- Audit deny-list implementations to confirm they operate on the jti claim rather than raw token bytes or hashes
- Review authentication and session revocation logic for reliance on JWT string equality
Patch Information
The maintainers released a fix in joserfc version 1.7.2 that rejects JWTs containing non-conforming trailing padding. Refer to the GitHub Security Advisory GHSA-5jhw-7jv7-qcqq for release notes and the corresponding commit.
Workarounds
- Normalize incoming JWTs by stripping trailing = characters from each segment before hashing or deny-list comparison
- Migrate revocation logic to key tokens by the jti claim, which is bound to the signature payload
- Reject any JWT containing = characters at the API gateway or reverse proxy layer prior to reaching application code
# Configuration example
pip install --upgrade 'joserfc>=1.7.2'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
