HashiCorp Vault and Vault Enterprise inbound client requests triggering a policy check can lead to an unbounded consumption of memory. A large number of these requests may lead to denial-of-service. Fixed in Vault 1.15.2, 1.14.6, and 1.13.10. (CVSS:5.9) (Last Update:2023-11-09 21:15:25)

Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. While DH_check() performs all the necessary checks (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. (CVSS:0.0) (Last Update:2023-11-06 16:31:59)

In certain conditions for Calico Typha (v3.26.2, v3.25.1 and below), and Calico Enterprise Typha (v3.17.1, v3.16.3, v3.15.3 and below), a client TLS handshake can block the Calico Typha server indefinitely, resulting in denial of service. The TLS Handshake() call is performed inside the main server handle for loop without any timeout allowing an unclean TLS handshake to block the main loop indefinitely while other connections will be idle waiting for that handshake to finish. (CVSS:7.5) (Last Update:2023-11-06 16:31:59)

A vulnerability in the remote access VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper handling of HTTPS requests. An attacker could exploit this vulnerability by sending crafted HTTPS requests to an affected system. A successful exploit could allow the attacker to cause resource exhaustion, resulting in a DoS condition. (CVSS:8.6) (Last Update:2023-11-01 18:17:44)

A vulnerability in ICMPv6 inspection when configured with the Snort 2 detection engine for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the CPU of an affected device to spike to 100 percent, which could stop all traffic processing and result in a denial of service (DoS) condition. FTD management traffic is not affected by this vulnerability. This vulnerability is due to improper error checking when parsing fields within the ICMPv6 header. An attacker could exploit this vulnerability by sending a crafted ICMPv6 packet through an affected device. A successful exploit could allow the attacker to cause the device to exhaust CPU resources and stop processing traffic, resulting in a DoS condition. Note: To recover from the DoS condition, the Snort 2 Detection Engine or the Cisco FTD device may need to be restarted. (CVSS:8.6) (Last Update:2023-11-01 18:17:44)

A vulnerability in the TLS 1.3 implementation of the Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the Snort 3 detection engine to unexpectedly restart. This vulnerability is due to a logic error in how memory allocations are handled during a TLS 1.3 session. Under specific, time-based constraints, an attacker could exploit this vulnerability by sending a crafted TLS 1.3 message sequence through an affected device. A successful exploit could allow the attacker to cause the Snort 3 detection engine to reload, resulting in a denial of service (DoS) condition. While the Snort detection engine reloads, packets going through the FTD device that are sent to the Snort detection engine will be dropped. The Snort detection engine will restart automatically. No manual intervention is required. (CVSS:4.0) (Last Update:2023-11-01 18:17:44)

A vulnerability in the AnyConnect SSL VPN feature of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to an implementation error within the SSL/TLS session handling process that can prevent the release of a session handler under specific conditions. An attacker could exploit this vulnerability by sending crafted SSL/TLS traffic to an affected device, increasing the probability of session handler leaks. A successful exploit could allow the attacker to eventually deplete the available session handler pool, preventing new sessions from being established and causing a DoS condition. (CVSS:6.8) (Last Update:2023-11-01 18:17:44)

A vulnerability in the SSL/TLS certificate handling of Snort 3 Detection Engine integration with Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the Snort 3 detection engine to restart. This vulnerability is due to a logic error that occurs when an SSL/TLS certificate that is under load is accessed when it is initiating an SSL connection. Under specific, time-based constraints, an attacker could exploit this vulnerability by sending a high rate of SSL/TLS connection requests to be inspected by the Snort 3 detection engine on an affected device. A successful exploit could allow the attacker to cause the Snort 3 detection engine to reload, resulting in either a bypass or a denial of service (DoS) condition, depending on device configuration. The Snort detection engine will restart automatically. No manual intervention is required. (CVSS:4.0) (Last Update:2023-11-01 18:17:44)