EEF-CVE-2026-65632 CVE-2026-65632 GHSA-44hw-rpw9-mwg4
ECDSA signature length is not validated in jose, allowing signature malleability
- Severity
- 0.0 / 10
- Unknown · CVSS 4.0
- Exploit chance (EPSS)
- 0.09%
- Chance of exploitation in the next 30 days. Higher than 0.50% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-347 Improper Verification of Cryptographic Signature
- Fix
1.11.13- Upgrade jose to this version or later
Description
Summary
The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 §3.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes.
As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic.
This issue affects jose: from 1.0.0 before 1.11.13.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| jose | >= 1.0.0, < 1.11.13 |
1.11.13 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
jose Hex → 1.11.13
- mix
{:jose, "~> 1.11.13"} # then: mix deps.update jose
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Local
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-347: Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-65630 Timing side-channel in pure-Erlang X25519 scalar multiplication leaks the private key in jose | Not rated yet | Also affects jose |
| EEF-CVE-2026-65631 erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service | Not rated yet | Also affects jose |
| EEF-CVE-2026-65629 Weak PBKDF2 parameters for password-encrypted private-key export in jose | Not rated yet | Also affects jose |
| EEF-CVE-2026-65628 Infinite recursion (CPU denial-of-service) in JOSE.JWK.shared_secret/2 on mismatched key types | Not rated yet | Also affects jose |
| EEF-CVE-2026-65627 Decompression bomb via unbounded zlib:inflate in jose_jwe_zip:uncompress/2 | Not rated yet | Also affects jose |
| EEF-CVE-2026-65626 Bleichenbacher padding oracle in RSAES-PKCS1-v1_5 decryption in jose | Not rated yet | Also affects jose |
| EEF-CVE-2026-65625 Attacker-controlled AES-GCM authentication tag length allows tag forgery in jose | Not rated yet | Also affects jose |
| GHSA-9mg4-v392-8j68 erlang-jose vulnerable to denial of service via large p2c value | Medium | Also affects jose |
Credits: Andrew Bennett, Jonatan Männchen / EEF, Peter Ullrich
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor