| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Observable Timing Discrepancy vulnerability in potatosalad jose allows recovery of a long-term X25519 private key through a timing side channel in the pure-Erlang Curve25519 fallback.
The pure-Erlang X25519 implementation performs scalar multiplication over the secret private key using a recursive Montgomery ladder (jose_jwa_x25519:curve25519/2) whose clauses branch on individual bits of the clamped private scalar, and whose per-step operations (jose_jwa_x25519:montgomery_add/3 and jose_jwa_x25519:montgomery_double/1) and field inversion are built from value-dependent Erlang bignum arithmetic (multiplication, remainder, and modular exponentiation). Although the ladder is operation-count balanced and fixed at 254 steps, the concrete integer values processed at each step, and therefore the running time, depend on the secret scalar. The execution time of the public entry points jose_jwa_x25519:scalarmult/2, jose_jwa_x25519:x25519/2, jose_jwa_x25519:x25519_base/1, and jose_jwa_x25519:sk_to_pk/1 is thus a function of the private key.
This path is reachable from the public API, most notably when a service decrypts attacker-supplied ECDH-ES (JWE) messages with a long-term X25519 key (for example through JOSE.JWK.box_decrypt_ecdh_es/2, which reaches jose_jwa_curve25519:x25519_shared_secret/2 and the ladder). An attacker who can submit ciphertexts and measure decryption timing can, in principle, recover the private key bit by bit, defeating the resistance X25519 was designed to provide. Recovery of the key compromises the confidentiality and authenticity of all data protected by it.
This issue affects jose: from 1.10.0 before 1.11.13. |
| Use of Password Hash With Insufficient Computational Effort in the jose library allows an attacker who obtains a password-encrypted private-key export to recover the private key through an offline password-cracking attack.
When jose exports a password-encrypted private key with jose_jwk:to_der/2 (JOSE.JWK.to_der/2), the jose_jwk_der:to_binary/3 function in src/jwk/jose_jwk_der.erl serializes the key as a PKCS#8 EncryptedPrivateKeyInfo using the PBES2 scheme with hardcoded key-derivation parameters: PBKDF2-HMAC-SHA256 with an iteration count of 2048 and an 8-byte (64-bit) random salt. Neither value can be overridden by the caller.
Both values are far below current guidance (OWASP recommends on the order of 600,000 iterations for PBKDF2-HMAC-SHA256, and NIST recommends salts of at least 128 bits), so the key-stretching work factor is roughly 300 times lower than intended and the short salt reduces the cost of precomputation across keys. The symmetric encryption (AES-256-CBC with a 16-byte random IV) is not affected; the weakness is entirely in the derivation strength. An attacker who obtains one of these exported blobs (for example from a backup, configuration repository, object storage, or logs) can mount a cheap offline dictionary or brute-force attack against the export password, and success yields the full private key.
This issue affects jose: from 1.10.0 before 1.11.13. |
| jose_jwk:shared_secret/2 (exposed in Elixir as JOSE.JWK.shared_secret/2) derives an ECDH shared secret from two JWKs. Its first function clause only matches when both JWKs carry the same key type (kty) module, and its fallback clause re-invokes itself as shared_secret(from(YourJWK), from(MyJWK)). Because from/1 returns an already-parsed jose_jwk record unchanged, passing two JWKs whose key types differ (for example an EC key and an RSA key) makes the fallback clause re-enter with identical arguments, producing an unbounded tail-recursive loop that never returns and never crashes.
An application that derives a shared secret from an externally supplied peer public key without first checking that the peer key's type and curve match its own key can be driven into this loop by an attacker-controlled JWK, pinning an Erlang scheduler at 100% CPU. Repeated requests exhaust the available schedulers, resulting in a denial of service.
This issue affects jose: from 1.5.0 before 1.11.13. |
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in potatosalad jose (erlang-jose) allows a remote attacker to exhaust a node's memory with a small crafted JWE token.
The jose_jwe_zip:uncompress/2 function in src/jwe/jose_jwe_zip.erl decompresses the DEFLATE-compressed plaintext of a JWE that carries the optional zip: DEF header by calling zlib:inflate/2 on the entire attacker-controlled stream, with no bound on the output size or the inflation ratio. Raw DEFLATE reaches ratios around 1000:1 on highly repetitive input, so a few-kilobyte token inflates to hundreds of megabytes or gigabytes in a single call.
Decompression runs automatically during decryption through jose_jwe:block_decrypt/2 (JOSE.JWE.block_decrypt/2 in Elixir), before the recipient can inspect or reject the payload. With the common asymmetric key-management algorithms (RSA-OAEP, ECDH-ES) an attacker needs only the recipient's public key to craft such a token, so no authentication or secret material is required. A single small token can exhaust the node's memory and crash the BEAM, denying service to all users.
This issue affects jose: from 1.0.0 before 1.11.13. |
| CVE-2026-116768 is a missing length validation vulnerability
in Secure Access servers prior to 14.61. Authenticated attackers can cause a
persistent denial of service when connecting for the first time. |
| Infinite loop in Xpdf 4.06 and earlier, due to incorrect validation of progression order field in JPEG 2000 image. |
| **UNSUPPORTED WHEN ASSIGNED** Authorization bypass in Apache Vysper, all versions.
Apache Vysper is an XMPP (Jabber) server library. Its XEP-0077 (In-Band Registration) implementation is missing an authentication check, allowing any authenticated user to compromise other accounts.
As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative. |
| **UNSUPPORTED WHEN ASSIGNED** Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition.
This issue affects all versions of Apache Vysper. Apache Vysper is an XMPP (Jabber) server library.
As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative. |
| SQL injection in the database-query custom resource handlers in the Amazon Web Services (AWS) Cloud Development Kit (CDK) @aws-cdk/aws-redshift-alpha module before 2.274.0-alpha.0 could allow a third party who can influence construct property values to run SQL statements with Amazon Redshift superuser privileges, including granting access to all cluster users. The statements are reachable through crafted user names, comments, or passwords.
To remediate this issue, users should upgrade to version 2.274.0-alpha.0 or later and review existing table grants to PUBLIC. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0490. |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0483. |
| NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.0404. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0389. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0360. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0322. |
| Use After Free in GitHub repository vim/vim prior to 9.0.0286. |
| Dell Command Update, Dell Update and Alienware Update versions prior to 4.6.0 contains a Local Privilege Escalation Vulnerability in the custom catalog configuration. A local malicious user may potentially exploit this vulnerability in order to elevate their privileges. |
| In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.
The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High. |
| Kerberos AppContainer Security Feature Bypass Vulnerability |
| Use After Free in GitHub repository vim/vim prior to 9.0.0260. |
