Jose
Monthly
Password-protected private-key exports produced by the Erlang/Elixir `jose` library between 1.10.0 and 1.11.12 are encrypted with a hardcoded, drastically under-strength key-derivation step, so anyone who obtains such an exported blob can crack the export password offline at roughly 300 times less cost than modern guidance intends and recover the full private key. Only the password-based export path is affected (JOSE.JWK.to_der/2, jose_jwk:to_der/2, the PEM equivalents and their _file variants); the attack requires possession of the exported DER/PEM file and succeeds only where the export password is weak or moderate, since a long randomly generated password still resists 2048 PBKDF2 iterations. EPSS is very low (0.06%) and there is no KEV listing, but a public proof-of-concept script accompanies the upstream advisory; a public PoC reference exists and demonstrates parameter extraction plus dictionary recovery, though it is not verified here as working exploit code. The vendor fixed the parameters in 1.11.13, and the CVSS vector indicates no privileges are required (PR:N), with the practical gating factors being blob exposure and password strength rather than any network-reachable interface.
Signature verification bypass in the OCaml jose library (ulrikstrid/ocaml-jose) before 0.11.0 lets attackers forge valid RSA-signed JWS/JWT tokens. The RSA verify path in Jws.ml only confirmed that PKCS #1 decoding succeeded and then returned success, never performing the RSA public-key operation that actually authenticates the signature. Any attacker can craft a token with an arbitrary payload and a syntactically well-formed but cryptographically meaningless signature and have it accepted as valid; no public exploit identified at time of analysis, but the flaw is trivially exploitable once understood.
JWT token forgery in appsup-dart/jose library (versions prior to 0.3.5+1) enables remote attackers to bypass authentication by embedding attacker-controlled public keys in JOSE headers. The library incorrectly accepts header-supplied 'jwk' parameters as trusted verification keys without validating they exist in the application's trusted keystore, allowing unauthenticated attackers to sign arbitrary tokens with their own key pairs. EPSS data not available; no public exploit identified at time of analysis, though exploitation requires only standard JWT manipulation tools.
Recovery of a long-term X25519 private key is possible in erlang-jose 1.10.0 through 1.11.12 whenever the pure-Erlang Curve25519 fallback is the code path actually in use, because scalar multiplication there runs in secret-dependent time and lets an attacker who can submit ECDH-ES JWE ciphertexts and measure decryption timing reconstruct the private scalar bit by bit. The assessed impact is confidentiality-only (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N) and depends on a service that reuses a fixed X25519 key being reachable by an attacker able to collect large numbers of low-noise timing samples, so this is a conditional cryptographic weakness rather than an opportunistic mass-exploitation issue. A public PoC reference exists in the vendor advisory - a demonstration script that forces crypto_fallback and shows a stable timing delta between two victims differing only in their private scalar - but it is not verified as working key-recovery exploit code; there is no CISA KEV listing and EPSS is 0.14% (3rd percentile).
ECDSA JWS signature malleability in erlang-jose (potatosalad:jose) 1.0.0 through 1.11.12 lets anyone holding a single legitimately issued ES256/ES256K/ES384/ES512 token produce multiple distinct signature byte strings that all verify against the same key, because verify/4 never checks the RFC 7518 §3.4 fixed signature length. It cannot forge new payloads or impersonate a signer - the underlying (r, s) pair is unchanged - but it defeats controls that assume a token or signature is unique, such as token-revocation-by-hash, replay/idempotency caches and deduplication keyed on raw signature bytes; applications that enforce uniqueness via a claim such as jti are not meaningfully affected. Exploitation requires an already-valid token as input (assessed vector AV:N/PR:L), a demonstration PoC reference ships with the vendor advisory but it is not verified as working exploit code against third-party deployments, EPSS is 0.09% (1st percentile), there is no CISA KEV listing, and the vendor released a fix in 1.11.13.
CPU-exhaustion denial of service in the erlang-jose library (versions 1.7.7 through 1.11.12) lets remote attackers who can get an application to parse an untrusted JWK pin BEAM schedulers by submitting a private RSA key that carries only d, e and n and omits every CRT parameter. Parsing such a key drives an internal prime-recovery loop that performs a modular exponentiation over the attacker-supplied modulus on every iteration; when the modulus is itself prime the search can never succeed and burns work until a one-second watchdog kills the worker, so roughly 211 bytes of input costs about one CPU-second. The advisory ships a public proof-of-concept script that was verified end-to-end to reach that watchdog, no credentials or valid RSA key are required, and sustained denial of service needs a flood of concurrent requests because the watchdog bounds each individual parse; EPSS is low (0.24%, 14th percentile) and there is no CISA KEV entry, consistent with a moderate, availability-only issue rather than a top-tier emergency.
The Erlang/Elixir JOSE library (potatosalad/erlang-jose) can be driven into an unbounded tail-recursive loop through JOSE.JWK.shared_secret/2 when an application derives an ECDH shared secret from an attacker-supplied peer JWK whose key type differs from the application's own key. A single mismatched JWK (for example an RSA public key submitted to a server holding an EC P-256 key) never returns and never crashes, pinning one BEAM scheduler at 100% CPU; repeated submissions exhaust schedulers and degrade or take down the service. Only deployments on jose 1.5.0 through 1.11.12 that actually call shared_secret/2 on untrusted input are reachable - applications using jose purely for JWS/JWE/JWT signing and verification do not hit the vulnerable clause. Severity is a genuine but modest-priority availability issue: EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, priority is 'this_month', but a public proof-of-concept script published with the vendor advisory demonstrates the scheduler hang. Fixed in 1.11.13.
Memory-exhaustion denial of service in the erlang-jose JOSE/JWE library for Erlang and Elixir (versions 1.0.0 through 1.11.12) lets a remote, unauthenticated attacker inflate a few-kilobyte JWE token into hundreds of megabytes or gigabytes on the decrypting node and crash the BEAM. When a token carries the optional zip: "DEF" header, jose_jwe_zip:uncompress/2 feeds the entire attacker-controlled plaintext to zlib:inflate/2 with no output-size or inflation-ratio bound, and this happens automatically inside jose_jwe:block_decrypt/2 (JOSE.JWE.block_decrypt/2) before the recipient can inspect or reject the payload; with RSA-OAEP or ECDH-ES key management the attacker only needs the recipient's public key and no secret material. Exposure is limited to applications that actually decrypt JWEs received from untrusted senders and do not reject compressed headers first; EPSS is 0.25% (16th percentile), no confirmed active exploitation (CISA KEV) is recorded, and a proof-of-concept script with supporting logs is published in the upstream advisory GHSA-wfpv-qxp8-x5gm.
Bleichenbacher padding-oracle weakness in erlang-jose's pure-Erlang RSAES-PKCS1-v1_5 decryption (jose 1.3.0 through before 1.11.13) can let an unauthenticated attacker who knows only the public RSA key recover plaintext from intercepted RSA1_5 JWE content-encryption keys via roughly 10^4 to 10^6 adaptive chosen-ciphertext queries. Exploitation requires an application that unwraps RSA1_5 JWE keys with jose and exposes the decryption outcome, either as distinguishable return values (recovered key versus error) or as observable timing; the direct return-value oracle applies when the pure-Erlang jose_jwa_pkcs1 backend is active. No CISA KEV entry or confirmed active exploitation was identified, EPSS is 0.09%, and a public PoC reference exists but it is not verified as working exploit code.
Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attacker defeat AES-GCM integrity wherever decryption routes through the pure-Erlang jose_jwa_aes fallback - FIPS builds, or stripped or older OTP releases where :crypto does not expose a native AES-GCM NIF. Because verification compares only as many bits of the real 128-bit tag as the attacker-supplied tag contains, truncating the tag to a single byte drops forgery resistance to 2^-8, so a forged JWE with attacker-chosen ciphertext is accepted within 256 attempts without knowledge of the key; an over-length tag instead triggers a badmatch that crashes the decrypting process. A public PoC reference exists (advisory-attached Elixir script); it is not verified as working exploit code, there is no confirmed active exploitation (not in CISA KEV), and EPSS is 0.11% (2nd percentile), consistent with the conditional fallback prerequisite.
jose is JavaScript module for JSON Object Signing and Encryption, providing support for JSON Web Tokens (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), JSON Web Key. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
JOSE is "JSON Web Almost Everything" - JWA, JWS, JWE, JWT, JWK, JWKS with no dependencies using runtime's native crypto in Node.js, Browser, Cloudflare Workers, Electron, and Deno. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
jose is an npm library providing a number of cryptographic operations. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required.
Password-protected private-key exports produced by the Erlang/Elixir `jose` library between 1.10.0 and 1.11.12 are encrypted with a hardcoded, drastically under-strength key-derivation step, so anyone who obtains such an exported blob can crack the export password offline at roughly 300 times less cost than modern guidance intends and recover the full private key. Only the password-based export path is affected (JOSE.JWK.to_der/2, jose_jwk:to_der/2, the PEM equivalents and their _file variants); the attack requires possession of the exported DER/PEM file and succeeds only where the export password is weak or moderate, since a long randomly generated password still resists 2048 PBKDF2 iterations. EPSS is very low (0.06%) and there is no KEV listing, but a public proof-of-concept script accompanies the upstream advisory; a public PoC reference exists and demonstrates parameter extraction plus dictionary recovery, though it is not verified here as working exploit code. The vendor fixed the parameters in 1.11.13, and the CVSS vector indicates no privileges are required (PR:N), with the practical gating factors being blob exposure and password strength rather than any network-reachable interface.
Signature verification bypass in the OCaml jose library (ulrikstrid/ocaml-jose) before 0.11.0 lets attackers forge valid RSA-signed JWS/JWT tokens. The RSA verify path in Jws.ml only confirmed that PKCS #1 decoding succeeded and then returned success, never performing the RSA public-key operation that actually authenticates the signature. Any attacker can craft a token with an arbitrary payload and a syntactically well-formed but cryptographically meaningless signature and have it accepted as valid; no public exploit identified at time of analysis, but the flaw is trivially exploitable once understood.
JWT token forgery in appsup-dart/jose library (versions prior to 0.3.5+1) enables remote attackers to bypass authentication by embedding attacker-controlled public keys in JOSE headers. The library incorrectly accepts header-supplied 'jwk' parameters as trusted verification keys without validating they exist in the application's trusted keystore, allowing unauthenticated attackers to sign arbitrary tokens with their own key pairs. EPSS data not available; no public exploit identified at time of analysis, though exploitation requires only standard JWT manipulation tools.
Recovery of a long-term X25519 private key is possible in erlang-jose 1.10.0 through 1.11.12 whenever the pure-Erlang Curve25519 fallback is the code path actually in use, because scalar multiplication there runs in secret-dependent time and lets an attacker who can submit ECDH-ES JWE ciphertexts and measure decryption timing reconstruct the private scalar bit by bit. The assessed impact is confidentiality-only (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:N) and depends on a service that reuses a fixed X25519 key being reachable by an attacker able to collect large numbers of low-noise timing samples, so this is a conditional cryptographic weakness rather than an opportunistic mass-exploitation issue. A public PoC reference exists in the vendor advisory - a demonstration script that forces crypto_fallback and shows a stable timing delta between two victims differing only in their private scalar - but it is not verified as working key-recovery exploit code; there is no CISA KEV listing and EPSS is 0.14% (3rd percentile).
ECDSA JWS signature malleability in erlang-jose (potatosalad:jose) 1.0.0 through 1.11.12 lets anyone holding a single legitimately issued ES256/ES256K/ES384/ES512 token produce multiple distinct signature byte strings that all verify against the same key, because verify/4 never checks the RFC 7518 §3.4 fixed signature length. It cannot forge new payloads or impersonate a signer - the underlying (r, s) pair is unchanged - but it defeats controls that assume a token or signature is unique, such as token-revocation-by-hash, replay/idempotency caches and deduplication keyed on raw signature bytes; applications that enforce uniqueness via a claim such as jti are not meaningfully affected. Exploitation requires an already-valid token as input (assessed vector AV:N/PR:L), a demonstration PoC reference ships with the vendor advisory but it is not verified as working exploit code against third-party deployments, EPSS is 0.09% (1st percentile), there is no CISA KEV listing, and the vendor released a fix in 1.11.13.
CPU-exhaustion denial of service in the erlang-jose library (versions 1.7.7 through 1.11.12) lets remote attackers who can get an application to parse an untrusted JWK pin BEAM schedulers by submitting a private RSA key that carries only d, e and n and omits every CRT parameter. Parsing such a key drives an internal prime-recovery loop that performs a modular exponentiation over the attacker-supplied modulus on every iteration; when the modulus is itself prime the search can never succeed and burns work until a one-second watchdog kills the worker, so roughly 211 bytes of input costs about one CPU-second. The advisory ships a public proof-of-concept script that was verified end-to-end to reach that watchdog, no credentials or valid RSA key are required, and sustained denial of service needs a flood of concurrent requests because the watchdog bounds each individual parse; EPSS is low (0.24%, 14th percentile) and there is no CISA KEV entry, consistent with a moderate, availability-only issue rather than a top-tier emergency.
The Erlang/Elixir JOSE library (potatosalad/erlang-jose) can be driven into an unbounded tail-recursive loop through JOSE.JWK.shared_secret/2 when an application derives an ECDH shared secret from an attacker-supplied peer JWK whose key type differs from the application's own key. A single mismatched JWK (for example an RSA public key submitted to a server holding an EC P-256 key) never returns and never crashes, pinning one BEAM scheduler at 100% CPU; repeated submissions exhaust schedulers and degrade or take down the service. Only deployments on jose 1.5.0 through 1.11.12 that actually call shared_secret/2 on untrusted input are reachable - applications using jose purely for JWS/JWE/JWT signing and verification do not hit the vulnerable clause. Severity is a genuine but modest-priority availability issue: EPSS is 0.14% (3rd percentile), there is no CISA KEV listing, priority is 'this_month', but a public proof-of-concept script published with the vendor advisory demonstrates the scheduler hang. Fixed in 1.11.13.
Memory-exhaustion denial of service in the erlang-jose JOSE/JWE library for Erlang and Elixir (versions 1.0.0 through 1.11.12) lets a remote, unauthenticated attacker inflate a few-kilobyte JWE token into hundreds of megabytes or gigabytes on the decrypting node and crash the BEAM. When a token carries the optional zip: "DEF" header, jose_jwe_zip:uncompress/2 feeds the entire attacker-controlled plaintext to zlib:inflate/2 with no output-size or inflation-ratio bound, and this happens automatically inside jose_jwe:block_decrypt/2 (JOSE.JWE.block_decrypt/2) before the recipient can inspect or reject the payload; with RSA-OAEP or ECDH-ES key management the attacker only needs the recipient's public key and no secret material. Exposure is limited to applications that actually decrypt JWEs received from untrusted senders and do not reject compressed headers first; EPSS is 0.25% (16th percentile), no confirmed active exploitation (CISA KEV) is recorded, and a proof-of-concept script with supporting logs is published in the upstream advisory GHSA-wfpv-qxp8-x5gm.
Bleichenbacher padding-oracle weakness in erlang-jose's pure-Erlang RSAES-PKCS1-v1_5 decryption (jose 1.3.0 through before 1.11.13) can let an unauthenticated attacker who knows only the public RSA key recover plaintext from intercepted RSA1_5 JWE content-encryption keys via roughly 10^4 to 10^6 adaptive chosen-ciphertext queries. Exploitation requires an application that unwraps RSA1_5 JWE keys with jose and exposes the decryption outcome, either as distinguishable return values (recovered key versus error) or as observable timing; the direct return-value oracle applies when the pure-Erlang jose_jwa_pkcs1 backend is active. No CISA KEV entry or confirmed active exploitation was identified, EPSS is 0.09%, and a public PoC reference exists but it is not verified as working exploit code.
Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attacker defeat AES-GCM integrity wherever decryption routes through the pure-Erlang jose_jwa_aes fallback - FIPS builds, or stripped or older OTP releases where :crypto does not expose a native AES-GCM NIF. Because verification compares only as many bits of the real 128-bit tag as the attacker-supplied tag contains, truncating the tag to a single byte drops forgery resistance to 2^-8, so a forged JWE with attacker-chosen ciphertext is accepted within 256 attempts without knowledge of the key; an over-length tag instead triggers a badmatch that crashes the decrypting process. A public PoC reference exists (advisory-attached Elixir script); it is not verified as working exploit code, there is no confirmed active exploitation (not in CISA KEV), and EPSS is 0.11% (2nd percentile), consistent with the conditional fallback prerequisite.
jose is JavaScript module for JSON Object Signing and Encryption, providing support for JSON Web Tokens (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), JSON Web Key. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
JOSE is "JSON Web Almost Everything" - JWA, JWS, JWE, JWT, JWK, JWKS with no dependencies using runtime's native crypto in Node.js, Browser, Cloudflare Workers, Electron, and Deno. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
jose is an npm library providing a number of cryptographic operations. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required.