Read the docs
TI-2026-80579 Aliases CVE-2026-65632GHSA-6g34-xwc5-pgxj

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

Priority MEDIUM 56CWE-347Published · Updated

Key facts

Attack vector
Local
Privileges required
None
User interaction
None
Attack complexity
Low
Attack requirements
None
Impact type
Security bypass
Confidentiality · integrity · availability
None · Low · None
Fix status
Fixed

Attack profile from CVSS 4.0 · CNA. Fix status from CNA. Impact type from CWE-347.

Summary

The jose library, an Erlang library for JSON Web Signatures, from 1.0.0 before 1.11.13 accepts ECDSA signatures of non-canonical length (ES256, ES256K, ES384 and ES512). The verifier splits the raw signature by its actual length and decodes each half in a way that ignores leading zero bytes, which is a case of improper verification of a cryptographic signature (CWE-347). An attacker who holds one valid token can pad the signature with leading zeros to produce many distinct byte strings that verify against the same key, without forging new payloads. This defeats controls that assume each token or signature is unique, such as revocation by hash or replay caches.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

Description from the CNA

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.

Why it matters now

Exploitation Proof of concept CISA SSVC · not in CISA KEV
EPSS 0.00092 0th percentileScored 2026-11-07
Fix Fixed jose (potatosalad): 1.11.13

SSVC decision points

CISA ADP · SSVC 2.0.3

Exploitation
Poc
Automatable
No
Technical impact
Partial

The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.

Affected products

VendorProductAffected versionsFixed inStatusSource
potatosaladjose1.0.0 to before 1.11.131.11.13Patch availableCNA
  • jose Vendorpotatosalad Affected 1.0.0 to before 1.11.13 Fixed in 1.11.13 Patch available CNA

CPE names CNA · 1

CPEVersionsRoleVendor
cpe:2.3:a:potatosalad:jose:*:*:*:*:*:*:*:*——potatosalad
  • cpe:2.3:a:potatosalad:jose:*:*:*:*:*:*:*:* Versions — — ·potatosalad

Remediation

Upgrade potatosalad jose to version 1.11.13 or later, which fixes the issue.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

  • Fix · CNA jose (potatosalad) Fixed in 1.11.13

Fixed in the same release

Records fixed by the same vendor advisory or release, as the CNA lists them.

  • Release ·

    potatosalad jose 1.11.13

    8 records Highest priority Priority HIGH 1 HIGH, 5 MEDIUM, 2 LOW

    Other records, highest priority first

    • TI-2026-80576 Weak key derivation in jose password-protected key exportPriority HIGH 68
    • TI-2026-80578 erlang-jose JWK parsing CPU exhaustion via attacker-chosen RSA modulusPriority MEDIUM 64
    • TI-2026-80574 Decompression bomb in potatosalad jose exhausts memory via JWE tokensPriority MEDIUM 64

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 1 product
  • Red Hat

Timeline

  1. 2026-10-26 Threatist record created from CVE-2026-65632
  2. 2026-10-27 Alias added: GHSA-6g34-xwc5-pgxj
  3. 2026-11-02 CISA SSVC decision points changed
  4. 2026-11-02 Priority changed: LOW → MEDIUM
  5. 2026-11-06 Affected versions changed · Red Hat
  6. 2026-11-06 CVSS score added · Red Hat

References

  • TI-2026-80576 Weak key derivation in jose password-protected key export CVSS 4.0HIGH 7.4
  • TI-2026-80578 erlang-jose JWK parsing CPU exhaustion via attacker-chosen RSA modulus CVSS 4.0MEDIUM 6.9
  • TI-2026-80574 Decompression bomb in potatosalad jose exhausts memory via JWE tokens CVSS 4.0MEDIUM 6.9
  • TI-2026-80577 Timing side channel in pure-Erlang X25519 leaks private keys in jose CVSS 4.0MEDIUM 5.9
  • TI-2026-80575 Unbounded recursion in jose JWK shared secret derivation causes DoS CVSS 4.0MEDIUM 5.9
  • TI-2026-80573 Bleichenbacher padding oracle in RSAES-PKCS1-v1_5 decryption in jose CVSS 4.0MEDIUM 5.9
See all 7 →

Sources