Last updated 25 August 2025

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method.

If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTT method. Tomcat's Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page.

Affects: 7.0.0 to 7.0.77, 8.0.0.RC1 to 8.0.43, 8.5.0 to 8.5.14

Upstream fixes:

Tomcat 7.x:

https://svn.apache.org/viewvc?view=revision&revision=1793471 https://svn.apache.org/viewvc?view=revision&revision=1793491

Tomcat 8.0.x:

https://svn.apache.org/viewvc?view=revision&revision=1793470 https://svn.apache.org/viewvc?view=revision&revision=1793489

Tomcat 8.5.x:

https://svn.apache.org/viewvc?view=revision&revision=1793469 https://svn.apache.org/viewvc?view=revision&revision=1793488

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.78 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.44 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.15

A bug in the error handling of the send file code for the NIO HTTP connector in Apache Tomcat 9.0.0.M1 to 9.0.0.M13, 8.5.0 to 8.5.8, 8.0.0.RC1 to 8.0.39, 7.0.0 to 7.0.73 and 6.0.16 to 6.0.48 resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, not not limited to, session ID and the response body. The bug was first noticed in 8.5.x onwards where it appears the refactoring of the Connector code for 8.5.x onwards made it more likely that the bug was observed. Initially it was thought that the 8.5.x refactoring introduced the bug but further investigation has shown that the bug is present in all currently supported Tomcat versions.

It was discovered that the code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack, or obtain sensitive information from requests other then their own.

A bug in the handling of the pipelined requests in Apache Tomcat 9.0.0.M1 to 9.0.0.M18, 8.5.0 to 8.5.12, 8.0.0.RC1 to 8.0.42, 7.0.0 to 7.0.76, and 6.0.0 to 6.0.52, when send file was used, results in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.

Apache Tomcat is vulnerable to a denial of service, caused by HTTP/2 connection window exhaustion on write. By failing to send WINDOWUPDATE messages, a remote attacker could exploit this vulnerability to block threads on the server and cause a denial of service.

Flaw affecting tomcat 8.0.0.RC1 to 8.0.52 and 9.0.0.M1 to 9.0.9 . The host name verification when using TLS with the WebSocket client was not enabled by default.

Upstream patch:

http://svn.apache.org/viewvc?view=revision&revision=1833757 http://svn.apache.org/viewvc?view=rev&rev=1833759

References:

https://tomcat.apache.org/security-8.html https://tomcat.apache.org/security-9.html

An improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.7, 8.5.0 to 8.5.30, 8.0.0.RC1 to 8.0.51, and 7.0.28 to 7.0.86.

In Apache Tomcat 9.0.0.M1 to 9.0.0.M18 and 8.5.0 to 8.5.12, the handling of an HTTP/2 GOAWAY frame for a connection did not close streams associated with that connection that were currently waiting for a WINDOWUPDATE before allowing the application to write more data. These waiting streams each consumed a thread. A malicious client could therefore construct a series of HTTP/2 requests that would consume all available processing threads.

A flaw was found in Apache Tomcat, where the HTTP/2 implementation accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open, which enables them to cause server-side threads to block. This flaw eventually leads to a denial of service attack.

The HTTP/2 implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M21 and 8.5.0 to 8.5.15 bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using a specially crafted URL.