Search
Search Results (7 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-12797 | 3 Netapp, Openssl, Redhat | 26 Bootstrap Os, Brocade Fabric Operating System, H300s and 23 more | 2026-11-06 | 6.3 Medium |
| Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. | ||||
| CVE-2016-3099 | 1 Redhat | 5 Enterprise Linux, Enterprise Linux Desktop, Enterprise Linux Hpc Node and 2 more | 2025-04-20 | N/A |
| mod_ns in Red Hat Enterprise Linux Desktop 7, Red Hat Enterprise Linux HPC Node 7, Red Hat Enterprise Linux Server 7, and Red Hat Enterprise Linux Workstation 7 allows remote attackers to force the use of ciphers that were not intended to be enabled. | ||||
| CVE-2017-2342 | 1 Juniper | 2 Junos, Srx300 | 2025-04-20 | N/A |
| MACsec feature on Juniper Networks Junos OS 15.1X49 prior to 15.1X49-D100 on SRX300 series does not report errors when a secure link can not be established. It falls back to an unencrypted link. This can happen when MACsec is configured on ports that are not capable of MACsec or when a secure link can not be established. This can mislead customers into believing that a link is secure. On SRX 300 series devices, prior to 15.1X49-D100, MACsec was only supported on control and fabric ports of SRX340 and SRX345 devices. SRX300 and and SRX320 did not have any MACsec capable ports. Configuring MACsec on ports that were not MACsec capable would have resulted in this issue. Affected releases are Juniper Networks Junos OS 15.1X49 prior to 15.1X49-D100 on SRX300 series. | ||||
| CVE-2014-3468 | 5 Debian, F5, Gnu and 2 more | 17 Debian Linux, Arx, Arx Firmware and 14 more | 2025-04-12 | N/A |
| The asn1_get_bit_der function in GNU Libtasn1 before 3.6 does not properly report an error when a negative bit length is identified, which allows context-dependent attackers to cause out-of-bounds access via crafted ASN.1 data. | ||||
| CVE-2015-5400 | 3 Debian, Fedoraproject, Squid-cache | 3 Debian Linux, Fedora, Squid | 2025-04-12 | N/A |
| Squid before 3.5.6 does not properly handle CONNECT method peer responses when configured with cache_peer, which allows remote attackers to bypass intended restrictions and gain access to a backend proxy via a CONNECT request. | ||||
| CVE-2013-2005 | 2 Redhat, X | 2 Enterprise Linux, Libxt | 2025-04-11 | N/A |
| X.org libXt 1.1.3 and earlier does not check the return value of the XGetWindowProperty function, which allows X servers to trigger use of an uninitialized pointer and memory corruption via vectors related to the (1) ReqCleanup, (2) HandleSelectionEvents, (3) ReqTimedOut, (4) HandleNormal, and (5) HandleSelectionReplies functions. | ||||
| CVE-2020-15566 | 2 Debian, Xen | 2 Debian Linux, Xen | 2024-11-21 | 6.5 Medium |
| An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1) will be considered an error. All the other cases will provide a valid port and will result in a crash when trying to access the event channel. When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and later are affected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event-channel limit. | ||||
Page 1 of 1.