potatosalad Jose up to 1.11.12 ECDSA Signature Verification jose_jwk_kty_ec.erl jose_jwk_kty_ec:verify authentication replay

Summaryinfo

A vulnerability classified as critical has been found in potatosalad Jose up to 1.11.12. This affects the function jose_jwk_kty_ec:verify of the file src/jwk/jose_jwk_kty_ec.erl of the component ECDSA Signature Verification. Performing a manipulation results in authentication replay. This vulnerability is identified as CVE-2026-65632. The attack can be initiated remotely. There is not any exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in potatosalad Jose up to 1.11.12. This affects the function jose_jwk_kty_ec:verify of the file src/jwk/jose_jwk_kty_ec.erl of the component ECDSA Signature Verification. The manipulation with an unknown input leads to a authentication replay vulnerability. CWE is classifying the issue as CWE-294. A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-65632 since 07/22/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1040 for this issue.

Upgrading to version 1.11.13 eliminates this vulnerability.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Vendor

• potatosalad

Name

• Jose

Version

• 1.11.0
• 1.11.1
• 1.11.2
• 1.11.3
• 1.11.4
• 1.11.5
• 1.11.6
• 1.11.7
• 1.11.8
• 1.11.9
• 1.11.10
• 1.11.11
• 1.11.12

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion