On BIG-IP 14.1.0-14.1.2, 14.0.0-14.0.1, and 13.1.0-13.1.1, undisclosed HTTP requests may consume excessive amounts of systems resources which may lead to a denial of service.
The BIG-IP 15.0.0-15.0.1, 14.0.0-14.1.2.2, 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.1-11.6.5.1, BIG-IQ 7.0.0, 6.0.0-6.1.0, and 5.2.0-5.4.0, iWorkflow 2.3.0, and Enterprise Manager 3.1.1 configuration utility is vulnerable to Anti DNS Pinning (DNS Rebinding) attack.
Improper invalidation for page table updates by a virtual guest operating system for multiple Intel(R) Processors may allow an authenticated user to potentially enable denial of service of the host system via local access.
On BIG-IP 13.1.0-13.1.3.1, 12.1.0-12.1.5, and 11.5.2-11.6.5.1, a reflected cross-site scripting (XSS) vulnerability exists in an undisclosed page of the BIG-IP Traffic Management User Interface (TMUI), also known as the BIG-IP Configuration utility.
On versions 14.0.0-14.1.2, 13.0.0-13.1.3, 12.1.0-12.1.5, and 11.5.1-11.6.5, the BIG-IP system fails to perform Martian Address Filtering (As defined in RFC 1812 section 5.3.7) on the control plane (management interface). This may allow attackers on an adjacent system to force BIG-IP into processing packets with spoofed source addresses.
Similar to the issue identified in CVE-2018-12120, on versions 14.1.0-14.1.0.5, 14.0.0-14.0.0.4, 13.0.0-13.1.2, and 12.1.0-12.1.4 BIG-IP will bind a debug nodejs process to all interfaces when invoked. This may expose the process to unauthorized users if the plugin is left in debug mode and the port is accessible.
Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both.
Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.