A flaw was found in Apache Tomcat, where the payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. The highest threat from this vulnerability is to system availability.
Last updated 25 August 2025
A vulnerability was discovered in Tomcat where if a servlet context was configured with readonly=false and HTTP PUT requests were allowed, an attacker could upload a JSP file to that context and achieve code execution.
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.
Apache Tomcat 6.x before 6.0.44, 7.x before 7.0.55, and 8.x before 8.0.9 does not properly handle cases where an HTTP response occurs before finishing the reading of an entire request body, which allows remote attackers to cause a denial of service (thread consumption) via a series of aborted upload attempts.
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.
Last updated 25 August 2025
A flaw was found in Apache Commons FileUpload. Specially-crafted input could trigger a denial of service if the buffer used by the MultipartStream was not big enough.
Tomcat 7 includes an embedded copy of Apache Commons FileUpload, so it was possible to craft a malformed Content-Type header for a multipart request which would cause Tomcat to enter an infinite loop.
This has been corrected in Tomcat 7 via commit r1565169 [1]. It has been corrected in Apache Commons FileUpload via commit r1565143 [2].
No new releases have been made with the changes; Tomcat 7.0.51 (not yet released) will correct this flaw.
[1] http://svn.apache.org/viewvc?view=revision&revision=1565169 [2] http://svn.apache.org/viewvc?view=revision&revision=1565143
Apache Tomcat uses a package renamed copy of Apache Commons FileUpload to implement the file upload requirements of the Servlet specification. A denial of service vulnerability was identified in Commons FileUpload that occurred when the length of the multipart boundary was just below the size of the buffer (4096 bytes) used to read the uploaded file. This caused the file upload process to take several orders of magnitude longer than if the boundary was the typical tens of bytes long.
External references:
http://tomcat.apache.org/security-8.html http://tomcat.apache.org/security-7.html
Upstream fixes:
Tomcat 8.5.x:
http://svn.apache.org/viewvc?view=revision&revision=1743722
Tomcat 8.0.x:
http://svn.apache.org/viewvc?view=revision&revision=1743738