Search
Search Results (20 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-3099 | 3 Gnome, Libsoup, Redhat | 4 Libsoup, Libsoup, Enterprise Linux and 1 more | 2026-11-05 | 5.8 Medium |
| A flaw was found in Libsoup. The server-side digest authentication implementation in the SoupAuthDomainDigest class does not properly track issued nonces or enforce the required incrementing nonce-count (nc) attribute. This vulnerability allows a remote attacker to capture a single valid authentication header and replay it repeatedly. Consequently, the attacker can bypass authentication and gain unauthorized access to protected resources, impersonating the legitimate user. | ||||
| CVE-2019-1543 | 2 Openssl, Redhat | 2 Openssl, Enterprise Linux | 2026-11-02 | N/A |
| ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1c (Affected 1.1.1-1.1.1b). Fixed in OpenSSL 1.1.0k (Affected 1.1.0-1.1.0j). | ||||
| CVE-2026-98805 | 1 Linux | 1 Linux Kernel | 2026-10-30 | 7.4 High |
| In the Linux kernel, the following vulnerability has been resolved: tipc: prevent GCM nonce reuse on peer key changes TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed. The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero. | ||||
| CVE-2026-5446 | 1 Wolfssl | 1 Wolfssl | 2026-04-29 | 7.1 High |
| In wolfSSL, ARIA-GCM cipher suites used in TLS 1.2 and DTLS 1.2 reuse an identical 12-byte GCM nonce for every application-data record. Because wc_AriaEncrypt is stateless and passes the caller-supplied IV verbatim to the MagicCrypto SDK with no internal counter, and because the explicit IV is zero-initialized at session setup and never incremented in non-FIPS builds. This vulnerability affects wolfSSL builds configured with --enable-aria and the proprietary MagicCrypto SDK (a non-default, opt-in configuration required for Korean regulatory deployments). AES-GCM is not affected because wc_AesGcmEncrypt_ex maintains an internal invocation counter independently of the call-site guard. | ||||
| CVE-2017-13077 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Pairwise Transient Key (PTK) Temporal Key (TK) during the four-way handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames. | ||||
| CVE-2017-13078 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Group Temporal Key (GTK) during the four-way handshake, allowing an attacker within radio range to replay frames from access points to clients. | ||||
| CVE-2017-13079 | 7 Canonical, Debian, Freebsd and 4 more | 12 Ubuntu Linux, Debian Linux, Freebsd and 9 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) that supports IEEE 802.11w allows reinstallation of the Integrity Group Temporal Key (IGTK) during the four-way handshake, allowing an attacker within radio range to spoof frames from access points to clients. | ||||
| CVE-2017-13080 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Group Temporal Key (GTK) during the group key handshake, allowing an attacker within radio range to replay frames from access points to clients. | ||||
| CVE-2017-13082 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) that supports IEEE 802.11r allows reinstallation of the Pairwise Transient Key (PTK) Temporal Key (TK) during the fast BSS transmission (FT) handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames. | ||||
| CVE-2017-13084 | 7 Canonical, Debian, Freebsd and 4 more | 12 Ubuntu Linux, Debian Linux, Freebsd and 9 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Station-To-Station-Link (STSL) Transient Key (STK) during the PeerKey handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames. | ||||
| CVE-2017-13086 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Tunneled Direct-Link Setup (TDLS) Peer Key (TPK) during the TDLS handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames. | ||||
| CVE-2017-1000246 | 1 Pysaml2 Project | 1 Pysaml2 | 2025-04-20 | N/A |
| Python package pysaml2 version 4.4.0 and earlier reuses the initialization vector across encryptions in the IDP server, resulting in weak encryption of data. | ||||
| CVE-2017-13088 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) that support 802.11v allows reinstallation of the Integrity Group Temporal Key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame, allowing an attacker within radio range to replay frames from access points to clients. | ||||
| CVE-2017-7902 | 1 Rockwellautomation | 21 1763-l16awa Series A, 1763-l16awa Series B, 1763-l16bbb Series A and 18 more | 2025-04-20 | N/A |
| A "Reusing a Nonce, Key Pair in Encryption" issue was discovered in Rockwell Automation Allen-Bradley MicroLogix 1100 programmable-logic controllers 1763-L16AWA, Series A and B, Version 16.00 and prior versions; 1763-L16BBB, Series A and B, Version 16.00 and prior versions; 1763-L16BWA, Series A and B, Version 16.00 and prior versions; and 1763-L16DWD, Series A and B, Version 16.00 and prior versions and Allen-Bradley MicroLogix 1400 programmable logic controllers 1766-L32AWA, Series A and B, Version 16.00 and prior versions; 1766-L32BWA, Series A and B, Version 16.00 and prior versions; 1766-L32BWAA, Series A and B, Version 16.00 and prior versions; 1766-L32BXB, Series A and B, Version 16.00 and prior versions; 1766-L32BXBA, Series A and B, Version 16.00 and prior versions; and 1766-L32AWAA, Series A and B, Version 16.00 and prior versions. The affected product reuses nonces, which may allow an attacker to capture and replay a valid request until the nonce is changed. | ||||
| CVE-2017-13087 | 7 Canonical, Debian, Freebsd and 4 more | 13 Ubuntu Linux, Debian Linux, Freebsd and 10 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) that support 802.11v allows reinstallation of the Group Temporal Key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame, allowing an attacker within radio range to replay frames from access points to clients. | ||||
| CVE-2017-13081 | 7 Canonical, Debian, Freebsd and 4 more | 12 Ubuntu Linux, Debian Linux, Freebsd and 9 more | 2025-04-20 | N/A |
| Wi-Fi Protected Access (WPA and WPA2) that supports IEEE 802.11w allows reinstallation of the Integrity Group Temporal Key (IGTK) during the group key handshake, allowing an attacker within radio range to spoof frames from access points to clients. | ||||
| CVE-2014-7203 | 1 Zeromq | 1 Zeromq | 2025-04-12 | N/A |
| libzmq (aka ZeroMQ/C++) 4.0.x before 4.0.5 does not ensure that nonces are unique, which allows man-in-the-middle attackers to conduct replay attacks via unspecified vectors. | ||||
| CVE-2021-32791 | 4 Apache, Fedoraproject, Openidc and 1 more | 4 Http Server, Fedora, Mod Auth Openidc and 1 more | 2024-11-21 | 5.9 Medium |
| mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. In mod_auth_openidc before version 2.4.9, the AES GCM encryption in mod_auth_openidc uses a static IV and AAD. It is important to fix because this creates a static nonce and since aes-gcm is a stream cipher, this can lead to known cryptographic issues, since the same key is being reused. From 2.4.9 onwards this has been patched to use dynamic values through usage of cjose AES encryption routines. | ||||
| CVE-2020-1759 | 3 Fedoraproject, Linuxfoundation, Redhat | 5 Fedora, Ceph, Ceph Storage and 2 more | 2024-11-21 | 6.4 Medium |
| A vulnerability was found in Red Hat Ceph Storage 4 and Red Hat Openshift Container Storage 4.2 where, A nonce reuse vulnerability was discovered in the secure mode of the messenger v2 protocol, which can allow an attacker to forge auth tags and potentially manipulate the data by leveraging the reuse of a nonce in a session. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. | ||||
| CVE-2019-7593 | 1 Johnsoncontrols | 1 Metasys System | 2024-11-21 | N/A |
| Metasys® ADS/ADX servers and NAE/NIE/NCE engines prior to 9.0 make use of a shared RSA key pair for certain encryption operations involving the Site Management Portal (SMP). | ||||
Page 1 of 1.