erlang-jose EUVD-2026-110310

The attacker must possess one valid ECDSA-signed JWS compact token (ES256, ES256K, ES384, or ES512) legitimately issued by the target - no private key, no payload forging, and no special configuration are needed. The affected feature is ECDSA JWS verification via jose_jwk_kty_ec:verify/4 (public API JOSE.JWS.verify) in jose 1.0.0 through 1.11.12. Exploitation only has security value when the application relies on signature-byte or whole-token uniqueness for a security decision - token-revocation-by-hash, replay/idempotency caches, or deduplication keyed on the raw signature; applications that enforce uniqueness via a claim such as jti, or that do not dedup on signatures, are not meaningfully affected. Limiting factors: only ECDSA algorithms are affected (not RSA/EdDSA/HMAC), the flaw cannot forge new payloads or impersonate a signer, and it requires an already-valid token as input.

Signals converge on a genuinely low-to-moderate, low-impact issue rather than an urgent one. The supplied CVSS 4.0 base score is 5.1 (Medium) with only Vulnerable-System Integrity Low (VI:L) and no confidentiality or availability impact (VC:N/VA:N), matching CWE-347 (improper signature verification) and the advisory's own statement that this is signature malleability - it does NOT allow forging payloads or impersonating a signer because the underlying (r,s) values are unchanged. EPSS is 0.09% (1st percentile), i.e. very low predicted exploitation probability, and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation. A working proof-of-concept is embedded in the GHSA advisory (with execution logs showing five re-padded signatures accepted and six distinct tokens verifying against one key), so exploitability of the malleability itself is demonstrated even though real-world attack value is narrow. The vuln.today decision label is 'this_month' (moderate urgency, not act_now/emergency), consistent with low EPSS and no KEV. One signal is questionable: the supplied 4.0 vector uses AV:L (local), but the attack is realistically delivered by submitting a re-encoded token to a network-facing verification endpoint, which argues for AV:N - verify against the actual deployment. Bottom line: a real but low-priority correctness/malleability bug that only matters where an application keys a security control (revocation-by-hash, replay/idempotency, dedup) on signature or token uniqueness; environments that rely on claims like jti are effectively unaffected.

An attacker who has been issued one valid ES256 JWS token re-encodes its signature by prepending leading zero bytes to each of the R and S halves, producing several distinct byte strings that all decode to the same (r,s) and still verify. They replay the re-encoded token past a revocation-by-hash list or idempotency/replay cache that assumed each signature is unique, defeating that protection. A public PoC embedded in the GHSA advisory demonstrates this against a single P-256 key.