The HTTP/2 experimental feature in Apache Traffic Server 5.3.x before 5.3.1 allows remote attackers to cause a denial of service (out-of-bounds access and daemon crash) or possibly execute arbitrary code via vectors related to the (1) frame_handlers array or (2) set_dynamic_table_size function.

Apache Traffic Server 5.1.x before 5.1.1 allows remote attackers to bypass access restrictions by leveraging failure to properly tunnel remap requests using CONNECT.

Apache Traffic Server: Security issues with the xdebug plugin

Improper Input Validation vulnerability for the xdebug plugin in Apache Software Foundation Apache Traffic Server can lead to cross site scripting and cache poisoning attacks.This issue affects Apache Traffic Server: 9.0.0 to 9.1.3. Users should upgrade to 9.1.4 or later versions.

Apache Traffic Server: Improperly reading the client requests

Improper Check for Unusual or Exceptional Conditions vulnerability in handling the requests to Apache Traffic Server. This issue affects Apache Traffic Server 8.0.0 to 9.1.2.

Apache Traffic Server: Improperly handled requests can cause crashes in specific plugins

Improper Check for Unusual or Exceptional Conditions vulnerability handling requests in Apache Traffic Server allows an attacker to crash the server under certain conditions. This issue affects Apache Traffic Server: from 8.0.0 through 9.1.3.

Unspecified vulnerability in Apache Traffic Server 3.x through 3.2.5, 4.x before 4.2.1.1, and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

Apache Traffic Server before 5.1.2 allows remote attackers to cause a denial of service via unspecified vectors, related to internal buffer sizing.

Apache Traffic Server 2.0.x and 3.0.x before 3.0.4 and 3.1.x before 3.1.3 does not properly allocate heap memory, which allows remote attackers to cause a denial of service (daemon crash) via a long HTTP Host header.

Apache Traffic Server before 2.0.1, and 2.1.x before 2.1.2-unstable, does not properly choose DNS source ports and transaction IDs, and does not properly use DNS query fields to validate responses, which makes it easier for man-in-the-middle attackers to poison the internal DNS cache via a crafted response.

Apache Traffic Server: Differential fuzzing for HTTP request parsing discrepancies

Improper Input Validation vulnerability in Apache Software Foundation Apache Traffic Server.This issue affects Apache Traffic Server: through 9.2.1.

Apache Traffic Server: s3_auth plugin problem with hash calculation

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Software Foundation Apache Traffic Server.This issue affects Apache Traffic Server: from 8.0.0 through 9.2.0. 8.x users should upgrade to 8.1.7 or later versions 9.x users should upgrade to 9.2.1 or later versions

Apache Traffic Server: Configuration option to block the PUSH method in ATS didn't work

Improper Input Validation vulnerability in Apache Software Foundation Apache Traffic Server.  The configuration option proxy.config.http.push_method_enabled didn't function.  However, by default the PUSH method is blocked in the ip_allow configuration file.This issue affects Apache Traffic Server: from 8.0.0 through 9.2.0. 8.x users should upgrade to 8.1.7 or later versions 9.x users should upgrade to 9.2.1 or later versions

Apache Traffic Server: Invalid Range header causes a crash

Improper input validation vulnerability on the range header in Apache Software Foundation Apache Traffic Server.This issue affects Apache Traffic Server: through 9.2.1.

Apache Traffic Server: The TRACE method can be use to disclose network information

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Software Foundation Apache Traffic Server.This issue affects Apache Traffic Server: 8.0.0 to 9.2.0.

Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service

Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both.

Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service

Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service

Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service. The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU.

Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service

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

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.

Some HTTP/2 implementations are vulnerable to a header leak, potentially leading to a denial of service

Some HTTP/2 implementations are vulnerable to a header leak, potentially leading to a denial of service. The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory.