Last updated 25 August 2025

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 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.

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 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

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 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