Skip to content

EEF-CVE-2026-65632 CVE-2026-65632 GHSA-44hw-rpw9-mwg4

ECDSA signature length is not validated in jose, allowing signature malleability

Not rated yet Hex
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

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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

Is this in your code?

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