Apache Tomcat^®

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat^® 8.x. Each vulnerability is given a security impact rating by the Apache Tomcat security team — please note that this rating may vary from platform to platform. We also list the versions of Apache Tomcat the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Note: Vulnerabilities that are not Tomcat vulnerabilities but have either been incorrectly reported against Tomcat or where Tomcat provides a workaround are listed at the end of this page.

Please note that Tomcat 8.0.x has reached end of life and is no longer supported. Vulnerabilities reported after June 2018 were not checked against the 8.0.x branch and will not be fixed. Users should upgrade to 8.5.x or later to obtain security fixes.

Please note that binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Tomcat version that you are using. For Tomcat 8.5 those are building.html and BUILDING.txt. Both files can be found in the webapps/docs subdirectory of a binary distributive. You may also want to review the Security Considerations page in the documentation.

If you need help on building or configuring Tomcat or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Tomcat Users mailing list

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Tomcat Security Team. Thank you.

• Fixed in Apache Tomcat 8.5.99
• Fixed in Apache Tomcat 8.5.96
• Fixed in Apache Tomcat 8.5.94
• Fixed in Apache Tomcat 8.5.93
• Fixed in Apache Tomcat 8.5.89
• Fixed in Apache Tomcat 8.5.88
• Fixed in Apache Tomcat 8.5.86
• Fixed in Apache Tomcat 8.5.85
• Fixed in Apache Tomcat 8.5.84
• Fixed in Apache Tomcat 8.5.83
• Fixed in Apache Tomcat 8.5.82
• Fixed in Apache Tomcat 8.5.79
• Fixed in Apache Tomcat 8.5.78
• Fixed in Apache Tomcat 8.5.76
• Fixed in Apache Tomcat 8.5.75
• Fixed in Apache Tomcat 8.5.72
• Fixed in Apache Tomcat 8.5.68
• Fixed in Apache Tomcat 8.5.66
• Fixed in Apache Tomcat 8.5.65
• Fixed in Apache Tomcat 8.5.64
• Fixed in Apache Tomcat 8.5.63
• Fixed in Apache Tomcat 8.5.60
• Fixed in Apache Tomcat 8.5.58
• Fixed in Apache Tomcat 8.5.57
• Fixed in Apache Tomcat 8.5.56
• Fixed in Apache Tomcat 8.5.55
• Fixed in Apache Tomcat 8.5.51
• Fixed in Apache Tomcat 8.5.50
• Fixed in Apache Tomcat 8.5.49
• Fixed in Apache Tomcat 8.5.41
• Fixed in Apache Tomcat 8.5.40
• Fixed in Apache Tomcat 8.5.38
• Fixed in Apache Tomcat 8.5.34
• Fixed in Apache Tomcat 8.0.53
• Fixed in Apache Tomcat 8.5.32
• Fixed in Apache Tomcat 8.0.52
• Fixed in Apache Tomcat 8.5.31
• Fixed in Apache Tomcat 8.0.50
• Fixed in Apache Tomcat 8.5.28
• Fixed in Apache Tomcat 8.0.48
• Fixed in Apache Tomcat 8.5.24
• Fixed in Apache Tomcat 8.0.47
• Fixed in Apache Tomcat 8.5.23
• Fixed in Apache Tomcat 8.0.45
• Fixed in Apache Tomcat 8.5.16
• Fixed in Apache Tomcat 8.0.44
• Fixed in Apache Tomcat 8.5.15
• Fixed in Apache Tomcat 8.0.43
• Fixed in Apache Tomcat 8.5.13
• Fixed in Apache Tomcat 8.0.42
• Fixed in Apache Tomcat 8.5.12
• Fixed in Apache Tomcat 8.0.41
• Fixed in Apache Tomcat 8.5.11
• Fixed in Apache Tomcat 8.5.9
• Fixed in Apache Tomcat 8.0.39
• Fixed in Apache Tomcat 8.5.8
• Fixed in Apache Tomcat 8.5.5 and 8.0.37
• Fixed in Apache Tomcat 8.5.3 and 8.0.36
• Fixed in Apache Tomcat 8.0.32
• Fixed in Apache Tomcat 8.0.30
• Fixed in Apache Tomcat 8.0.27
• Fixed in Apache Tomcat 8.0.17
• Fixed in Apache Tomcat 8.0.9
• Fixed in Apache Tomcat 8.0.8
• Fixed in Apache Tomcat 8.0.5
• Fixed in Apache Tomcat 8.0.3
• Fixed in Apache Tomcat 8.0.0-RC10
• Fixed in Apache Tomcat 8.0.0-RC3
• Not a vulnerability in Tomcat
• Not a vulnerability in Tomcat

Important: Denial of Service CVE-2024-23672

It was possible for a WebSocket client to keep a WebSocket connection open leading to increased resource consumption.

This was fixed with commit 3631adb1.

This issue was identified by the Tomcat Security Team on 17 January 2024. The issue was made public on 13 March 2024.

Affects: 8.5.0 to 8.5.98

Important: Denial of Service CVE-2024-24549

When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.

This was fixed with commit 0cac540a.

This issue was reported to the Tomcat Security Team on 24 January 2024. The issue was made public on 13 March 2024.

Affects: 8.5.0 to 8.5.98

Important: Request smuggling CVE-2023-46589

Tomcat did not correctly parse HTTP trailer headers. A specially crafted trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.

This was fixed with commit aa92971e.

This issue was reported to the Tomcat Security Team on 20 October 2023. The issue was made public on 28 November 2023.

Affects: 8.5.0 to 8.5.95

Important: Request smuggling CVE-2023-45648

Tomcat did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.

This was fixed with commit 59583245.

This issue was reported to the Tomcat Security Team on 12 September 2023. The issue was made public on 10 October 2023.

Affects: 8.5.0 to 8.5.93

Important: Denial of Service CVE-2023-44487

Tomcat's HTTP/2 implementation was vulnerable to the rapid reset attack. The denial of service typically manifested as an OutOfMemoryError.

This was fixed with commit 944332bb.

This issue was reported to the Tomcat Security Team on 14 September 2023. The issue was made public on 10 October 2023.

Affects: 8.5.0 to 8.5.93

Important: Information Disclosure CVE-2023-42795

When recycling various internal objects, including the request and the response, prior to re-use by the next request/response, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.

This was fixed with commit 30f8063d.

This issue was identified by the Tomcat Security Team on 13 September 2023. The issue was made public on 10 October 2023.

Affects: 8.5.0 to 8.5.93

Low: Denial of Service CVE-2023-42794

