Total
62 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-81235 | 2026-09-16 | N/A | 8.0 HIGH | ||
| Dell Wyse Management Suite, versions prior to 2605.0.3.683, contain a Missing Cryptographic Step vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information tampering. | |||||
| CVE-2026-4601 | 1 Kjur | 1 Jsrsasign | 2026-09-10 | N/A | 8.7 HIGH |
| Versions of the package jsrsasign before 11.1.1 are vulnerable to Missing Cryptographic Step via the KJUR.crypto.DSA.signWithMessageHash process in the DSA signing implementation. An attacker can recover the private key by forcing r or s to be zero, so the library emits an invalid signature without retrying, and then solves for x from the resulting signature. | |||||
| CVE-2026-28498 | 1 Authlib | 1 Authlib | 2026-09-10 | N/A | 7.5 HIGH |
| Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a library-level vulnerability was identified in the Authlib Python library concerning the validation of OpenID Connect (OIDC) ID Tokens. Specifically, the internal hash verification logic (_verify_hash) responsible for validating the at_hash (Access Token Hash) and c_hash (Authorization Code Hash) claims exhibits a fail-open behavior when encountering an unsupported or unknown cryptographic algorithm. This flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized alg header parameter. The library intercepts the unsupported state and silently returns True (validation passed), inherently violating fundamental cryptographic design principles and direct OIDC specifications. This issue has been patched in version 1.6.9. | |||||
| CVE-2026-25250 | 2026-09-09 | N/A | 6.0 MEDIUM | ||
| EAZ EazyFix 12.9 allows a Security Feature Bypass related to a "Missing Cryptographic Step" associated with "Secure Boot disable." | |||||
| CVE-2026-40542 | 1 Apache | 1 Httpclient | 2026-09-09 | N/A | 7.3 HIGH |
| Missing critical step in authentication in Apache HttpClient 5.6 allows an attacker to cause the client to accept SCRAM-SHA-256 authentication without proper mutual authentication verification. Users are recommended to upgrade to version 5.6.1, which fixes this issue. | |||||
| CVE-2026-76784 | 2026-08-28 | N/A | N/A | ||
| Multiple TP-Link Kasa smart home devices contain insufficient cryptographic protections in the local device communication protocol. An adjacent network attacker may intercept, replay or forge locally exchanged control messages, potentially resulting in unauthorized device control. Successful exploitation could allow an attacker to manipulate the operational state of an affected device, resulting in unauthorized state changes, disruption of normal device functionality or a denial-of-service condition. | |||||
| CVE-2026-42246 | 1 Ruby-lang | 1 Net\ | 2026-08-24 | N/A | 7.4 HIGH |
| Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4, a man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS. This issue has been patched in versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4. | |||||
| CVE-2022-20742 | 1 Cisco | 2 Adaptive Security Appliance Software, Secure Firewall Threat Defense | 2026-08-11 | 5.8 MEDIUM | 7.4 HIGH |
| A vulnerability in an IPsec VPN library of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to read or modify data within an IPsec IKEv2 VPN tunnel. This vulnerability is due to an improper implementation of Galois/Counter Mode (GCM) ciphers. An attacker in a man-in-the-middle position could exploit this vulnerability by intercepting a sufficient number of encrypted messages across an affected IPsec IKEv2 VPN tunnel and then using cryptanalytic techniques to break the encryption. A successful exploit could allow the attacker to decrypt, read, modify, and re-encrypt data that is transmitted across an affected IPsec IKEv2 VPN tunnel. | |||||
| CVE-2026-17666 | 1 Google | 1 Chrome | 2026-08-03 | N/A | 9.1 CRITICAL |
| Cryptographic Flaw in Enterprise in Google Chrome prior to 151.0.7922.72 allowed an attacker in a privileged network position to bypass discretionary access control via malicious network traffic. (Chromium security severity: High) | |||||
| CVE-2026-4258 | 1 Bitwiseshiftleft | 1 Stanford Javascript Crypto Library | 2026-07-28 | N/A | 7.5 HIGH |
| Versions of the package sjcl before 1.0.9 are vulnerable to Improper Verification of Cryptographic Signature due to missing point-on-curve validation in sjcl.ecc.basicKey.publicKey(). An attacker can recover a victim's ECDH private key by sending crafted off-curve public keys and observing ECDH outputs. The dhJavaEc() function directly returns the raw x-coordinate of the scalar multiplication result (no hashing), providing a plaintext oracle without requiring any decryption feedback. | |||||
| CVE-2026-45446 | 1 Openssl | 1 Openssl | 2026-07-23 | N/A | 4.8 MEDIUM |
| Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) mishandle the authentication of AAD (Additional Authenticated Data) with an empty ciphertext allowing a forgery of such messages. Impact summary: An attacker can forge empty messages with arbitrary AAD to the victim's application using these ciphers. AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD modes: they accept a key, nonce, optional AAD (bytes that are authenticated but not encrypted), and plaintext, and produces ciphertext plus a 16-byte tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only if the tag is verified succesfully. In OpenSSL's provider implementation of these ciphers, the expected tag is computed only when decryption function is invoked with non-empty data. If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without invocation of the ciphertext update, which can happen when the received ciphertext length is zero, the tag is never recalculated and still holds its all-zeros value. When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty ciphertext, and all-zeros tag passes authentication under any key they do not know, single-shot. When AES-SIV is used, for mounting the attack it's necessary for the application to reuse the decryption context without resetting the key. AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since OpenSSL 3.2. No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must implement their own protocol and use the EVP interface. Also they must skip the ciphertext update when a message with an empty ciphertext arrives. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as these algorithms are not FIPS approved and the affected code is outside the OpenSSL FIPS module boundary. | |||||
| CVE-2026-45445 | 1 Openssl | 1 Openssl | 2026-07-23 | N/A | 7.5 HIGH |
| Issue summary: When an application drives an AES-OCB context through the public EVP_Cipher() one-shot interface, the application-supplied initialisation vector (IV) is silently discarded. Impact summary: Every message encrypted under the same key uses the same effective nonce regardless of the IV supplied by the caller, resulting in (key, nonce) reuse and loss of confidentiality. If the same code path is used to compute the authentication tag, the tag depends only on the (key, IV) pair and not on the plaintext or ciphertext, allowing universal forgery of arbitrary ciphertext from a single captured message. OpenSSL provides two ways to drive a cipher: the documented streaming interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level one-shot, EVP_Cipher(), whose documentation explicitly recommends against use by applications in favour of EVP_CipherUpdate() and EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes the application-supplied IV into the OCB context before processing data; the one-shot handler did not. Every call to EVP_Cipher() on an AES-OCB context therefore ran with the all-zero key-derived offset state left by cipher initialisation, regardless of the caller's IV. If EVP_EncryptFinal_ex() is subsequently used to obtain the authentication tag, the deferred IV setup runs at that point and clears the running checksum that should have been accumulated over the plaintext. The resulting tag is a function of (key, IV) only and verifies against any ciphertext produced under the same (key, IV) pair. The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a TLS cipher suite, and libssl does not call EVP_Cipher() in any case. Applications that drive AES-OCB through the documented streaming AEAD API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only applications that combine the AES-OCB cipher with the EVP_Cipher() one-shot API are vulnerable. The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue, as AES-OCB is outside the OpenSSL FIPS module boundary. | |||||
| CVE-2026-0420 | 1 Netgear | 8 Rax120, Rax120 Firmware, Rax35 and 5 more | 2026-07-23 | N/A | 5.9 MEDIUM |
| An improper implementation of TLS certificate validation vulnerability found in NETGEAR's ReadyCloud client app which could allow an attacker to perform attacker-in-the-middle (MiTM) style attacks impacting the product's confidentiality. This vulnerability affects the listed NETGEAR models. | |||||
| CVE-2026-42770 | 1 Openssl | 1 Openssl | 2026-07-23 | N/A | 3.7 LOW |
| Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the peer key is not properly checked for the subgroup membership. Impact summary: A malicious peer which presents an X9.42 key carrying the victim's p and g parameters, a forged q = r (a small prime factor of the cofactor (p−1)/q_local), and a public value Y of order r can recover the victim's private key after a small number of key exchange attempts. When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's own q parameter, not the local key's q. The peer's domain parameters are then matched against the domain parameters of the private key, but the value of q is not compared. A malicious peer who presents an X9.42 key carrying the victim's p, g, a forged q = r (a small prime factor of the cofactor), and a public value Y of order r passes all checks. The shared secret then takes only r distinct values, leaking priv mod r. Repeating for each small-prime factor of the cofactor and combining via CRT recovers the full private key (Lim–Lee / small-subgroup-confinement attack). The realistic attack surface is narrow: principally CMP deployments with long-lived RA/CA DHX keys and bespoke enterprise or government applications using X9.42 DHX static keys with interactive protocols and therefore this issue was assigned Low severity. The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this issue. | |||||
| CVE-2026-48480 | 2026-07-22 | N/A | N/A | ||
| The netty incubator codec.bhttp is a java language binary http parser. Prior to version 0.0.22.FInal, the codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp does not verify that a cryptographically-signed final chunk was received before the outer HTTP body terminates. An on-path adversary (the OHTTP relay itself, or any MITM on the relay↔gateway or relay↔client transport) can forward a prefix of a legitimate chunked-OHTTP message—cut at a non-final chunk boundary—and close the outer body cleanly, producing no decryption error and no exception in the receiving application. Version 0.0.22.Final fixes the issue. | |||||
| CVE-2026-58638 | 1 Microsoft | 12 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 9 more | 2026-07-22 | N/A | 6.0 MEDIUM |
| Missing cryptographic step in Windows Boot Loader allows an authorized attacker to bypass a security feature locally. | |||||
| CVE-2026-59776 | 2026-07-21 | N/A | 6.8 MEDIUM | ||
| Missing Cryptographic Step (CWE-325) vulnerability exists in certain FeliCa IC chips shipped in or before 2017. If the vulnerability is exploited, information stored in the IC chip may be read or tampered with. | |||||
| CVE-2026-55144 | 1 Microsoft | 5 Windows 11 24h2, Windows 11 25h2, Windows 11 26h1 and 2 more | 2026-07-21 | N/A | 7.1 HIGH |
| Missing cryptographic step in Windows CryptoAPI allows an authorized attacker to perform tampering locally. | |||||
| CVE-2026-49440 | 1 Deno | 1 Deno | 2026-06-26 | N/A | 7.4 HIGH |
| Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) ran no Miller-Rabin rounds at all when the caller left options.checks at its default of 0. In that mode, the only test applied to the candidate was trial division by the primes up to 17,863. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as 17,881 × 17,891 — was reported as true ("probably prime"). The same divergence affected the lower-level op_node_check_prime / op_node_check_prime_bytes paths that the polyfill calls into. This vulnerability is fixed in 2.8.1. | |||||
| CVE-2026-6458 | 2026-06-25 | N/A | N/A | ||
| Missing cryptographic step in Caliptra Core Firmware (aes_256_gcm_update module) results in an incorrect GCM authentication tag. When the streaming AES-256-GCM API is used with empty AAD, the hardware GHASH accumulator state is not saved after the first update call, causing the final tag to exclude the first batch of processed ciphertext. Ciphertext produced by that call may be modified without the tag reflecting the change. This issue affects Core Runtime Firmware: from 2.0.0 through 2.0.1, 2.1.0. | |||||