erlang-jose EUVD-2026-110308

Exploitation requires three concrete preconditions. (1) The victim application must have exported a private key using the password-based export path - JOSE.JWK.to_der/2 (jose_jwk:to_der/2), the PEM equivalents, or their _file variants - which produces a PKCS#8 EncryptedPrivateKeyInfo protected by the hardcoded PBES2 parameters; keys exported without a password or by other means are unaffected. (2) The attacker must obtain that exported blob from a location they can read (backup, config repository, object storage, or logs); no host access, runtime access, or authenticated session on the victim system is needed. (3) Success is gated on the export password being weak or moderate enough to fall to an offline attack at only 2048 PBKDF2 iterations - a long, randomly generated password still resists even this reduced work factor. The key LIMITING factors are therefore blob exposure and password strength, not any network-reachable interface; the flaw cannot be triggered against a running service and does not affect keys already on disk unless their encrypted export leaks.

Signals point consistently to a genuine-but-bounded issue rather than a drop-everything emergency. The CVSS 4.0 base score is 7.4 (High), but the vector itself tells the real story: AV:L with AT:P means this is not a remote attack against a running jose service - exploitation happens offline, after an attacker has already obtained an exported, password-encrypted private-key blob, and only when an attack requirement (the blob being exposed somewhere readable) is met. EPSS is effectively zero (0.06%, 0th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; this is a latent cryptographic-strength weakness, not a mass-exploitable network flaw. Working proof-of-concept code is published in the GHSA advisory, which raises practical risk for anyone whose exported blobs have leaked, but POC availability is a distinct signal from active exploitation and should not be conflated with it. The vendor/CNA (EEF/ErlEF) priority label is 'this_week,' which is consistent with the picture: patch promptly, but the dominant real-world risk is conditional on (a) using the password-export API and (b) a blob leaking plus (c) a weak/moderate export password. Note a signal tension worth flagging: a 7.4 High score sits alongside near-zero EPSS and no KEV listing - this reflects high theoretical impact (full private-key compromise) gated behind preconditions the attacker does not control, i.e. targeted/opportunistic rather than widespread exploitation.

An application uses JOSE.JWK.to_der(password, jwk) to export a password-encrypted private key, and the resulting PKCS#8 EncryptedPrivateKeyInfo blob ends up in a readable location such as a backup, a configuration repository, object storage, or logs. An attacker who obtains only that blob parses the embedded PBES2/PBKDF2 parameters (2048 iterations, 64-bit salt) and runs an offline dictionary or brute-force attack against the export password roughly 300x cheaper than modern guidance would allow, recovering the full private key on success. A working proof-of-concept demonstrating parameter recovery and the offline crack via the library's public decrypt path is published in the GHSA advisory.