A flaw was found in Undertow. This vulnerability allows a remote attacker to construct specially crafted requests where header names are parsed differently by Undertow compared to upstream proxies. This discrepancy in header interpretation can be exploited to launch request smuggling attacks, potentially bypassing security controls and accessing unauthorized resources.

A flaw was found in Undertow. A remote attacker can exploit this vulnerability by sending \r\r\r as a header block terminator. This can be used for request smuggling with certain proxy servers, such as older versions of Apache Traffic Server and Google Cloud Classic Application Load Balancer, potentially leading to unauthorized access or manipulation of web requests.

Undertow allows \r\r\r as a header block terminator. This can be used for request smuggling with proxy servers that forwards this byte sequence, including older versions of Apache Traffic Server and Google Cloud Classic Application Load Balancer.

A vulnerability was identified in Undertow (as used in Wildfly) where the server prematurely parses and stores multipart/form-data content to the disk when receiving an HTTP GET request, provided the underlying application (e.g., JSF) invokes parameter-parsing methods like getParameterMap().

Description: Product Security received a report that Undertow might incorrectly re-use an HTTP request header value from a previous stream for a request associated with a subsequent stream on the same HTTP/2 connection. The issue is linked to the readHpackString method and its interaction with the stringBuilder field. While such behavior typically results in an error followed by the termination of the HTTP/2 connection, it presents a potential vector for information leakage between requests.

The original reporter referenced a similar issue in Apache Tomcat (CVE-2020-17527). In the patch for that vulnerability (https://github.com/apache/tomcat/commit/8d2fe6894d6e258a6d615d7f786acca80e6020cb) a StringBuilder field was improperly reused across multiple requests, leading to this issue. In the io.undertow.protocols.http2.HpackDecoder class of Undertow, within the readHpackString method, there is a code pattern identical to the one mentioned:

for (int i = 0; i < length; ++i) { stringBuilder.append((char) buffer.get()); } String ret = stringBuilder.toString(); stringBuilder.setLength(0); if (ret.isEmpty()) { //return the interned empty string, rather than allocating a new one each time return ""; }

Steps to reproduce: No reproducers or PoC were provided, this issue was identified through static testing.

Affected versions: 2.2.x, 2.3.x, and 3.x

A flaw was found in undertow. The undertow client is not checking the server identity the server certificate presents in HTTPS connections. This is a compulsory step ( that should at least be performed by default) in HTTPS and in http/2.

A flaw was found in Undertow with EJB invocations. This flaw allows an attacker to generate a valid HTTP request and send it to the server on an established connection after removing the LASTCHUNK from the bytes, causing a denial of service.

A flaw was found in Undertow. For an AJP 400 response, EAP 7 is improperly sending two response packets, and those packets have the reuse flag set even though JBoss EAP closes the connection. A failure occurs when the connection is reused after a 400 by CPING since it reads in the second SENDHEADERS response packet instead of a CPONG.

A flaw was found in Undertow where a potential security issue in flow control handling by browser over HTTP/2 may potentially cause overhead or DOS in the server. The highest impact of this vulnerability is availability.(incomplete fix for CVE-2021-3629)

A flaw was found in Undertow that tripped the client-side invocation timeout with certain calls made over HTTP2. This flaw allows an attacker to carry out denial of service attacks.

A flaw was found in Undertow. A buffer leak on the incoming WebSocket PONG message may lead to memory exhaustion. This flaw allows an attacker to cause a denial of service. The highest threat from this vulnerability is availability.

A flaw was found in undertow where HTTP2SourceChannel fails to write final frame under some circumstances may result in DoS. The highest impact of this vulnerability is availability.

A flaw was found in the Undertow AJP connector. Malicious requests and abrupt connection closes could be triggered by an attacker using query strings with non-RFC compliant characters resulting in a denial of service. The highest threat from this vulnerability is to system availability.

In some circumstances Undertow can serve data from a random ByteBuffer, this is due to an incomplete fix for UNDERTOW-438.

Basically if all the headers are not written out in the first write() call then the code that handles flushing the buffer will always write out the full contents of the writevBuffer buffer, which may contain data from previous requests.

Upstream bug:

https://issues.jboss.org/browse/JBEAP-15428

Upstream patch:

https://github.com/jbossas/redhat-undertow/commit/e65ad5b410f95b166ff04f876e22f873e9b4ce62

It was found in Undertow before 1.3.28 that with non-clean TCP close, the Websocket server gets into infinite loop on every IO thread, effectively causing DoS.

It was found that code that parsed the HTTP request line in undertow permitted invalid characters which results into HTTP request smuggling vulnerability.

Directory traversal vulnerability in JBoss Undertow 1.0.x before 1.0.17, 1.1.x before 1.1.0.CR5, and 1.2.x before 1.2.0.Beta3, when running on Windows, allows remote attackers to read arbitrary files via a .. (dot dot) in a resource URI.