What's the vulnerability?
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.
Business impact & how R4IM helps
This advisory is on our active-exploitation watchlist. Attackers are using it for initial access, privilege escalation or lateral movement in real-world intrusions. R4IM's offensive security and SOC teams already have detections, exploit replicas and remediation playbooks for this issue.
Targeted vulnerability assessment to confirm which of your assets are actually exploitable — not just theoretically affected.
Our pentesters chain this CVE into realistic attack paths so you see business impact, not just a scan finding.
If the affected product is internet-facing, our AppSec team will harden it against this and related OWASP-class issues.
Continuous monitoring with custom detections for this CVE deployed across your endpoints, identity and cloud.
Recommended remediation
- Inventory all assets running the affected vendor and product, including shadow IT and third-party hosted instances.
- Apply the vendor patch or mitigation referenced in the advisories below. Where no patch exists, isolate the asset or restrict network exposure.
- Hunt for indicators of prior compromise — exploitation of this class of bug often predates public disclosure.
- Deploy detections for the exploit primitives (network signature, EDR rule, WAF rule) and re-test after remediation.
Need help executing these steps? Our team typically completes validation and remediation within a single patch cycle. Request remediation support →
Vendor & research references
- https://cna.erlef.org/cves/CVE-2026-65632.html · 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
- https://github.com/potatosalad/erlang-jose/commit/72ce1866622b9329347dc52a94173ac0317bc9cf · 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
- https://github.com/potatosalad/erlang-jose/commit/a7746ecd4950f85a393136e449a91dac62b5c429 · 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
- https://github.com/potatosalad/erlang-jose/security/advisories/GHSA-44hw-rpw9-mwg4 · 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
- https://osv.dev/vulnerability/EEF-CVE-2026-65632 · 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
- https://github.com/potatosalad/erlang-jose/security/advisories/GHSA-44hw-rpw9-mwg4 · 134c704f-9b21-4f2e-91b3-4a467353bcc0
