Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
38 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
2.2.39.Final2.3.21.Final2.4.0.Beta1· Vendor fix available
Issue
A flaw was found in Undertow. Servlets using a method that calls HttpServletRequestImpl.getParameterNames() can cause an OutOfMemoryError when the client sends a request with large parameter names. This issue can be exploited by an unauthorized user to cause a remote denial-of-service (DoS) attack.
Recommended action: Upgrade to 2.4.0.Beta1, 2.3.21.Final or 2.2.39.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests. As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.
Recommended action: Upgrade to 2.3.21.Final or 2.2.39.Final by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.2.39.Final2.3.21.Final2.4.0.Beta1· Vendor fix available
Issue
A flaw was found in Undertow that can cause remote denial of service attacks. When the server uses the FormEncodedDataDefinition.doParse(StreamSourceChannel) method to parse large form data encoding with application/x-www-form-urlencoded, the method will cause an OutOfMemory issue. This flaw allows unauthorized users to cause a remote denial of service (DoS) attack.
Recommended action: Upgrade to 2.4.0.Beta1, 2.3.21.Final or 2.2.39.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Undertow where malformed client requests can trigger server-side stream resets without triggering abuse counters. This issue, referred to as the "MadeYouReset" attack, allows malicious clients to induce excessive server workload by repeatedly causing server-side stream aborts. While not a protocol bug, this highlights a common implementation weakness that can be exploited to cause a denial of service (DoS).
Recommended action: Upgrade to 2.3.20.Final or 2.2.38.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Undertow, which incorrectly parses cookies with certain value-delimiting characters in incoming requests. This issue could allow an attacker to construct a cookie value to exfiltrate HttpOnly cookie values or spoof arbitrary additional cookie values, leading to unauthorized data access or modification. The main threat from this flaw impacts data confidentiality and integrity.
Recommended action: Upgrade to 2.3.11.Final or 2.2.30.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server's memory.
Recommended action: Upgrade to 2.3.13.Final or 2.2.32.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests. This issue occurs when the parseProxyProtocolV1 method processes multiple requests on the same HTTP connection. As a result, different requests may share the same StringBuilder instance, potentially leading to information leakage between requests or responses. In some cases, a value from a previous request or response may be erroneously reused, which could lead to unintended data exposure. This issue primarily results in errors and connection termination but creates a risk of data leakage in multi-request environments.
Recommended action: Upgrade to 2.3.17.Final or 2.2.36.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in Undertow. This issue requires enabling the learning-push handler in the server's config, which is disabled by default, leaving the maxAge config in the handler unconfigured. The default is -1, which makes the handler vulnerable. If someone overwrites that config, the server is not subject to the attack. The attacker needs to be able to reach the server with a normal HTTP request.
Recommended action: Upgrade to 2.3.15.Final or 2.2.34.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed. The response headers and body were sent but the client would continue waiting as Undertow does not send the expected 0\r\n termination of the chunked response. This results in uncontrolled resource consumption, leaving the server side to a denial of service attack. This happens only with Java 17 TLSv1.3 scenarios.
Recommended action: Upgrade to 2.3.15.Final or 2.2.34.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in Undertow, where URL-encoded request paths can be mishandled during concurrent requests on the AJP listener. This issue arises because the same buffer is used to decode the paths for multiple requests simultaneously, leading to incorrect path information being processed. As a result, the server may attempt to access the wrong path, causing errors such as "404 Not Found" or other application failures. This flaw can potentially lead to a denial of service, as legitimate resources become inaccessible due to the path mix-up.
Recommended action: Upgrade to 2.3.14.Final or 2.2.33.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in Undertow. This vulnerability impacts a server that supports the wildfly-http-client protocol. Whenever a malicious user opens and closes a connection with the HTTP port of the server and then closes the connection immediately, the server will end with both memory and open file limits exhausted at some point, depending on the amount of memory available. At HTTP upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks connections if RemotingConnection is closed by Remoting ServerConnectionOpenListener. Because the remoting connection originates in Undertow as part of the HTTP upgrade, there is an external layer to the remoting connection. This connection is unaware of the outermost layer when closing the connection during the connection opening procedure. Hence, the Undertow WriteTimeoutStreamSinkConduit is not notified of the closed connection in this scenario. Because WriteTimeoutStreamSinkConduit creates a timeout task, the whole dependency tree…
Recommended action: Upgrade to 2.3.12.Final or 2.2.31.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability was found in Undertow. This issue may allow a remote attacker to append a specially-crafted sequence to an HTTP request for an application deployed to JBoss EAP, which may permit access to privileged or restricted files and directories.
Recommended action: Upgrade to 2.3.12.Final or 2.2.31.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in undertow. This issue makes achieving a denial of service possible due to an unexpected handshake status updated in SslConduit, where the loop never terminates.
Recommended action: Upgrade to 2.3.5.Final or 2.2.24.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The undertow client is not checking the server identity presented by the server certificate in https connections. This should be performed by default in https and in http/2.
Recommended action: Upgrade to 2.3.5.Final or 2.2.24.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In modcluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in "All workers are in error state" and modcluster responds "503 Service Unavailable" for a while (up to 10 seconds). In modproxybalancer, it does not forward requests to the worker until the "retry" timeout passes. However, luckily, modproxybalancer has "forcerecovery" setting (On by default; this parameter can force the immediate recovery of all workers without considering the retry parameter of the workers if all workers of a…
Recommended action: Upgrade to 2.3.0.Alpha2 or 2.2.19.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Undertow client side invocation timeout raised when calling over HTTP2, this vulnerability can allow attacker to carry out denial of service (DoS) attacks in versions less than 2.2.15 Final.
Recommended action: Upgrade to 2.2.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Buffer leak on incoming WebSocket PONG message(s) in Undertow before 2.0.40 and 2.2.10 can lead to memory exhaustion and allow a denial of service.
Recommended action: Upgrade to 2.2.10 or 2.0.40 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Undertow. A potential security issue in flow control handling by the browser over HTTP/2 may potentially cause overhead or a denial of service in the server. The highest threat from this vulnerability is availability. This flaw affects Undertow versions prior to 2.0.40.Final and prior to 2.2.11.Final.
Recommended action: Upgrade to 2.2.11.Final or 2.0.40.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in undertow. The HTTP2SourceChannel fails to write the final frame under some circumstances, resulting in a denial of service. The highest threat from this vulnerability is availability. This flaw affects Undertow versions prior to 2.0.35.SP1, prior to 2.2.6.SP1, prior to 2.2.7.SP1, prior to 2.0.36.SP1, prior to 2.2.9.Final and prior to 2.0.39.Final.
Recommended action: Upgrade to 2.2.9.Final or 2.0.39.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A file inclusion vulnerability was found in the AJP connector enabled with a default AJP configuration port of 8009 in Undertow version 2.0.29.Final and before and was fixed in 2.0.30.Final. A remote, unauthenticated attacker could exploit this vulnerability to read web application files from a vulnerable server. In instances where the vulnerable server allows file uploads, an attacker could upload malicious JavaServer Pages (JSP) code within a variety of file types and trigger this vulnerability to gain remote code execution.
Recommended action: Upgrade to 2.0.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in all undertow-2.x.x SP1 versions prior to undertow-2.0.30.SP1, all undertow-1.x.x and undertow-2.x.x versions prior to undertow-2.1.0.Final, where the Servlet container causes servletPath to normalize incorrectly by truncating the path after semicolon which may lead to an application mapping resulting in the security bypass.
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in the Undertow HTTP server in versions before 2.0.29 when listening on HTTPS. An attacker can target the HTTPS port to carry out a Denial Of Service (DOS) to make the service unavailable on SSL.
Recommended action: Upgrade to 2.0.29.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.2.0.Beta3, 1.1.0.CR5 or 1.0.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A long URL proxy request lead to java.nio.BufferOverflowException in Undertow.
Recommended action: Upgrade to 1.4.3.Final or 1.3.25.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It was discovered that Undertow before 1.4.17, 1.3.31 and 2.0.0 processes http request headers with unusual whitespaces which can cause possible http request smuggling.
Recommended action: Upgrade to 2.0.0.Beta1, 1.4.17 or 1.3.31 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.