Tomcat's internal fork of a Commons FileUpload included an unreleased, in progress refactoring that exposed a potential denial of service on Windows if a web application opened a stream for an uploaded file but failed to close the stream. The file would never be deleted from disk creating the possibility of an eventual denial of service due to the disk being full.

This was fixed with commit c99ffc30.

This issue was reported to the Tomcat Security Team on 1 September 2023. The issue was made public on 10 October 2023.

Affects: 8.5.85 to 8.5.93

Moderate: Open redirect CVE-2023-41080

If the ROOT (default) web application is configured to use FORM authentication then it is possible that a specially crafted URL could be used to trigger a redirect to an URL of the attackers choice.

This was fixed with commit 4998ad74.

This issue was reported to the Tomcat Security Team on 17 August 2023. The issue was made public on 22 August 2023.

Affects: 8.5.0 to 8.5.92

Important: Information disclosure CVE-2023-34981

The fix for bug 66512 introduced a regression that was fixed as bug 66591. The regression meant that, if a response did not have any HTTP headers set, no AJP SEND_HEADERS message would be sent which in turn meant that at least one AJP based proxy (mod_proxy_ajp) would use the response headers from the previous request for the current request leading to an information leak.

This was fixed with commit 2214c803.

This issue was reported to the Tomcat Security Team on 24 May 2023. The issue was made public on 21 June 2023.

Affects: 8.5.88

Moderate: Apache Tomcat denial of service CVE-2023-28709

The fix for CVE-2023-24998 was incomplete. If non-default HTTP connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur.

This was fixed with commit 5badf94e.

This issue was reported to the Tomcat Security Team on 13 March 2023. The issue was made public on 22 May 2023.

Affects: 8.5.85 to 8.5.87

Important: Apache Tomcat information disclosure CVE-2023-28708

When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Tomcat did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel.

This was fixed with commit 5b72c94e.

66471 was reported publicly on 8 February 2023. The security implications were identified by the Tomcat Security team on 9 February 2023. The issue was made public on 22 March 2023.

Affects: 8.5.0 to 8.5.85

Important: Apache Tomcat denial of service CVE-2023-24998

Apache Tomcat uses a packaged renamed copy of Apache Commons FileUpload to provide the file upload functionality defined in the Jakarta Servlet specification. Apache Tomcat was, therefore, also vulnerable to the Apache Commons FileUpload vulnerability CVE-2023-24998 as there was no limit to the number of request parts processed. This resulted in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads.

This was fixed with commit 9ca96c8c.

This issue was reported to the Apache Tomcat Security team on 11 December 2022. The issue was made public on 20 February 2023.

Affects: 8.5.0 to 8.5.84

Low: Apache Tomcat JsonErrorReportValve injection CVE-2022-45143

The JsonErrorReportValve did not escape the type, message or description values. In some circumstances these are constructed from user provided data and it was therefore possible for users to supply values that invalidated or manipulated the JSON output.

This was fixed with commit 0cab3a56.

This issue was identified by the Apache Tomcat Security team on 2 September 2022. The issue was made public on 3 January 2023.

Affects: 8.5.83

Low: Apache Tomcat request smuggling CVE-2022-42252

If Tomcat was configured to ignore invalid HTTP headers via setting rejectIllegalHeader to false (the default), Tomcat did not reject a request containing an invalid Content-Length header making a request smuggling attack possible if Tomcat was located behind a reverse proxy that also failed to reject the request with the invalid header.

This was fixed with commit a1c07906.

This issue was reported to the Apache Tomcat Security team on 29 September 2022. The issue was made public on 31 October 2022.

Affects: 8.5.0 to 8.5.82

Low: Apache Tomcat XSS in examples web application CVE-2022-34305

The Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability.

This was fixed with commit 5f6c88b0.

This issue was reported to the Apache Tomcat Security team on 22 June 2022. The issue was made public on 23 June 2022.

Affects: 8.5.50 to 8.5.81

Low: Apache Tomcat EncryptInterceptor DoS CVE-2022-29885

The documentation for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks.

This was fixed with commit b679bc62.

This issue was reported to the Apache Tomcat Security team by 4ra1n on 17 April 2022. The issue was made public on 10 May 2022.

Affects: 8.5.38 to 8.5.78

High: Information Disclosure CVE-2021-43980

The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.

This was fixed with commit 4a00b0c0.

This issue was reported to the Apache Tomcat Security team by Adam Thomas, Richard Hernandez and Ryan Schmitt on 11 November 2021. The issue was made public on 28 September 2022.

Affects: 8.5.0 to 8.5.77

Important: Request mix-up CVE-2022-25762

If a web application sends a WebSocket message concurrently with the WebSocket connection closing, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.

This was fixed with commit 01f2cf25.

This issue was identified by the Apache Tomcat Security Team on 21 December 2021. The issue was made public on 12 May 2022.

Affects: 8.5.0 to 8.5.75

Note: The issue below was fixed in Apache Tomcat 8.5.74 but the release vote for the 8.5.74 release candidate did not pass. Therefore, although users must download 8.5.75 to obtain a version that includes a fix for these issues, version 8.5.74 is not included in the list of affected versions.

Low: Local Privilege Escalation CVE-2022-23181

The fix for bug CVE-2020-9484 introduced a time of check, time of use vulnerability that allowed a local attacker to perform actions with the privileges of the user that the Tomcat process is using. This issue is only exploitable when Tomcat is configured to persist sessions using the FileStore.

This was fixed with commit 97943959.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 10 December 2021. The issue was made public on 26 January 2022.

Affects: 8.5.55 to 8.5.73

Important: Denial of Service CVE-2021-42340

The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.

This was fixed with commit d27535bd.

The memory leak was reported publicly via the users mailing list on 23 September 2021. The security implications were identified by the Tomcat Security team the same day. The issue was made public on 14 October 2021.

Affects: 8.5.60 to 8.5.71

Note: The issue below was fixed in Apache Tomcat 8.5.67 but the release vote for the 8.5.67 release candidate did not pass. Therefore, although users must download 8.5.68 to obtain a version that includes a fix for this issue, version 8.5.67 is not included in the list of affected versions.

Important: Request Smuggling CVE-2021-33037

Apache Tomcat did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility of request smuggling when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the transfer-encoding header if the client declared it would only accept an HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

This was fixed with commits 3202703e, da0e7cb0 and 8874fa02.

This issue was reported to the Apache Tomcat Security team by Bahruz Jabiyev, Steven Sprecher and Kaan Onarlioglu of NEU seclab on 7 May 2021. The issue was made public on 12 July 2021.

This issue was identified and reported responsibly .

Affects: 8.5.0 to 8.5.66

Low: Authentication weakness CVE-2021-30640

Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (eg user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm.

This was fixed with commits 24dfb300, 0a272b00, c9f21a2a, 4e86b4ea, 79580e7f, d3407672, 6a9129ac and ad22db64.

This issue was reported publicly as 65224.

Affects: 8.5.0 to 8.5.65

Important: Denial of Service CVE-2021-30639

An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS.

Applications that do not use non-blocking I/O are not exposed to this vulnerability.

This was fixed with commit 411caf29.

This issue was reported publicly as 65203.

Affects: 8.5.64

Important: Denial of Service CVE-2021-41079

When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service.

This was fixed with commit b90d4fc1.

This issue was first reported to the Apache Tomcat Security Team by Thomas Wozenilek on 26 February 2021 but could not be confirmed. A speculative fix was applied on 3 March 2021. On 14 September 2021 David Frankson of Infinite Campus independently reported the issue and included a test case. This allowed both the issue and the speculative fix to be verified. The issue was made public on 15 September 2021.

Affects: 8.5.0 to 8.5.63

Important: Information Disclosure CVE-2024-21733

Incomplete POST requests triggered an error response that could contain data from a previous request from another user.

This was fixed with commit ce4b154e.

This issue was reported to the Apache Tomcat Security Team by xer0dayz from Sn1perSecurity LLC on 20 December 2023. The issue was made public on 19 January 2024.

Affects: 8.5.7 to 8.5.63

Note: The issues below were fixed in Apache Tomcat 8.5.62 but the release vote for the 8.5.62 release candidate did not pass. Therefore, although users must download 8.5.63 to obtain a version that includes a fix for these issues, version 8.5.62 is not included in the list of affected versions.

Low: Fix for CVE-2020-9484 was incomplete CVE-2021-25329

The fix for CVE-2020-9484 was incomplete. When using a highly unlikely configuration edge case, the Tomcat instance was still vulnerable to CVE-2020-9484. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published non-upgrade mitigations for CVE-2020-9484 also apply to this issue.

This was fixed with commit 93f0cc40.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 12 January 2021. The issue was made public on 1 March 2021.

Affects: 8.5.0 to 8.5.61

Important: Request mix-up with h2c CVE-2021-25122

When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.

This was fixed with commit bb0e7c1e.

This issue was identified by the Apache Tomcat Security team on 11 January 2021. The issue was made public on 1 March 2021.

Affects: 8.5.0 to 8.5.61

Important: Information disclosure CVE-2021-24122

When serving resources from a network location using the NTFS file system it was possible to bypass security constraints and/or view the source code for JSPs in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.

This was fixed with commit 920dddbd.

This issue was reported the Apache Tomcat Security team by Ilja Brander on 26 October 2020. The issue was made public on 14 January 2021.

Affects: 8.5.0 to 8.5.59

Moderate: HTTP/2 request header mix-up CVE-2020-17527

While investigating issue 64830 it was discovered that Apache Tomcat could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.

This was fixed with commit 21e34086.

This issue was identified by the Apache Tomcat Security team on 10 November 2020. The issue was made public on 3 December 2020.

Affects: 8.5.0 to 8.5.59

Moderate: HTTP/2 request mix-up CVE-2020-13943

If an HTTP/2 client exceeded the agreed maximum number of concurrent streams for a connection (in violation of the HTTP/2 protocol), it was possible that a subsequent request made on that connection could contain HTTP headers - including HTTP/2 pseudo headers - from a previous request rather than the intended headers. This could lead to users seeing responses for unexpected resources.

This was fixed with commit 9d7def06.

This issue was identified by the Apache Tomcat Security team on 23 July 2020. The issue was made public on 12 October 2020.

Affects: 8.5.0 to 8.5.57

Important: WebSocket DoS CVE-2020-13935

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.

This was fixed with commit 12d71567.

This issue was reported publicly via the Apache Bugzilla instance on 28 June 2020 and included references to high CPU but no specific reference to denial of service. The associated DoS risks were identified by the Apache Tomcat Security Team the same day. The issue was made public on 14 July 2020.

Affects: 8.5.0 to 8.5.56

Moderate: HTTP/2 DoS CVE-2020-13934

An h2c direct connection did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.

This was fixed with commit 923d8345.

This issue was reported publicly via the Apache Tomcat Users mailing list on 22 June 2020 without reference to the potential for DoS. After further discussion to identify the steps necessary to reproduce the issue, the root cause of the issue and the associated DoS risks were identified by the Apache Tomcat Security Team on 26 June 2020. The issue was made public on 14 July 2020.

Affects: 8.5.1 to 8.5.56

Important: HTTP/2 DoS CVE-2020-11996

A specially crafted sequence of HTTP/2 requests could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.

This was fixed with commit c8acd2ab.

This issue was reported publicly via the Apache Tomcat Users mailing list on 21 May 2020 without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team the same day. The issue was made public on 25 June 2020.

Affects: 8.5.0 to 8.5.55

Important: Remote Code Execution via session persistence CVE-2020-9484

If:

• an attacker is able to control the contents and name of a file on the server; and
• the server is configured to use the PersistenceManager with a FileStore; and
• the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and
• the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over;

then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control.

Note: All of conditions above must be true for the attack to succeed.

As an alternative to upgrading to 8.5.35 or later, users may configure the PersistenceManager with an appropriate value for sessionAttributeValueClassNameFilter to ensure that only application provided attributes are serialized and deserialized.

This was fixed with commit ec08af18.

This issue was reported to the Apache Tomcat Security Team by by jarvis threedr3am of pdd security research on 12 April 2020. The issue was made public on 20 May 2020.

Affects: 8.5.0 to 8.5.54

Important: AJP Request Injection and potential Remote Code Execution CVE-2020-1938

When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. Prior to Tomcat 8.5.51, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required.

Prior to this vulnerability report, the known risks of an attacker being able to access the AJP port directly were:

• bypassing security checks based on client IP address
• bypassing user authentication if Tomcat was configured to trust authentication data provided by the reverse proxy

This vulnerability report identified a mechanism that allowed the following:

• returning arbitrary files from anywhere in the web application including under the WEB-INF and META-INF directories or any other location reachable via ServletContext.getResourceAsStream()
• processing any file in the web application as a JSP

Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible.

It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31 or later. Users should note that a number of changes were made to the default AJP Connector configuration in 8.5.51 to harden the default configuration. It is likely that users upgrading to 8.5.51 or later will need to make small changes to their configurations as a result.

This was fixed with commits 69c56080, b962835f, 5a5494f0, 9be57601, 64159aa1 and 03c43612.

This issue was reported to the Apache Tomcat Security Team on 3 January 2020. The issue was made public on 24 February 2020.

Affects: 8.5.0 to 8.5.50

Low: HTTP Request Smuggling CVE-2020-1935

The HTTP header parsing code used an approach to end-of-line (EOL) parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.

This was fixed with commit 8fbe2e96.

This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 25 December 2019. The issue was made public on 24 February 2020.

Affects: 8.5.0 to 8.5.50

Low: HTTP Request Smuggling CVE-2019-17569

The refactoring in 8.5.48 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.

This was fixed with commit 959f1dfd.

This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 12 December 2019. The issue was made public on 24 February 2020.

Affects: 8.5.48 to 8.5.50

Low: Session fixation CVE-2019-17563

When using FORM authentication there was a narrow window where an attacker could perform a session fixation attack. The window was considered too narrow for an exploit to be practical but, erring on the side of caution, this issue has been treated as a security vulnerability.

This was fixed with commit e19a202e.

This issue was reported to the Apache Tomcat Security Team by William Marlow (IBM) on 19 November 2019. The issue was made public on 18 December 2019.

Affects: 8.5.0 to 8.5.49

Note: The issue below was fixed in Apache Tomcat 8.0.48 but the release vote for the 8.0.48 release candidate did not pass. Therefore, although users must download 8.0.49 to obtain a version that includes the fix for this issue, version 8.0.48 is not included in the list of affected versions.

Moderate: Local Privilege Escalation CVE-2019-12418

When Tomcat is configured with the JMX Remote Lifecycle Listener, a local attacker without access to the Tomcat process or configuration files is able to manipulate the RMI registry to perform a man-in-the-middle attack to capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and gain complete control over the Tomcat instance.

The JMX Remote Lifecycle Listener will be deprecated in future Tomcat releases, will be removed for Tomcat 10 and may be removed from all Tomcat releases some time after 31 December 2020.

Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables this issue to be exploited remotely.

This was fixed with commit a91d7db4.

This issue was reported to the Apache Tomcat Security Team by An Trinh of Viettel Cyber Security on 10 October 2019. The issue was made public on 18 December 2019.

Affects: 8.5.0 to 8.5.47

Important: Denial of Service CVE-2019-10072

The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write. By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.

This was fixed with commits 0bcd69c9 and 8d14c6f2.

This issue was reported to the Apache Tomcat Security Team by John Simpson of Trend Micro Security Research working with Trend Micro's Zero Day Initiative on 26 April 2019. The issue was made public on 20 June 2019.

Affects: 8.5.0 to 8.5.40

Important: Remote Code Execution on Windows CVE-2019-0232

When running on Windows with enableCmdLineArguments enabled, the CGI Servlet is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. For a detailed explanation of the JRE behaviour, see Markus Wulftange's blog and this archived MSDN blog.

This was fixed with commit 5bc4e6d7.

This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 3rd March 2019. The issue was made public on 10 April 2019.

Affects: 8.5.0 to 8.5.39

Low: XSS in SSI printenv CVE-2019-0221

The SSI printenv command echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website.

This was fixed with commit 4fcdf706.

This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 7th March 2019. The issue was made public on 17 May 2019.

Affects: 8.5.0 to 8.5.39

Important: Denial of Service CVE-2019-0199

The HTTP/2 implementation accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open without reading/writing request/response data. By keeping streams open for requests that utilised the Servlet API's blocking I/O, clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.

This was fixed in revisions 1852707, 1852711, 1852712, 1852713, 1852714, 1852715, 1852717, 1852718, 1852719, 1852722, 1852723, 1852724 and 60a3af17.

This issue was reported to the Apache Tomcat Security Team by Michal Karm Babacek from Red Hat, Inc on 4 January 2019 with additional issues identified by the Tomcat Security Team. The issue was made public on 25 March 2019.

Affects: 8.5.0 to 8.5.37

Moderate: Open Redirect CVE-2018-11784

When the default servlet returned a redirect to a directory (e.g. redirecting to /foo/ when the user requested /foo) a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice.

This was fixed in revision 1840056.

This issue was reported to the Apache Tomcat Security Team by Sergey Bobrov on 28 August 2018 and made public on 3 October 2018.

Affects: 8.5.0 to 8.5.33

Low: host name verification missing in WebSocket client CVE-2018-8034

The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default.

This was fixed in revision 1833759.

This issue was reported publicly on 11 June 2018 and formally announced as a vulnerability on 22 July 2018.

Affects: 8.0.0.RC1 to 8.0.52

Low: CORS filter has insecure defaults CVE-2018-8014

The defaults settings for the CORS filter are insecure and enable supportsCredentials for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue.

This was fixed in revision 1831729.

This issue was reported publicly on 1 May 2018 and formally announced as a vulnerability on 16 May 2018.

Important: Information Disclosure CVE-2018-8037

If an async request was completed by the application at the same time as the container triggered the async timeout, a race condition existed that could result in a user seeing a response intended for a different user. An additional issue was present in the NIO and NIO2 connectors that did not correctly track the closure of the connection when an async request was completed by the application and timed out by the container at the same time. This could also result in a user seeing a response intended for another user.

This was fixed in revisions 1833826, 1833832, 1837531 and 1833907.

This issue was reported to the Apache Tomcat Security Team by Dmitry Treskunov on 16 June 2018 and made public on 22 July 2018.

Affects: 8.5.5 to 8.5.31

Low: host name verification missing in WebSocket client CVE-2018-8034

The host name verification when using TLS with the WebSocket client was missing. It is now enabled by default.

This was fixed in revision 1833758.

This issue was reported publicly on 11 June 2018 and formally announced as a vulnerability on 22 July 2018.

Affects: 8.5.0 to 8.5.31

Low: CORS filter has insecure defaults CVE-2018-8014

The defaults settings for the CORS filter are insecure and enable supportsCredentials for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue.

This was fixed in revision 1831728.

This issue was reported publicly on 1 May 2018 and formally announced as a vulnerability on 16 May 2018.

Important: A bug in the UTF-8 decoder can lead to DoS CVE-2018-1336

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.

This was fixed in revision 1830375.

This issue was reported publicly on 6 April 2018 and formally announced as a vulnerability on 22 July 2018.

Affects: 8.0.0.RC1 to 8.0.51

Important: A bug in the UTF-8 decoder can lead to DoS CVE-2018-1336

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.

This was fixed in revision 1830374.

This issue was reported publicly on 6 April 2018 and formally announced as a vulnerability on 22 July 2018.

Affects: 8.5.0 to 8.5.30

Important: Security constraint annotations applied too late CVE-2018-1305

Security constraints defined by annotations of Servlets were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.

This was fixed in revisions 1823319 and 1824359.

This issue was identified by the Apache Tomcat Security on 1 February 2018 and made public on 23 February 2018.

Affects: 8.0.0.RC1 to 8.0.49

Important: Security constraints mapped to context root are ignored CVE-2018-1304

The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected.

This was fixed in revision 1823308.

This issue was reported publicly as 62067 on 31 January 2018 and the security implications identified by the Apache Tomcat Security Team the same day. It was made public on 23 February 2018.

Affects: 8.0.0.RC1 to 8.0.49

Important: Security constraint annotations applied too late CVE-2018-1305

Security constraints defined by annotations of Servlets were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.

This was fixed in revisions 1823314 and 1824358.

This issue was identified by the Apache Tomcat Security on 1 February 2018 and made public on 23 February 2018.

Affects: 8.5.0 to 8.5.27

Important: Security constraints mapped to context root are ignored CVE-2018-1304

The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected.

This was fixed in revision 1823307.

This issue was reported publicly as 62067 on 31 January 2018 and the security implications identified by the Apache Tomcat Security Team the same day. It was made public on 23 February 2018.

Affects: 8.5.0 to 8.5.27

Low: Incorrectly documented CGI search algorithm CVE-2017-15706

As part of the fix for bug 61201, the description of the search algorithm used by the CGI Servlet to identify which script to execute was updated. The update was not correct. As a result, some scripts may have failed to execute as expected and other scripts may have been executed unexpectedly. Note that the behaviour of the CGI servlet has remained unchanged in this regard. It is only the documentation of the behaviour that was wrong and has been corrected.

This was fixed in revision 1814827.

This issue was reported to the Apache Tomcat Security Team by Jan Michael Greiner on 17 September 2017 and made public on 31 January 2018.

Affects: 8.0.45 to 8.0.47

Low: Incorrectly documented CGI search algorithm CVE-2017-15706

As part of the fix for bug 61201, the description of the search algorithm used by the CGI Servlet to identify which script to execute was updated. The update was not correct. As a result, some scripts may have failed to execute as expected and other scripts may have been executed unexpectedly. Note that the behaviour of the CGI servlet has remained unchanged in this regard. It is only the documentation of the behaviour that was wrong and has been corrected.

This was fixed in revision 1814826.

This issue was reported to the Apache Tomcat Security Team by Jan Michael Greiner on 17 September 2017 and made public on 31 January 2018.

Affects: 8.5.16 to 8.5.23

Important: Remote Code Execution CVE-2017-12617

When running with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.

This was fixed in revision 1809921.

This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.

Affects: 8.0.0.RC1 to 8.0.46

Important: Remote Code Execution CVE-2017-12617

When running with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.

This was fixed in revisions 1809673, 1809675 and 1809896.

This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.

Affects: 8.5.0 to 8.5.22

Moderate: Cache Poisoning CVE-2017-7674

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

This was fixed in revision 1795815.

The issue was reported as bug 61101 on 16 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. This issue was made public on 10 August 2017.

Affects: 8.0.0.RC1 to 8.0.44

Important: Security Constraint Bypass CVE-2017-7675

The HTTP/2 implementation bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using an specially crafted URL.

This was fixed in revision 1796091.

The issue was originally reported as a failure to process URL path parameters in bug 61120 on 24 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. This issue was made public on 10 August 2017.

Affects: 8.5.0 to 8.5.15

Moderate: Cache Poisoning CVE-2017-7674

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

This was fixed in revision 1795814.

The issue was reported as bug 61101 on 16 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. This issue was made public on 10 August 2017.

Affects: 8.5.0 to 8.5.15

Important: Security Constraint Bypass CVE-2017-5664

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

Notes for other user provided error pages:

• Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
• By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

This was fixed in revisions 1793470 and 1793489.

This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.

Affects: 8.0.0.RC1 to 8.0.43

Important: Security Constraint Bypass CVE-2017-5664

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

Notes for other user provided error pages:

• Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
• By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

This was fixed in revisions 1793469 and 1793488.

This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.

Affects: 8.5.0 to 8.5.14

Important: Information Disclosure CVE-2017-5647

A bug in the handling of the pipelined requests when send file was used resulted 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.

This was fixed in revision 1788999.

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

Affects: 8.0.0.RC1 to 8.0.42

Important: Information Disclosure CVE-2017-5651

The refactoring of the HTTP connectors for 8.5.x onwards, introduced a regression in the send file processing. If the send file processing completed quickly, it was possible for the Processor to be added to the processor cache twice. This could result in the same Processor being used for multiple requests which in turn could lead to unexpected errors and/or response mix-up.

This was fixed in revision 1788546.

This issue was identified by the Apache Tomcat Security Team on 24 March 2017 and made public on 10 April 2017.

Affects: 8.5.0 to 8.5.12

Important: Denial of Service CVE-2017-5650

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

This was fixed in revision 1788480.

This issue was reported to the Apache Tomcat Security Team by Chun Han Hsiao on 11 March 2017 and made public on 10 April 2017.

Affects: 8.5.0 to 8.5.12

Important: Information Disclosure CVE-2017-5647

A bug in the handling of the pipelined requests when send file was used resulted 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.

This was fixed in revision 1788932.

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

Affects: 8.5.0 to 8.5.12

Low: Information Disclosure CVE-2017-5648

While investigating bug 60718, it was noticed that some calls to application listeners did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.

This was fixed in revision 1785776.

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

Affects: 8.0.0.RC1 to 8.0.41

Low: Information Disclosure CVE-2017-5648

While investigating bug 60718, it was noticed that some calls to application listeners did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.

This was fixed in revision 1785775.

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

Affects: 8.5.0 to 8.5.11

Note: The issue below was fixed in Apache Tomcat 8.0.40 but the release vote for the 8.0.40 release candidate did not pass. Therefore, although users must download 8.0.41 to obtain a version that includes the fix for this issue, version 8.0.40 is not included in the list of affected versions.

Important: Information Disclosure CVE-2016-8745

A bug in the error handling of the send file code for the NIO HTTP connector 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, but not limited to, session ID and the response body.

This was fixed in revision 1777469.

This issue was identified as affecting 8.0.x by the Apache Tomcat Security Team on 3 January 2016 and made public on 5 January 2017.

Affects: 8.0.0.RC1 to 8.0.39

Note: The issue below was fixed in Apache Tomcat 8.5.10 but the release vote for the 8.5.10 release candidate did not pass. Therefore, although users must download 8.5.11 to obtain a version that includes the fix for this issue, version 8.5.10 is not included in the list of affected versions.

Moderate: Information Disclosure CVE-2016-8747

The refactoring to make wider use of ByteBuffer introduced a regression that could cause information to leak between requests on the same connection. When running behind a reverse proxy, this could result in information leakage between users. All HTTP connector variants are affected but HTTP/2 and AJP are not affected.

This was fixed in revision 1774166.

This issue was identified by the Apache Tomcat Security Team on 14 December 2016 and made public on 13 March 2017.

Affects: 8.5.7 to 8.5.9

Important: Information Disclosure CVE-2016-8745

A bug in the error handling of the send file code for the NIO HTTP connector 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, but not limited to, session ID and the response body.

This was fixed in revision 1771857.

This issue was identified by the Apache Tomcat Security Team on 8 December 2016 and made public on 12 December 2016.

Affects: 8.5.0 to 8.5.8

Important: Remote Code Execution CVE-2016-8735

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be accessible to an attacker even when the listener is used.

This was fixed in revision 1767656.

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

Affects: 8.0.0.RC1 to 8.0.38

Important: Information Disclosure CVE-2016-6816

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 and/or obtain sensitive information from requests other then their own.

This was fixed in revision 1767653.

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

Affects: 8.0.0.RC1 to 8.0.38

Note: The issues below were fixed in Apache Tomcat 8.5.7 but the release vote for the 8.5.7 release candidate did not pass. Therefore, although users must download 8.5.8 to obtain a version that includes fixes for these issues, version 8.5.7 is not included in the list of affected versions.

Important: Remote Code Execution CVE-2016-8735

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be accessible to an attacker even when the listener is used.

This was fixed in revision 1767646.

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

Affects: 8.5.0 to 8.5.6

Important: Denial of Service CVE-2016-6817

The HTTP/2 header parser entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.

This was fixed in revision 1765798.

This issue was reported as 60232 on 10 October 2016 and the security implications identified by the Apache Tomcat Security Team on the same day. It was made public on 22 November 2016.

Affects: 8.5.0 to 8.5.6

Important: Information Disclosure CVE-2016-6816

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 and/or obtain sensitive information from requests other then their own.

This was fixed in revision 1767645.

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

Affects: 8.5.0 to 8.5.6

Low: Unrestricted Access to Global Resources CVE-2016-6797

The ResourceLinkFactory did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.

This was fixed in revision 1757272 for 8.5.x and revision 1757273 for 8.0.x.

This issue was identified by the Apache Tomcat Security Team on 18 January 2016 and made public on 27 October 2016.

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

Low: Security Manager Bypass CVE-2016-6796

A malicious web application was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.

This was fixed in revisions 1758493 and 1763233 for 8.5.x and revisions 1758494 and 1763234for 8.0.x.

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

Low: System Property Disclosure CVE-2016-6794

When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. Tomcat's system property replacement feature for configuration files could be used by a malicious web application to bypass the SecurityManager and read system properties that should not be visible.

This was fixed in revision 1754726 for 8.5.x and revision 1754727 for 8.0.x.

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

Low: Security Manager Bypass CVE-2016-5018

A malicious web application was able to bypass a configured SecurityManager via a Tomcat utility method that was accessible to web applications.

This was fixed in revisions 1754900 and 1760305 for 8.5.x and revisions 1754901 and 1760307 for 8.0.x.

This issue was discovered by Alvaro Munoz and Alexander Mirosh of the HP Enterprise Security Team and reported to the Apache Tomcat Security Team on 5 July 2016. It was made public on 27 October 2016.

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

Low: Timing Attack CVE-2016-0762

The Realm implementations did not process the supplied password if the supplied user name did not exist. This made a timing attack possible to determine valid user names. Note that the default configuration includes the LockOutRealm which makes exploitation of this vulnerability harder.

This was fixed in revision 1758500 for 8.5.x and revision 1758501 for 8.0.x.

This issue was identified by the Apache Tomcat Security Team on 1 January 2016 and made public on 27 October 2016.

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

Moderate: Denial of Service CVE-2016-3092

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.

This was fixed in revision 1743722 for 8.5.x and revision 1743738 for 8.0.x.

This issue was identified by the TERASOLUNA Framework Development Team and reported to the Apache Commons team via JPCERT on 9 May 2016. It was made public on 21 June 2016.

Affects: 8.5.0 to 8.5.2, 8.0.0.RC1 to 8.0.35

Note: The issues below were fixed in Apache Tomcat 8.0.31 but the release vote for the 8.0.31 release candidate did not pass. Therefore, although users must download 8.0.32 to obtain a version that includes fixes for these issues, version 8.0.31 is not included in the list of affected versions.

Low: Session Fixation CVE-2015-5346

When recycling the Request object to use for a new request, the requestedSessionSSL field was not recycled. This meant that a session ID provided in the next request to be processed using the recycled Request object could be used when it should not have been. This gave the client the ability to control the session ID. In theory, this could have been used as part of a session fixation attack but it would have been hard to achieve as the attacker would not have been able to force the victim to use the 'correct' Request object. It was also necessary for at least one web application to be configured to use the SSL session ID as the HTTP session ID. This is not a common configuration.

This was fixed in revisions 1713185 and 1723506.

This issue was identified by the Tomcat security team on 22 June 2014 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Moderate: CSRF token leak CVE-2015-5351

The index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. If an attacker had access to the Manager or Host Manager applications (typically these applications are only accessible to internal users, not exposed to the Internet), this token could then be used by the attacker to construct a CSRF attack.

This was fixed in revisions 1720658 and 1720660.

This issue was identified by the Tomcat security team on 8 December 2015 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Low: Security Manager bypass CVE-2016-0706

This issue only affects users running untrusted web applications under a security manager.

The internal StatusManagerServlet could be loaded by a malicious web application when a security manager was configured. This servlet could then provide the malicious web application with a list of all deployed applications and a list of the HTTP request lines for all requests currently being processed. This could have exposed sensitive information from other web applications, such as session IDs, to the web application.

This was fixed in revision 1722800.

This issue was identified by the Tomcat security team on 27 December 2015 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Moderate: Security Manager bypass CVE-2016-0714

This issue only affects users running untrusted web applications under a security manager.

Tomcat provides several session persistence mechanisms. The StandardManager persists session over a restart. The PersistentManager is able to persist sessions to files, a database or a custom Store. The cluster implementation persists sessions to one or more additional nodes in the cluster. All of these mechanisms could be exploited to bypass a security manager. Session persistence is performed by Tomcat code with the permissions assigned to Tomcat internal code. By placing a carefully crafted object into a session, a malicious web application could trigger the execution of arbitrary code.

This was fixed in revisions 1726196 and 1726203.

This issue was identified by the Tomcat security team on 12 November 2015 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Moderate: Security Manager bypass CVE-2016-0763

This issue only affects users running untrusted web applications under a security manager.

ResourceLinkFactory.setGlobalContext() is a public method and was accessible to web applications even when running under a security manager. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

This was fixed in revision 1725929.

This issue was identified by the Tomcat security team on 18 January 2016 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Low: Directory disclosure CVE-2015-5345

When accessing a directory protected by a security constraint with a URL that did not end in a slash, Tomcat would redirect to the URL with the trailing slash thereby confirming the presence of the directory before processing the security constraint. It was therefore possible for a user to determine if a directory existed or not, even if the user was not permitted to view the directory. The issue also occurred at the root of a web application in which case the presence of the web application was confirmed, even if a user did not have access.

The solution was to implement the redirect in the DefaultServlet so that any security constraints and/or security enforcing Filters were processed before the redirect. The Tomcat team recognised that moving the redirect could cause regressions so two new Context configuration options (mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled) were introduced. The initial default was false for both since this was more secure. However, due to regressions such as Bug 58765 the default for mapperContextRootRedirectEnabled was later changed to true since it was viewed that the regression was more serious than the security risk of associated with being able to determine if a web application was deployed at a given path.

This was fixed in revisions 1715207 and 1717209.

This issue was identified by Mark Koek of QCSec on 12 October 2015 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.29

Low: Limited directory traversal CVE-2015-5174

This issue only affects users running untrusted web applications under a security manager.

When accessing resources via the ServletContext methods getResource() getResourceAsStream() and getResourcePaths() the paths should be limited to the current web application. The validation was not correct and paths of the form "/.." were not rejected. Note that paths starting with "/../" were correctly rejected. This bug allowed malicious web applications running under a security manager to obtain a directory listing for the directory in which the web application had been deployed. This should not be possible when running under a security manager. Typically, the directory listing that would be exposed would be for $CATALINA_BASE/webapps.

This was fixed in revisions 1696281 and 1700897.

This issue was identified by the Tomcat security team on 12 August 2015 and made public on 22 February 2016.

Affects: 8.0.0-RC1 to 8.0.26

Note: The issue below was fixed in Apache Tomcat 8.0.16 but the release vote for the 8.0.16 release candidate did not pass. Therefore, although users must download 8.0.17 to obtain a version that includes a fix for this issue, version 8.0.16 is not included in the list of affected versions.

Moderate: Security Manager bypass CVE-2014-7810

Malicious web applications could use expression language to bypass the protections of a Security Manager as expressions were evaluated within a privileged code section.

This was fixed in revisions 1644018 and 1645642.

This issue was identified by the Tomcat security team on 2 November 2014 and made public on 14 May 2015.

Affects: 8.0.0-RC1 to 8.0.15

Important: Request Smuggling CVE-2014-0227

It was possible to craft a malformed chunk as part of a chunked request that caused Tomcat to read part of the request body as a new request.

This was fixed in revisions 1600984, 1601329, 1601330 and 1601332.

This issue was identified by the Tomcat security team on 30 May 2014 and made public on 9 February 2015.

Affects: 8.0.0-RC1 to 8.0.8

Low: Denial of Service CVE-2014-0230

When a response for a request with a request body is returned to the user agent before the request body is fully read, by default Tomcat swallows the remaining request body so that the next request on the connection may be processed. There was no limit to the size of request body that Tomcat would swallow. This permitted a limited Denial of Service as Tomcat would never close the connection and a processing thread would remain allocated to the connection.

This was fixed in revision 1603770 and improved in revisions 1603775, 1603779, 1609175 and 1659294.

This issue was disclosed to the Tomcat security team by AntBean@secdig from the Baidu Security Team on 4 June 2014 and made public on 9 April 2015.

Affects: 8.0.0-RC1 to 8.0.8

Note: The issue below was fixed in Apache Tomcat 8.0.6 but the release votes for the 8.0.6 and 8.0.7 release candidates did not pass. Therefore, although users must download 8.0.8 to obtain a version that includes a fix for this issue, versions 8.0.6 and 8.0.7 are not included in the list of affected versions.

Low: Information Disclosure CVE-2014-0119

In limited circumstances it was possible for a malicious web application to replace the XML parsers used by Tomcat to process XSLTs for the default servlet, JSP documents, tag library descriptors (TLDs) and tag plugin configuration files. The injected XML parser(s) could then bypass the limits imposed on XML external entities and/or have visibility of the XML files processed for other web applications deployed on the same Tomcat instance.

This was fixed in revisions 1588193, 1589837, 1589980, 1589983, 1589985, 1589990 and 1589992.

This issue was identified by the Tomcat security team on 12 April 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.5

Note: The issues below were fixed in Apache Tomcat 8.0.4 but the release vote for the 8.0.4 release candidate did not pass. Therefore, although users must download 8.0.5 to obtain a version that includes fixes for these issues, version 8.0.4 is not included in the list of affected versions.

Important: Denial of Service CVE-2014-0075

It was possible to craft a malformed chunk size as part of a chucked request that enabled an unlimited amount of data to be streamed to the server, bypassing the various size limits enforced on a request. This enabled a denial of service attack.

This was fixed in revision 1578337.

This issue was reported to the Tomcat security team by David Jorm of the Red Hat Security Response Team on 28 February 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

Important: Denial of Service CVE-2014-0095

A regression was introduced in 1519838 that caused AJP requests to hang if an explicit content length of zero was set on the request. The hanging request consumed a request processing thread which could lead to a denial of service.

This was fixed in revision 1578392.

This issue was reported as a possible bug via the Tomcat users mailing list on 3 March 2014 and the security implications were identified by the Tomcat security team on the same day. This issue was made public on 27 May 2014.

Affects: 8.0.0-RC2 to 8.0.3

Important: Information disclosure CVE-2014-0096

The default servlet allows web applications to define (at multiple levels) an XSLT to be used to format a directory listing. When running under a security manager, the processing of these was not subject to the same constraints as the web application. This enabled a malicious web application to bypass the file access constraints imposed by the security manager via the use of external XML entities.

This was fixed in revisions 1578610 and 1578611.

This issue was identified by the Tomcat security team on 27 February 2014 and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

Important: Information disclosure CVE-2014-0099

The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header.

This was fixed in revision 1578812.

A test case that demonstrated the parsing bug was sent to the Tomcat security team on 13 March 2014 but no context was provided. The security implications were identified by the Tomcat security team the day the report was received and made public on 27 May 2014.

Affects: 8.0.0-RC1 to 8.0.3

Note: The issue below was fixed in Apache Tomcat 8.0.2 but the release vote for the 8.0.2 release candidates did not pass. Therefore, although users must download 8.0.3 to obtain a version that includes a fix for this issue, version 8.0.2 is not included in the list of affected versions.

Important: Denial of Service CVE-2014-0050

It was possible to craft a malformed Content-Type header for a multipart request that caused Apache Tomcat to enter an infinite loop. A malicious user could, therefore, craft a malformed request that triggered a denial of service.

The root cause of this error was a bug in Apache Commons FileUpload. Tomcat 8 uses a packaged renamed copy of Apache Commons FileUpload to implement the requirement of the Servlet 3.0 and later specifications to support the processing of mime-multipart requests. Tomcat 8 was therefore affected by this issue.

This was fixed in revision 1565163.

This issue was reported to the Apache Software Foundation on 04 Feb 2014 and accidently made public on 06 Feb 2014.

Affects: 8.0.0-RC1 to 8.0.1

Note: The issue below was fixed in Apache Tomcat 8.0.0-RC6 but the release votes for 8.0.0-RC6 to 8.0.0-RC9 did not pass. Therefore, although users must download 8.0.0-RC10 to obtain a version that includes a fix for this issue, versions 8.0.0-RC6 to 8.0.0-RC9 are not included in the list of affected versions.

Important: Denial of service CVE-2013-4322

The fix for CVE-2012-3544 was not complete. It did not cover the following cases:

• chunk extensions were not limited
• whitespace after the : in a trailing header was not limited

This was fixed in revisions 1521834 and 1549522.

The first part of this issue was identified by the Apache Tomcat security team on 27 August 2013 and the second part by Saran Neti of TELUS Security Labs on 5 November 2013. It was made public on 25 February 2014.

Affects: 8.0.0-RC1 to 8.0.0-RC5

Low: Information disclosure CVE-2013-4590

Application provided XML files such as web.xml, context.xml, *.tld, *.tagx and *.jspx allowed XXE which could be used to expose Tomcat internals to an attacker. This vulnerability only occurs when Tomcat is running web applications from untrusted sources such as in a shared hosting environment.

This was fixed in revision 1549528.

This issue was identified by the Apache Tomcat security team on 29 October 2013 and made public on 25 February 2014.

Affects: 8.0.0-RC1 to 8.0.0-RC5

Note: The issue below was fixed in Apache Tomcat 8.0.0-RC2 but the release vote for 8.0.0-RC2 did not pass. Therefore, although users must download 8.0.0-RC3 to obtain a version that includes a fix for this issue, version 8.0.0-RC2 is not included in the list of affected versions.

Important: Information disclosure CVE-2013-4286

The fix for CVE-2005-2090 was not complete. It did not cover the following cases:

• content-length header with chunked encoding over any HTTP connector
• multiple content-length headers over any AJP connector

Requests with multiple content-length headers or with a content-length header when chunked encoding is being used should be rejected as invalid. When multiple components (firewalls, caches, proxies and Tomcat) process a sequence of requests where one or more requests contain either multiple content-length headers or a content-length header when chunked encoding is being used and several components do not reject the request and make different decisions as to which content-length header to use an attacker can poison a web-cache, perform an XSS attack and obtain sensitive information from requests other then their own. Tomcat now rejects requests with multiple content-length headers or with a content-length header when chunked encoding is being used.

This was fixed in revision 1521829.

This issue was identified by the Apache Tomcat security team on 15 August 2013 and made public on 25 February 2014.

Affects: 8.0.0-RC1

Important: Denial of Service CVE-2017-6056

In February 2015 a single user reported high CPU usage (57544) which was traced to a tight loop. However, it was not clear how the conditions necessary to enter the loop were being created. There was no evidence that indicated that the loop was user triggerable. The only potential paths identified by code inspection depended on application bugs (retaining references to request objects and accessing after the request had completed).

It was (and still is) believed that an application bug was the most likely root cause. Therefore, 57544 was not treated as a DoS vulnerability.

In November 2016, CVE-2016-6816 was announced. When downstream distributions, notably Debian, back-ported the fix for CVE-2016-6816 they inadvertently make it trivial for users to trigger the tight loop from 57544. This made a DoS attack trivial to mount and resulted in multiple reports of problems including 60578 and 60581.

Tomcat releases from the Apache Software Foundation were not affected as the ASF did not release any versions that contained the fix for CVE-2016-6816 but not the fix for 57544.

This issue was first announced on 13 February 2017.

Affects: Debian, Ubuntu and potentially other downstream distributions.

Important: Remote Memory Read CVE-2014-0160 (a.k.a. "Heartbleed")

A bug in certain versions of OpenSSL can allow an unauthenticated remote user to read certain contents of the server's memory. Binary versions of tcnative 1.1.24 - 1.1.29 include this vulnerable version of OpenSSL. tcnative 1.1.30 and later ship with patched versions of OpenSSL.

This issue was first announced on 7 April 2014.

Affects: OpenSSL 1.0.1-1.0.1f, tcnative 1.1.24-1.1.29

Critical: Remote Code Execution via log4j CVE-2021-44228

Apache Tomcat 8.5.x has no dependency on any version of log4j.

Web applications deployed on Apache Tomcat may have a dependency on log4j. You should seek support from the application vendor in this instance.

It is possible to configure Apache Tomcat 8.5.x to use log4j 2.x for Tomcat's internal logging. This requires explicit configuration and the addition of the log4j 2.x library. Anyone who has switched Tomcat's internal logging to log4j 2.x is likely to need to address this vulnerability.

The first few releases of 8.5.x (8.5.3 and earlier) provided optional support for switching Tomcat's internal logging to log4j 1.x. Anyone one using these very old (5+ years), unsupported versions of Tomcat that switched to using log4j 1.x may need to address this vulnerability as log4j 1.x may be affected in some (probably rarely used) configurations. Regardless, they'll need to address the Tomcat vulnerabilities that have been made public in those 5+ years

In most cases, disabling the problematic feature will be the simplest solution. Exactly how to do that depends on the exact version of log4j 2.x being used. Details are provided on the log4j 2.x security page.