Google Git
Sign in
apache/tomcat-site/refs/heads/trunk/./docs/security-9.html
blob: 0f5efb199d1cf566f85a3f05b86dda275ed7332c [file]
<!DOCTYPE html SYSTEM "about:legacy-compat">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link href="res/css/tomcat.css" rel="stylesheet" type="text/css"><link href="res/css/fonts/fonts.css" rel="stylesheet" type="text/css"><title>Apache Tomcat&reg; - Apache Tomcat 9 vulnerabilities</title><meta name="author" content="Apache Tomcat Project"><script src="https://www.apachecon.com/event-images/snippet.js"></script></head><body><div id="wrapper"><header id="header"><div class="clearfix"><div class="menu-toggler pull-left" tabindex="1"><div class="hamburger"></div></div><a href="http://tomcat.apache.org/"><img class="tomcat-logo pull-left noPrint" alt="Tomcat Home" src="res/images/tomcat.png"></a><h1 class="pull-left">Apache Tomcat<sup>&reg;</sup></h1><div class="asf-logos pull-right"><a href="https://www.apache.org/foundation/contributing.html" target="_blank" class="pull-left"><img src="https://www.apache.org/images/SupportApache-small.png" class="support-asf" alt="Support Apache"></a><a href="http://www.apache.org/" target="_blank" class="pull-left"><img src="res/images/asf_logo_wide.svg" class="asf-logo" alt="The Apache Software Foundation"></a></div></div></header><main id="middle"><div><div id="mainLeft"><div id="nav-wrapper"><form action="https://www.google.com/search" method="get"><div class="searchbox"><input value="tomcat.apache.org" name="sitesearch" type="hidden"><input aria-label="Search text" placeholder="Search&hellip;" required="required" name="q" id="query" type="search"><button>GO</button></div></form><div class="asfevents"><a class="acevent" data-format="square" data-width="150"></a></div><nav><div><h2>Apache Tomcat</h2><ul><li><a href="./index.html">Home</a></li><li><a href="./taglibs.html">Taglibs</a></li><li><a href="./maven-plugin.html">Maven Plugin</a></li></ul></div><div><h2>Download</h2><ul><li><a href="./whichversion.html">Which version?</a></li><li><a href="https://tomcat.apache.org/download-11.cgi">Tomcat 11</a></li><li><a href="https://tomcat.apache.org/download-10.cgi">Tomcat 10</a></li><li><a href="https://tomcat.apache.org/download-90.cgi">Tomcat 9</a></li><li><a href="https://tomcat.apache.org/download-migration.cgi">Tomcat Migration Tool for Jakarta EE</a></li><li><a href="https://tomcat.apache.org/download-connectors.cgi">Tomcat Connectors</a></li><li><a href="https://tomcat.apache.org/download-native.cgi">Tomcat Native</a></li><li><a href="https://tomcat.apache.org/download-taglibs.cgi">Taglibs</a></li><li><a href="https://archive.apache.org/dist/tomcat/">Archives</a></li></ul></div><div><h2>Documentation</h2><ul><li><a href="./tomcat-11.0-doc/index.html">Tomcat 11.0</a></li><li><a href="./tomcat-10.1-doc/index.html">Tomcat 10.1</a></li><li><a href="./tomcat-9.0-doc/index.html">Tomcat 9.0</a></li><li><a href="./upgrading.html">Upgrading</a></li><li><a href="./connectors-doc/index.html">Tomcat Connectors</a></li><li><a href="./native-doc/index.html">Tomcat Native 2</a></li><li><a href="./native-1.3-doc/index.html">Tomcat Native 1.3</a></li><li><a href="https://cwiki.apache.org/confluence/display/TOMCAT">Wiki</a></li><li><a href="./migration.html">Migration Guide</a></li><li><a href="./presentations.html">Presentations</a></li><li><a href="https://cwiki.apache.org/confluence/x/Bi8lBg">Specifications</a></li></ul></div><div><h2>Problems?</h2><ul><li><a href="./security.html">Security Reports</a></li><li><a href="./findhelp.html">Find help</a></li><li><a href="https://cwiki.apache.org/confluence/display/TOMCAT/FAQ">FAQ</a></li><li><a href="./lists.html">Mailing Lists</a></li><li><a href="./bugreport.html">Bug Database</a></li></ul></div><div><h2>Get Involved</h2><ul><li><a href="./getinvolved.html">Overview</a></li><li><a href="./source.html">Source code</a></li><li><a href="./ci.html">Buildbot</a></li><li><a href="./tools.html">Tools</a></li></ul></div><div><h2>Media</h2><ul><li><a href="https://www.youtube.com/c/ApacheTomcatOfficial">YouTube</a></li></ul></div><div><h2>Misc</h2><ul><li><a href="./whoweare.html">Who We Are</a></li><li><a href="https://www.redbubble.com/people/comdev/works/30885254-apache-tomcat">Swag</a></li><li><a href="./heritage.html">Heritage</a></li><li><a href="http://www.apache.org">Apache Home</a></li><li><a href="./resources.html">Resources</a></li><li><a href="./contact.html">Contact</a></li><li><a href="./legal.html">Legal</a></li><li><a href="https://privacy.apache.org/policies/privacy-policy-public.html">Privacy</a></li><li><a href="https://www.apache.org/foundation/contributing.html">Support Apache</a></li><li><a href="https://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li><li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li><li><a href="http://www.apache.org/licenses/">License</a></li></ul></div></nav></div></div><div id="mainRight"><div id="content"><h2 style="display: none;">Content</h2><h3 id="Apache_Tomcat_9.x_vulnerabilities">Apache Tomcat 9.x vulnerabilities</h3><div class="text">
<p>This page lists all security vulnerabilities fixed in released versions
of Apache Tomcat<sup>&reg;</sup> 9.x. Each vulnerability is given a
<a href="security-impact.html">security impact rating</a> by the Apache
Tomcat security team &mdash; 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.</p>
<p><strong>Note:</strong> 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.</p>
<p>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 9.0 those are
<a href="/tomcat-9.0-doc/building.html"><code>building.html</code></a> and
<a href="/tomcat-9.0-doc/BUILDING.txt"><code>BUILDING.txt</code></a>.
Both files can be found in the <code>webapps/docs</code> subdirectory
of a binary distribution. You may also want to review the
<a href="/tomcat-9.0-doc/security-howto.html">Security Considerations</a>
page in the documentation.</p>
<p>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
<a href="lists.html">Tomcat Users mailing list</a>
</p>
<p>If you have encountered an unlisted security vulnerability or other
unexpected behaviour that has <a href="security-impact.html">security
impact</a>, or if the descriptions here are incomplete,
please report them privately to the
<a href="security.html">Tomcat Security Team</a>. Thank you.
</p>
</div><h3 id="Table_of_Contents">Table of Contents</h3><div class="text">
<ul><li><a href="#Fixed_in_Apache_Tomcat_9.0.121">Fixed in Apache Tomcat 9.0.121</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.120">Fixed in Apache Tomcat 9.0.120</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.119">Fixed in Apache Tomcat 9.0.119</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.118">Fixed in Apache Tomcat 9.0.118</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.117">Fixed in Apache Tomcat 9.0.117</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.116">Fixed in Apache Tomcat 9.0.116</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.115">Fixed in Apache Tomcat 9.0.115</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.113">Fixed in Apache Tomcat 9.0.113</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.110">Fixed in Apache Tomcat 9.0.110</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.109">Fixed in Apache Tomcat 9.0.109</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.108">Fixed in Apache Tomcat 9.0.108</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.107">Fixed in Apache Tomcat 9.0.107</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.106">Fixed in Apache Tomcat 9.0.106</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.105">Fixed in Apache Tomcat 9.0.105</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.104">Fixed in Apache Tomcat 9.0.104</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.102">Fixed in Apache Tomcat 9.0.102</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.99">Fixed in Apache Tomcat 9.0.99</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.98">Fixed in Apache Tomcat 9.0.98</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.97">Fixed in Apache Tomcat 9.0.97</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.96">Fixed in Apache Tomcat 9.0.96</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.90">Fixed in Apache Tomcat 9.0.90</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.86">Fixed in Apache Tomcat 9.0.86</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.83">Fixed in Apache Tomcat 9.0.83</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.81">Fixed in Apache Tomcat 9.0.81</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.80">Fixed in Apache Tomcat 9.0.80</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.75">Fixed in Apache Tomcat 9.0.75</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.74">Fixed in Apache Tomcat 9.0.74</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.72">Fixed in Apache Tomcat 9.0.72</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.71">Fixed in Apache Tomcat 9.0.71</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.69">Fixed in Apache Tomcat 9.0.69</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.68">Fixed in Apache Tomcat 9.0.68</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.65">Fixed in Apache Tomcat 9.0.65</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.63">Fixed in Apache Tomcat 9.0.63</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.62">Fixed in Apache Tomcat 9.0.62</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.58">Fixed in Apache Tomcat 9.0.58</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.54">Fixed in Apache Tomcat 9.0.54</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.48">Fixed in Apache Tomcat 9.0.48</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.46">Fixed in Apache Tomcat 9.0.46</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.45">Fixed in Apache Tomcat 9.0.45</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.44">Fixed in Apache Tomcat 9.0.44</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.43">Fixed in Apache Tomcat 9.0.43</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.40">Fixed in Apache Tomcat 9.0.40</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.38">Fixed in Apache Tomcat 9.0.38</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.37">Fixed in Apache Tomcat 9.0.37</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.36">Fixed in Apache Tomcat 9.0.36</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.35">Fixed in Apache Tomcat 9.0.35</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.31">Fixed in Apache Tomcat 9.0.31</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.30">Fixed in Apache Tomcat 9.0.30</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.29">Fixed in Apache Tomcat 9.0.29</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.21">Fixed in Apache Tomcat 9.0.21</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.20">Fixed in Apache Tomcat 9.0.20</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.19">Fixed in Apache Tomcat 9.0.19</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.16">Fixed in Apache Tomcat 9.0.16</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.12">Fixed in Apache Tomcat 9.0.12</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.10">Fixed in Apache Tomcat 9.0.10</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.9">Fixed in Apache Tomcat 9.0.9</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.8">Fixed in Apache Tomcat 9.0.8</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.5">Fixed in Apache Tomcat 9.0.5</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.2">Fixed in Apache Tomcat 9.0.2</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.1">Fixed in Apache Tomcat 9.0.1</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M22">Fixed in Apache Tomcat 9.0.0.M22</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M21">Fixed in Apache Tomcat 9.0.0.M21</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M19">Fixed in Apache Tomcat 9.0.0.M19</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M18">Fixed in Apache Tomcat 9.0.0.M18</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M17">Fixed in Apache Tomcat 9.0.0.M17</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M15">Fixed in Apache Tomcat 9.0.0.M15</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M13">Fixed in Apache Tomcat 9.0.0.M13</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M10">Fixed in Apache Tomcat 9.0.0.M10</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M8">Fixed in Apache Tomcat 9.0.0.M8</a></li><li><a href="#Fixed_in_Apache_Tomcat_9.0.0.M3">Fixed in Apache Tomcat 9.0.0.M3</a></li><li><a href="#Not_a_vulnerability_in_Tomcat">Not a vulnerability in Tomcat</a></li></ul>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.121"><span class="pull-right">not yet released</span> Fixed in Apache Tomcat 9.0.121</h3><div class="text">
<p><strong>Low: DoS in WebSocket chat example</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-66299" rel="nofollow">CVE-2026-66299</a></p>
<p>The WebSocket chat example provided an unbounded buffer for undelivered
messages. A maliciously slow client could cause the buffer to grow
continuously, eventually leading to an memory exhaustion and failure of
the Tomcat process.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/f6dda658e4eda2190de96219c182b9a75d27ab06">f6dda658</a>.</p>
<p>This issue was reported to the Tomcat security team on 13 July 2026.
The issue was made public on 28 July 2026.</p>
<p>Affects: 9.0.89 to 9.0.120<br>
Users who followed the security guidance to remove the examples web
application are not affected.</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.120"><span class="pull-right">2026-07-07</span> Fixed in Apache Tomcat 9.0.120</h3><div class="text">
<p><strong>Low: EncryptInterceptor requirements not clearly
documented</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-59084" rel="nofollow">CVE-2026-59084</a></p>
<p>The requirements to securely configure the EncryptInterceptor were not
clearly documented.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/617d7275782bf58b45f6b7ea82c2edf16660e0b3">617d7275</a>.</p>
<p>This issue was reported to the Tomcat security team on 29 June 2026.
The issue was made public on 14 July 2026.</p>
<p>Affects: 9.0.13 to 9.0.119</p>
<p><strong>Low: Incorrect URL decoding in RewriteValve may allow security
control bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-59083" rel="nofollow">CVE-2026-59083</a></p>
<p>Incorrect decoding of <code>+</code> in rewritten URIs to a single space
could allow security control bypass for some configurations.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/a520aecb325e2279f2bf3a7a090ca7f61ed1c7af">a520aecb</a>.</p>
<p>This issue was identified by the Tomcat security team on 26 June 2026.
The issue was made public on 14 July 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.119</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.119"><span class="pull-right">2026-06-23</span> Fixed in Apache Tomcat 9.0.119</h3><div class="text">
<p><strong>Moderate: Security constraints for default servlet ignored
method</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-55956" rel="nofollow">CVE-2026-55956</a></p>
<p>If security constraints were specified for the default servlet, any
method or method omission configured as part of the constraint was
ignored.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/a0374c450970760efafbd8806a1db278830ba7bd">a0374c45</a>.</p>
<p>This issue was reported to the Tomcat security team on 15 June 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.118</p>
<p><strong>Low: EncryptInterceptor not protected against replay
attacks</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-55955" rel="nofollow">CVE-2026-55955</a></p>
<p>Contrary to the documentation, the EncryptInterceptor was not protected
against replay attacks.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/6a7a432cd7fb4ef358dc12e8da99cf3ab320f3fe">6a7a432c</a>.</p>
<p>This issue was reported to the Tomcat security team on 17 June 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.13 to 9.0.118</p>
<p><strong>Low: Logged effective web.xml is incomplete</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-55276" rel="nofollow">CVE-2026-55276</a></p>
<p>Logic errors in the effective web.xml generation meant that neither
special roles nor empty authorization constraints were included in the
logged effective web.xml.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/3ca8cae5fd3796b1bd9759e11b0e238161e7a39c">3ca8cae5</a>.</p>
<p>This issue was reported to the Tomcat security team on 16 June 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.118</p>
<p><strong>Low: Invalid CRL configuration doesn't trigger failure for FFM
Connector</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53434" rel="nofollow">CVE-2026-53434</a></p>
<p>If an FFM connector was configured with invalid CRLs, the invalid CRLs
were ignored meaning invalid certificates could be accepted.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/c48ac39c27f4494f8c96b9d56a487253e362d276">c48ac39c</a>.</p>
<p>This issue was reported to the Tomcat security team on 8 June 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.83 to 9.0.118</p>
<p><strong>Low: Bad ornext processing in RewriteValve</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-53404" rel="nofollow">CVE-2026-53404</a></p>
<p>If a request matched the first condition in an OR chain, subsequent
non-OR conditions were skipped and the rewrite succeeded.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/fe06ae8a71997061596f54189dae1b1b5da75430">fe06ae8a</a>.</p>
<p>This issue was reported to the Tomcat security team on 28 May 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.118</p>
<p><strong>Low: XSS in number guess example</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-50229" rel="nofollow">CVE-2026-50229</a></p>
<p>The use of wild card property mapping resulted in some properties, that
were intended to be internal only, being exposed to clients allowing an
XSS attack.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/de5a950415fc67713f17fab63d0c7809e0fca80b">de5a9504</a>.</p>
<p>This issue was reported to the Tomcat security team on 11 May 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.118</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.118"><span class="pull-right">2026-05-10</span> Fixed in Apache Tomcat 9.0.118</h3><div class="text">
<p><strong>Moderate: Security constraints not correctly applied</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43515" rel="nofollow">CVE-2026-43515</a></p>
<p>When multiple security constraints defined an HTTP method constraint for
the same extension pattern, only the first method constraint was
applied.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/db919ff9912b4d61d1b702a1342b8bde39270031">db919ff9</a>.</p>
<p>This issue was reported to the Tomcat security team on 20 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
<p><strong>Low: AJP secret compared in non-constant time</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43514" rel="nofollow">CVE-2026-43514</a></p>
<p>The AJP secret was compared in non-constant time allowing an attacker on
the local network to mount a timing attack to determine the AJP
secret.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/933dcdbf2515972280002929e7e597dead2e9ffa">933dcdbf</a> and
<a href="https://github.com/apache/tomcat/commit/2e676264ce27448a4d4841e42c1238bd10ca3755">2e676264</a>.</p>
<p>This issue was reported to the Tomcat security team on 20 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
<p><strong>Low: LockOutRealm treats user names as case-sensitive</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43513" rel="nofollow">CVE-2026-43513</a></p>
<p>The LockOut Realm treated user names as case sensitive meaning that, for
Realms where the user name was case insensitive, the LockOut Realm was
not as effective at blocking brute force attacks against a user's
password.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/6dd75beb55bd42fc5f78e929596b25018cd17717">6dd75beb</a>.</p>
<p>This issue was reported to the Tomcat security team on 20 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
<p><strong>Moderate: Digest authenticator will authenticate any unknown user</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43512" rel="nofollow">CVE-2026-43512</a></p>
<p>When DIGEST authentication was configured, any user not known to the
configured Realm would be authenticated if they presented the password
"null".</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/6565a6cb6499e56fe2f34457cec99f9d1c4f39e9">6565a6cb</a>.</p>
<p>This issue was reported to the Tomcat security team on 20 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
<p><strong>Low: WebSocket authentication header exposure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-42498" rel="nofollow">CVE-2026-42498</a></p>
<p>If a WebSocket request was redirected after authentication, Tomcat's
WebSocket client would present the most recent authentication header to
the redirect target host.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/169d725788ea6aec217ecac70fe4161c837ba423">169d7257</a>.</p>
<p>This issue was reported to the Tomcat security team on 21 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.2 to 9.0.117</p>
<p><strong>Low: HTTP/2 request headers not validated</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-41293" rel="nofollow">CVE-2026-41293</a></p>
<p>HTTP/2 request headers were not validated which may have triggered
unexpected application behaviour if the application (quite reasonably)
assumed that header value exposed through the Servlet API would be
specification compliant.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/cf9452443bcbf3b1a4b435ef7d624364f1b65ca3">cf945244</a>,
<a href="https://github.com/apache/tomcat/commit/1c70480466572c9192ed412ebefcd43fc63137fd">1c704804</a> and
<a href="https://github.com/apache/tomcat/commit/57c2b3bfd62792631e1df24cf4237b990a0b36fa">57c2b3bf</a>.</p>
<p>This issue was reported to the Tomcat security team on 15 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
<p><strong>Low: Unbounded read in WebDAV LOCK and PROPFIND handling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-41284" rel="nofollow">CVE-2026-41284</a></p>
<p>No limit was enforced on the request body for WebDAV LOCK or PROPFIND
requests which were available to unauthenticated users.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/17dacd9aa48628da2eba37a9ab743c0b6c71685c">17dacd9a</a>.</p>
<p>This issue was reported to the Tomcat security team on 11 April 2026.
The issue was made public on 12 May 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.117</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.117"><span class="pull-right">2026-04-03</span> Fixed in Apache Tomcat 9.0.117</h3><div class="text">
<p><strong>Moderate: OCSP checks sometimes soft-fail with FFM even when
soft-fail is disabled</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34500" rel="nofollow">CVE-2026-34500</a></p>
<p>CLIENT_CERT authentication does not fail as expected for some scenarios
when soft fail is disabled and FFM is used.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/ff589ab26e8250a2ca4286d986305318c033ff9f">ff589ab2</a>.</p>
<p>This issue was reported to the Tomcat security team on 25 March 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.92 to 9.0.116</p>
<p><strong>Low: Cloud membership for clustering component exposed the
Kubernetes bearer token</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34487" rel="nofollow">CVE-2026-34487</a></p>
<p>The cloud membership for clustering component exposed the Kubernetes
bearer token in log messages.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/f593292a082e5ef9336a8db2b4b522f7f3e36976">f593292a</a>.</p>
<p>This issue was reported to the Tomcat security team on 25 March 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.13 to 9.0.116</p>
<p><strong>Important: The fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-29146" rel="nofollow">CVE-2026-29146</a> allowed the
bypass of the EncryptInterceptor</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34486" rel="nofollow">CVE-2026-34486</a></p>
<p>An error in the fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-29146" rel="nofollow">CVE-2026-29146</a> allowed the
EncryptInterceptor to be bypassed.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/776e12b3e2b0b4507b8a3b62c187ceb0b74bf418">776e12b3</a>.</p>
<p>This issue was reported to the Tomcat security team on 26 March 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.116</p>
<p><strong>Low: Incomplete escaping of JSON access logs</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34483" rel="nofollow">CVE-2026-34483</a></p>
<p>Incomplete escaping when non-default values were used for the Connector
attributes relaxedPathChars and/or relaxedQueryChars allowed the
injection of arbitrary JSON into the JSON access log.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/97566842589d0b80de138ca719378861fd017d68">97566842</a>.</p>
<p>This issue was reported to the Tomcat security team on 25 March 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.40 to 9.0.116</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.116"><span class="pull-right">2026-03-20</span> Fixed in Apache Tomcat 9.0.116</h3><div class="text">
<p><strong>Moderate: The fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-66614" rel="nofollow">CVE-2025-66614</a> was
incomplete</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-32990" rel="nofollow">CVE-2026-32990</a></p>
<p>The validation of SNI name and host name did not take account of possible
differences in case allowing the strict SNI checks to be bypassed.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/95f7778248cac46d03e6af04de9c72a598be3a53">95f77782</a>.</p>
<p>This issue was reported to the Tomcat security team on 13 March 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.113 to 9.0.115</p>
<p><strong>Important: EncryptInterceptor vulnerable to padding oracle attack
by default</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-29146" rel="nofollow">CVE-2026-29146</a></p>
<p>The EncryptInterceptor used CBC by default which is vulnerable to a
padding Oracle attack.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/0112ed22abfccc3d54e44d91eb08804d0886acd1">0112ed22</a>.</p>
<p>This issue was reported to the Tomcat security team on 22 February 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.13 to 9.0.115</p>
<p><strong>Moderate: OCSP checks sometimes soft-fail even when soft-fail is
disabled</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-29145" rel="nofollow">CVE-2026-29145</a></p>
<p>CLIENT_CERT authentication did not fail OCSP checks as expected for some
scenarios when soft fail was disabled.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/d1406df5ae0326f39f54c3f64ac30d8fca55cd5b">d1406df5</a>.</p>
<p>This issue was reported to the Tomcat security team on 26 February 2026.
The issue was made public on 9 April 2026.</p>
<p><strong>Low: Configured TLS cipher preference order not preserved</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-29129" rel="nofollow">CVE-2026-29129</a></p>
<p>The additional of the ability to configure TLS 1.3 cipher suites did not
preserve the order of the configured cipher suites and ciphers.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/6db238562ec36ab1106db4d04843f8b33e7a0c06">6db23856</a>.</p>
<p>This was reported as a bug on 20 February 026 and the security
implications identified by the Tomcat security team the same day.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.114 to 9.0.115</p>
<p><strong>Low: Occasionally open redirect</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-25854" rel="nofollow">CVE-2026-25854</a></p>
<p>When a Tomcat node in a cluster with the LoadBalancerDrainingValve was in
the disabled (draining) state, a specially crafted URL could be used to
trigger a redirect to a URI of the attackers choice.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/c5a45ae68d07f7a07be2a875e5b6772d66c4e5d0">c5a45ae6</a>.</p>
<p>This issue was reported to the Tomcat security team on 30 January 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.0.M23 to 9.0.115</p>
<p><strong>Low: Request smuggling via invalid chunk extension</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-24880" rel="nofollow">CVE-2026-24880</a></p>
<p>Tomcat did not validate that contents of HTTP/1.1 chunk extensions. This
enabled a request smuggling attack if a reverse proxy in front of Tomcat
allowed CRLF sequences in an otherwise valid chunk extension.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/1b586d6aa8ae65726da5fa8799427b5d4718478a">1b586d6a</a> and
<a href="https://github.com/apache/tomcat/commit/6d478dbe18b7c4bb671c30fedf130309b0dab77c">6d478dbe</a>.</p>
<p>This issue was reported to the Tomcat security team on 19 January 2026.
The issue was made public on 9 April 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.115</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.115"><span class="pull-right">2026-01-23</span> Fixed in Apache Tomcat 9.0.115</h3><div class="text">
<p><strong>Moderate: Incomplete OCSP verification checks</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-24734" rel="nofollow">CVE-2026-24734</a></p>
<p>When using an OCSP responder, Tomcat's FFM integration with OpenSSL did
not complete verification or freshness checks on the OCSP response which
could allow certificate revocation to be bypassed.</p>
<p>Affects: 9.0.83 to 9.0.114</p>
<p>This issue was reported to the Tomcat security team on 2 November 2025.
The issue was made public on 17 February 2026.</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.113"><span class="pull-right">2025-12-07</span> Fixed in Apache Tomcat 9.0.113</h3><div class="text">
<p><strong>Low: Security constraint bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-24733" rel="nofollow">CVE-2026-24733</a></p>
<p>Tomcat did not limit HTTP/0.9 requests to the GET method. If a security
constraint was configured to allow HEAD requests to a URI but deny GET
requests, the user could bypass that constraint on GET requests by
sending a (specification invalid) HEAD request using HTTP/0.9.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/2e2fa23f2635bbb819759576a2f2f5e64ecf7c5f">2e2fa23f</a>.</p>
<p>This issue was identified by the Tomcat security team on 26 November
2025. The issue was made public on 17 February 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.112</p>
<p><strong>Moderate: Client certificate verification bypass due to virtual
host mapping</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-66614" rel="nofollow">CVE-2025-66614</a></p>
<p>Tomcat did not validate that the host name provided via the SNI extension
was the same as the host name provided in the HTTP host header field. If
Tomcat was configured with more than one virtual host and the TLS
configuration for one of those hosts did not require client certificate
authentication but another one did, it was possible for a client to
bypass the client certificate authentication by sending different host
names in the SNI extension and the HTTP host header field.</p>
<p>The vulnerability only applies if client certificate authentication is
only enforced at the Connector. It does not apply if client certificate
authentication is enforced at the web application.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/152c14885d45f5e0a8b59bd9f93c289cfe20ce30">152c1488</a>,
<a href="https://github.com/apache/tomcat/commit/a4aa74232e826028cd2f7ba0445caf8a8b52c509">a4aa7423</a> and
<a href="https://github.com/apache/tomcat/commit/9276b5e783c8cd5b3fe2bb716306b65004bdd940">9276b5e7</a>.</p>
<p>This issue was reported to the Tomcat security team on 15 October 2025.
The issue was made public on 17 February 2026.</p>
<p>Affects: 9.0.0.M1 to 9.0.112</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.110"><span class="pull-right">2025-10-06</span> Fixed in Apache Tomcat 9.0.110</h3><div class="text">
<p><strong>Low: Delayed cleaning of multipart upload temporary files may
lead to DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-61795" rel="nofollow">CVE-2025-61795</a></p>
<p>If an error occurred (including exceeding limits) during the processing
of a multipart upload, temporary copies of the uploaded parts written to
local storage were not cleaned up immediately but left for the garbage
collection process to delete. Depending on JVM settings, application
memory usage and application load, it was possible that space for the
temporary copies of uploaded parts would be filled faster than GC cleared
it, leading to a DoS.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/afa422bd7ca1eef0f507259c682fd876494d9c3b">afa422bd</a>.</p>
<p>This issue was reported to the Tomcat security team on 7 September 2025.
The issue was made public on 27 October 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.109</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.109"><span class="pull-right">2025-09-05</span> Fixed in Apache Tomcat 9.0.109</h3><div class="text">
<p><strong>Low: Console manipulation via escape sequences in log
messages</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-55754" rel="nofollow">CVE-2025-55754</a></p>
<p>Tomcat did not escape ANSI escape sequences in log messages. If Tomcat
was running in a console on a Windows operating system, and the console
supported ANSI escape sequences, it was possible for an attacker to use a
specially crafted URL to inject ANSI escape sequences to manipulate the
console and the clipboard and attempt to trick an administrator into
running an attacker controlled command. While no attack vector was found,
it may have been possible to mount this attack on other operating
systems.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/a03cabf3a36a42d27d8d997ed31f034f50ba6cd5">a03cabf3</a>.</p>
<p>This issue was reported to the Tomcat security team on 5 August 2025. The
issue was made public on 27 October 2025.</p>
<p>Affects: 9.0.40 to 9.0.108</p>
<p><strong>Important: Directory traversal via Rewrite Valve with possible
remote code execution if PUT is enabled</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-55752" rel="nofollow">CVE-2025-55752</a></p>
<p>The fix for bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=60013">60013</a> introduced a regression where the
rewritten URL was normalized before it was decoded. This introduced the
possibility that, for rewrite rules that rewrite query parameters to the
URL, an attacker could manipulate the request URI to bypass security
constraints including the protection for <code>/WEB-INF/</code> and
<code>/META-INF/</code>. If PUT requests were also enabled then malicious
files could be uploaded leading to remote code execution. PUT requests
are normally limited to trusted users and it is considered unlikely that
PUT requests would be enabled in conjunction with a rewrite that
manipulated the URI.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/b5042622b8b78340ae65403c55dcb9c7416924df">b5042622</a>.</p>
<p>This issue was reported to the Tomcat security team on 11 August 2025.
The issue was made public on 27 October 2025.</p>
<p>Affects: 9.0.0.M11 to 9.0.108</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.108"><span class="pull-right">2025-08-06</span> Fixed in Apache Tomcat 9.0.108</h3><div class="text">
<p><strong>Important: DoS in HTTP/2 due to client triggered stream
reset</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48989" rel="nofollow">CVE-2025-48989</a></p>
<p>Tomcat's HTTP/2 implementation was vulnerable to the made you reset
attack. The denial of service typically manifested as an
<code>OutOfMemoryError</code>.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/f36b8a4eea4ce8a0bc035079e1d259d29f5eb7bf">f36b8a4e</a>.</p>
<p>This issue was reported to the ASF security team on 29 May 2025. The
issue was made public on 13 August 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.107</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.107"><span class="pull-right">2025-07-04</span> Fixed in Apache Tomcat 9.0.107</h3><div class="text">
<p><strong>Important: APR/Native Connector crash leading to DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-52434" rel="nofollow">CVE-2025-52434</a></p>
<p>A race condition on connection close could trigger a JVM crash when using
the APR/Native connector leading to a DoS. This was particularly
noticeable with client initiated closes of HTTP/2 connections.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/8a83c3c42d20762782678932c14005cd3397a018">8a83c3c4</a>.</p>
<p>This issue was reported to the Tomcat security team on 6 June 2025. The
issue was made public on 10 July 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.106</p>
<p><strong>Low: DoS due to overflow in file upload limit</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-52520" rel="nofollow">CVE-2025-52520</a></p>
<p>For some unlikely configurations of multipart upload, an Integer Overflow
vulnerability could lead to a DoS via bypassing of size limits.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/927d66fbc294cb65242102b817a45fd80834e040">927d66fb</a>.</p>
<p>This issue was reported to the Tomcat security team on 7 June 2025. The
issue was made public on 10 July 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.106</p>
<p><strong>Important: DoS via excessive HTTP/2 streams</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-53506" rel="nofollow">CVE-2025-53506</a></p>
<p>An uncontrolled resource consumption vulnerability if an HTTP/2 client
did not acknowledge the initial settings frame that reduces the maximum
permitted concurrent streams could result in a DoS.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/434772930f362145516dd60681134e7f0cf8115b">43477293</a>.</p>
<p>This issue was reported to the Tomcat security team on 28 June 2025. The
issue was made public on 10 July 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.106</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.106"><span class="pull-right">2025-06-10</span> Fixed in Apache Tomcat 9.0.106</h3><div class="text">
<p><strong>Moderate: Session fixation possible via rewrite valve</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-55668" rel="nofollow">CVE-2025-55668</a></p>
<p>If the rewrite valve was enabled for a web application, an attacker was
able to craft a URL that, if a victim clicked on it, would cause the
victim's interaction with that resource to occur in the context of the
attacker's session.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/9c3673ba04009377cb0c81ccb6cf5078aec1aa95">9c3673ba</a>.</p>
<p>This issue was reported to the Tomcat security team on 30 May 2025. The
issue was made public on 13 August 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.105</p>
<p><strong>Moderate: Security constraint bypass for PreResources and
PostResources</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-49125" rel="nofollow">CVE-2025-49125</a></p>
<p>When using PreResources or PostResources mounted other than at the root
of the web application, it was possible to access those resources via an
unexpected path. That path was likely not to be protected by the same
security constraints as the expected path, allowing those security
constraints to be bypassed.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/9418e3ff9f1f4c006b4661311ae9376c52d162b9">9418e3ff</a>.</p>
<p>This issue was reported to the Tomcat security team on 30 May 2025. The
issue was made public on 16 June 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.105</p>
<p><strong>Low: Side-loading via Tomcat installer for Windows</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-49124" rel="nofollow">CVE-2025-49124</a></p>
<p>During installation, the Tomcat installer for Windows used icacls.exe
without specifying a full path. This enabled a side-loading
vulnerability.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/28726cc2e63bed68771f5eb0f65a78dc7080571823">28726cc2</a>.</p>
<p>This issue was reported to the Tomcat security team on 30 May 2025. The
issue was made public on 16 June 2025.</p>
<p>Affects: 9.0.23 to 9.0.105</p>
<p><strong>Important: DoS in multipart upload</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48988" rel="nofollow">CVE-2025-48988</a></p>
<p>Tomcat used the same limit for both request parameters and parts in a
multipart request. Since uploaded parts also include headers which must
be retained, processing multipart requests can result in significantly
more memory usage. A specially crafted request that used a large number
of parts could trigger excessive memory usage leading to a DoS. The
maximum number of parts is now configurable (maxPartCount on the
Connector) with a default of 10 parts.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/ee8042ffce4cb9324dfd79efda5984f37bbb6910">ee8042ff</a>.</p>
<p>This issue was reported to the ASF security team on 16 May 2025. The
issue was made public on 16 June 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.105</p>
<p><strong>Important: DoS in Commons FileUpload</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48976" rel="nofollow">CVE-2025-48976</a></p>
<p>Apache Commons FileUpload provided a hard-coded limit of 10kB for the
size of the headers associated with a multipart request. A specially
crafted request that used a large number of parts with large headers
could trigger excessive memory usage leading to a DoS. This limit is
now configurable (maxPartHeaderSize on the Connector) with a default of
512 bytes.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/97790a35a27d236fa053e660676c3f8196284d93">97790a35</a>.</p>
<p>This issue was reported to the ASF security team on 16 May 2025. The
issue was made public on 16 June 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.105</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.105"><span class="pull-right">2025-05-12</span> Fixed in Apache Tomcat 9.0.105</h3><div class="text">
<p><strong>Low: CGI security constraint bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-46701" rel="nofollow">CVE-2025-46701</a></p>
<p>When running on a case insensitive file system with security constraints
configured for the <code>pathInfo</code> component of a URL that mapped
to the CGI servlet, it was possible to bypass those security constraints
with a specially crafted URL.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/8df00018a252baa9497615d6420fb6c10466fa74">8df00018</a> and
<a href="https://github.com/apache/tomcat/commit/8cb95ff03221067c511b3fa66d4f745bc4b0a605">8cb95ff0</a>.</p>
<p>This issue was reported to the Tomcat security team on 7 April 2025. The
issue was made public on 29 May 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.104</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.104"><span class="pull-right">2025-04-08</span> Fixed in Apache Tomcat 9.0.104</h3><div class="text">
<p><i>Note: The issues below were fixed in Apache Tomcat 9.0.103 but the
release vote for the 9.0.103 release candidate did not pass. Therefore,
although users must download 9.0.104 to obtain a version that includes a
fix for these issues, version 9.0.103 is not included in the list of
affected versions.</i></p>
<p><strong>Low: Rewrite rule bypass</strong> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-31651" rel="nofollow">CVE-2025-31651</a></p>
<p>For a subset of unlikely rewrite rule configurations, it was possible for
a specially crafted request to bypass some rewrite rules. If those
rewrite rules effectively enforced security constraints, those
constraints could be bypassed.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/ee3ab548e92345eca0cbd1f01649eb36c6f29454">ee3ab548</a> and
<a href="https://github.com/apache/tomcat/commit/175dc75fc428930034a6c93fb52f830d955d8e64">175dc75f</a>.</p>
<p>This issue was reported to the Tomcat security team on 28 February 2025.
The issue was made public on 28 April 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.102</p>
<p><strong>Important: Denial of Service via invalid HTTP priority
header</strong> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-31650" rel="nofollow">CVE-2025-31650</a></p>
<p>Incorrect error handling for some invalid HTTP priority headers resulted
in incomplete clean-up of the failed request which created a memory leak.
A large number of such requests could trigger an
OutOfMemoryException resulting in a denial of service.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/40ae788c2e64d018b4e58cd4210bb96434d0100d">40ae788c</a>,
<a href="https://github.com/apache/tomcat/commit/b98e74f517b36929f4208506e5adad22cb767baa">b98e74f5</a> and
<a href="https://github.com/apache/tomcat/commit/b7674782679e1514a0d154166b1d04d38aaac4a9">b7674782</a>.</p>
<p>This issue was not disclosed responsibly. It was reported via the public
bug tracker on 13 March 2025. The CVE was published on 28 April 2025.</p>
<p>Affects: 9.0.76 to 9.0.102</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.102"><span class="pull-right">2025-03-06</span> Fixed in Apache Tomcat 9.0.102</h3><div class="text">
<p><strong>Important: Authentication bypass with JNDIRealm and GSSAPI
authenticated bind</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-55957" rel="nofollow">CVE-2026-55957</a></p>
<p>When the JNDIRealm was configured to authenticate binds using GSSAPI, an
attacker was able authenticate without providing the correct
password.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/c32bbd37ea9ee0aaab848af4ee1c9a76e84240ea">c32bbd37</a>.</p>
<p>This issue was reported to the Tomcat security team on 14 June 2026.
The issue was made public on 29 June 2026.</p>
<p>Affects: 9.0.0-M1 to 9.0.100</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.99"><span class="pull-right">2025-02-10</span> Fixed in Apache Tomcat 9.0.99</h3><div class="text">
<p><strong>Important: Remote Code Execution and/or Information disclosure
and/or malicious content added to uploaded files via write enabled
Default Servlet - </strong> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-24813" rel="nofollow">CVE-2025-24813</a></p>
<p>The original implementation of partial PUT used a temporary file based on
the user provided file name and path with the path separator replaced by
".".</p>
<p>If all of the following were true, a malicious user was able to view
security sensitive files and/or inject content into those files:</p>
<ul>
<li>writes enabled for the default servlet (disabled by default)</li>
<li>support for partial PUT (enabled by default)</li>
<li>a target URL for security sensitive uploads that is a sub-directory of
a target URL for public uploads</li>
<li>attacker knowledge of the names of security sensitive files being
uploaded</li>
<li>the security sensitive files also being uploaded via partial PUT</li>
</ul>
<p>If all of the following were true, a malicious user was able to perform
remote code execution:</p>
<ul>
<li>writes enabled for the default servlet (disabled by default)</li>
<li>support for partial PUT (enabled by default)</li>
<li>application was using Tomcat's file based session persistence with the
default storage location</li>
<li>application included a library that may be leveraged in a
deserialization attack</li>
</ul>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/eb61aade8f8daccaecabf07d428b877975622f72">eb61aade</a>.</p>
<p>This issue was reported to the Tomcat security team on 13 January 2025.
The issue was made public on 10 March 2025.</p>
<p>Affects: 9.0.0.M1 to 9.0.98</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.98"><span class="pull-right">2024-12-09</span> Fixed in Apache Tomcat 9.0.98</h3><div class="text">
<p><strong>Important: Remote Code Execution via write enabled Default
Servlet. Mitigation for CVE-2024-50379 was incomplete - </strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56337" rel="nofollow">CVE-2024-56337</a></p>
<p>The previous mitigation for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50379" rel="nofollow">CVE-2024-50379</a> was incomplete. In
addition to upgrading to 9.0.98 or later, users running Tomcat on a case
insensitive file system with the default servlet write enabled may need
additional configuration depending on the version of Java being used:
<ul>
<li>running on Java 8 or Java 11: the system property
<code>sun.io.useCanonCaches</code> must be explicitly set to
<code>false</code> (it defaults to <code>true</code>)</li>
<li>running on Java 17: the&nbsp;system property
<code>sun.io.useCanonCaches</code>, if set, must be set to
<code>false</code>&nbsp;(it defaults to <code>false</code>)</li>
<li>running on Java 21 onwards: no further configuration is required&nbsp;(the
system property and the problematic cache have been removed)</li>
</ul></p>
<p>This issue was reported to the Tomcat security team on 17 December 2024.
The issue was made public on 20 December 2024.</p>
<p>Affects: 9.0.0.M1 to 9.0.97</p>
<p><strong>Low: DoS in examples web application</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-54677" rel="nofollow">CVE-2024-54677</a></p>
<p>Numerous examples in the examples web application did not place limits on
uploaded data enabling an OutOfMemoryError to be triggered causing a
denial of service.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/1d88dd3ffaed76188dd4ee32ce77709ce6e153cd">1d88dd3f</a>,
<a href="https://github.com/apache/tomcat/commit/721544ea28e92549824b106be954a9f411867a1c">721544ea</a>,
<a href="https://github.com/apache/tomcat/commit/84065e26ca4555e63a922bb29b13b0a1c86b7654">84065e26</a>,
<a href="https://github.com/apache/tomcat/commit/3315a9027a7eaab18f42625b97b569940ff1365d">3315a902</a>,
<a href="https://github.com/apache/tomcat/commit/c2f7ce21c3fb12caefee87c517a8bb4f80700044">c2f7ce21</a>,
<a href="https://github.com/apache/tomcat/commit/75ff7e8622edcc024b268677aa789ee8f0880ecc">75ff7e86</a>,
<a href="https://github.com/apache/tomcat/commit/4d5cc6538d91386f950373ac8120e98c2c78ed3a">4d5cc653</a>,
<a href="https://github.com/apache/tomcat/commit/84c4af76e7a10fc7f8630ce62e6a46632ea4a90e">84c4af76</a> and
<a href="https://github.com/apache/tomcat/commit/9ffd23fc27f5d1fc95bf97e5cea175c8968f4533">9ffd23fc</a>.</p>
<p>This issue was reported to the Tomcat security team on 23 November 2024.
The issue was made public on 17 December 2024.</p>
<p>Affects: 9.0.0.M1 to 9.0.97</p>
<p><strong>Important: Remote Code Execution via write enabled Default Servlet</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50379" rel="nofollow">CVE-2024-50379</a></p>
<p>If the default servlet is write enabled (<code>readonly</code>
initialisation parameter set to the non-default value of
<code>false</code>) for a case insensitive file system, concurrent read
and upload under load of the same file can bypass Tomcat's case
sensitivity checks and cause an uploaded file to be treated as a JSP
leading to remote code execution.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/43b507ebac9d268b1ea3d908e296cc6e46795c00">43b507eb</a> and
<a href="https://github.com/apache/tomcat/commit/631500b0c9b2a2a2abb707e3de2e10a5936e5d41">631500b0</a>.</p>
<p>This issue was reported to the Tomcat security team on 18 October 2024.
The issue was made public on 17 December 2024.</p>
<p>Affects: 9.0.0.M1 to 9.0.97</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.97"><span class="pull-right">2024-11-09</span> Fixed in Apache Tomcat 9.0.97</h3><div class="text">
<p><strong>Important: XSS in generated JSPs</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-52318" rel="nofollow">CVE-2024-52318</a></p>
<p>The fix for improvement <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=69333">69333</a> caused pooled JSP tags not to be
released after use which in turn could cause output of some tags not to
escaped as expected. This unescaped output could lead to XSS.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/9813c5dd3259183f659bbb83312a5cf673cc1ebf">9813c5dd</a>.</p>
<p>This issue was not disclosed responsibly. It was reported via the public
bug tracker on 6 November 2024. The CVE was published on 18 November
2024.</p>
<p>Affects: 9.0.96</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.96"><span class="pull-right">2024-10-09</span> Fixed in Apache Tomcat 9.0.96</h3><div class="text">
<p><strong>Important: Request and/or response mix-up</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-52317" rel="nofollow">CVE-2024-52317</a></p>
<p>Incorrect recycling of the request and response used by HTTP/2 requests
could lead to request and/or response mix-up between users.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/47307ee27abcdea2ee40e33897aca760083de46a">47307ee2</a>.</p>
<p>This issue was identified by the Tomcat Security Team on 1 October 2024.
The issue was made public on 18 November 2024.</p>
<p>Affects: 9.0.92 to 9.0.95</p>
<p><strong>Low: Authentication Bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-52316" rel="nofollow">CVE-2024-52316</a></p>
<p>If Tomcat was configured to use a custom Jakarta Authentication (formerly
JASPIC) ServerAuthContext component which may throw an exception during
the authentication process without explicitly setting an HTTP status to
indicate failure, the authentication may not have failed, allowing the
user to bypass the authentication process. There are no known Jakarta
Authentication components that behave in this way.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/7532f9dc4a8c37ec958f79dc82c4924a6c539223">7532f9dc</a>.</p>
<p>This issue was identified by the Tomcat Security Team on 19 September
2024. The issue was made public on 18 November 2024.</p>
<p>Affects: 9.0.0-M1 to 9.0.95</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.90"><span class="pull-right">2024-06-19</span> Fixed in Apache Tomcat 9.0.90</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-34750" rel="nofollow">CVE-2024-34750</a></p>
<p>When processing an HTTP/2 stream, Tomcat did not handle some cases of
excessive HTTP headers correctly. This led to a miscounting of active
HTTP/2 streams which in turn led to the use of an incorrect infinite
timeout which allowed connections to remain open which should have been
closed.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/9fec9a82887853402833a80b584e3762c7423f5f">9fec9a82</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 4 May 2024. The
issue was made public on 3 July 2024.</p>
<p>Affects: 9.0.0-M1 to 9.0.89</p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-38286" rel="nofollow">CVE-2024-38286</a></p>
<p>Tomcat, under certain configurations on any platform, allows an attacker
to cause an OutOfMemoryError by abusing the TLS handshake process.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/76c5cce6f0bcef14b0c21c38910371ca7d322d13">76c5cce6</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 4 June 2024. The
issue was made public on 23 September 2024.</p>
<p>Affects: 9.0.13 to 9.0.89</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.86"><span class="pull-right">2024-02-19</span> Fixed in Apache Tomcat 9.0.86</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23672" rel="nofollow">CVE-2024-23672</a></p>
<p>It was possible for a WebSocket client to keep a WebSocket connection
open leading to increased resource consumption.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/52d6650e062d880704898d7d8c1b2b7a3efe8068">52d6650e</a>.</p>
<p>This issue was identified by the Tomcat Security Team on 17 January 2024.
The issue was made public on 13 March 2024.</p>
<p>Affects: 9.0.0-M1 to 9.0.85</p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-24549" rel="nofollow">CVE-2024-24549</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/8e03be9f2698f2da9027d40b9e9c0c9429b74dc0">8e03be9f</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 24 January 2024. The
issue was made public on 13 March 2024.</p>
<p>Affects: 9.0.0-M1 to 9.0.85</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.83"><span class="pull-right">2023-11-15</span> Fixed in Apache Tomcat 9.0.83</h3><div class="text">
<p><strong>Important: Request smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-46589" rel="nofollow">CVE-2023-46589</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/7a2d8818fcea0b51747a67af9510ce7977245ebd">7a2d8818</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 20 October 2023.
The issue was made public on 28 November 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.82</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.81"><span class="pull-right">2023-10-10</span> Fixed in Apache Tomcat 9.0.81</h3><div class="text">
<p><strong>Important: Request smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45648" rel="nofollow">CVE-2023-45648</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/59583245639d8c42ae0009f4a4a70464d3ea70a0">59583245</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 12 September 2023.
The issue was made public on 10 October 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.80</p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-44487" rel="nofollow">CVE-2023-44487</a></p>
<p>Tomcat's HTTP/2 implementation was vulnerable to the rapid reset
attack. The denial of service typically manifested as an
<code>OutOfMemoryError</code>.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/6d1a9fd6642387969e4410b9989c85856b74917a">6d1a9fd6</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 14 September 2023.
The issue was made public on 10 October 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.80</p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-42795" rel="nofollow">CVE-2023-42795</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/44d05d75d696ca10ce251e4e370511e38f20ae75">44d05d75</a>.</p>
<p>This issue was identified by the Tomcat Security Team on 13 September
2023. The issue was made public on 10 October 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.80</p>
<p><strong>Low: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-42794" rel="nofollow">CVE-2023-42794</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/43b882b8a577684498ab9b8851aa0427216784f7">43b882b8</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 1 September
2023. The issue was made public on 10 October 2023.</p>
<p>Affects: 9.0.70 to 9.0.80</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.80"><span class="pull-right">2023-08-25</span> Fixed in Apache Tomcat 9.0.80</h3><div class="text">
<p><strong>Moderate: Open redirect</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41080" rel="nofollow">CVE-2023-41080</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/77c0ce2d169efa248b64b992e547aad549ec906b">77c0ce2d</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 17 August 2023. The
issue was made public on 22 August 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.79</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.75"><span class="pull-right">2023-05-10</span> Fixed in Apache Tomcat 9.0.75</h3><div class="text">
<p><strong>Important: Information disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34981" rel="nofollow">CVE-2023-34981</a></p>
<p>The fix for bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=66512">66512</a> introduced a regression that was fixed
as bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=66591">66591</a>. The regression meant that, if a response did not
have any HTTP headers set, no AJP <code>SEND_HEADERS</code> 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/2f0ca2378415f4cf0748f4bc8fa955f41f803fa5">2f0ca237</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 24 May 2023. The
issue was made public on 21 June 2023.</p>
<p>Affects: 9.0.74</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.74"><span class="pull-right">2023-04-18</span> Fixed in Apache Tomcat 9.0.74</h3><div class="text">
<p><strong>Moderate: Apache Tomcat denial of service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28709" rel="nofollow">CVE-2023-28709</a></p>
<p>The fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998" rel="nofollow">CVE-2023-24998</a> was incomplete. If non-default HTTP
connector settings were used such that the <code>maxParameterCount</code>
could be reached using query string parameters and a request was
submitted that supplied exactly <code>maxParameterCount</code> parameters
in the query string, the limit for uploaded request parts could be
bypassed with the potential for a denial of service to occur.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/fbd81421629afe8b8a3922d59020cde81caea861">fbd81421</a>.</p>
<p>This issue was reported to the Tomcat Security Team on 13 March 2023. The
issue was made public on 22 May 2023.</p>
<p>Affects: 9.0.71 to 9.0.73</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.72"><span class="pull-right">2023-02-23</span> Fixed in Apache Tomcat 9.0.72</h3><div class="text">
<p><strong>Important: Apache Tomcat information disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28708" rel="nofollow">CVE-2023-28708</a></p>
<p>When using the <code>RemoteIpFilter</code> with requests received from a
reverse proxy via HTTP that include the <code>X-Forwarded-Proto</code>
header set to <code>https</code>, 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/3b51230764da595bb19e8d0962dd8c69ab40dfab">3b512307</a>.</p>
<p><a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=66471">66471</a> 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.</p>
<p>Affects: 9.0.0-M1 to 9.0.71</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.71"><span class="pull-right">2023-01-13</span> Fixed in Apache Tomcat 9.0.71</h3><div class="text">
<p><strong>Important: Apache Tomcat denial of service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998" rel="nofollow">CVE-2023-24998</a></p>
<p>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 <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998" rel="nofollow">CVE-2023-24998</a> 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/cf77cc545de0488fb89e24294151504a7432df74">cf77cc54</a>.</p>
<p>This issue was reported to the Apache Tomcat Security team on 11
December 2022. The issue was made public on 20 February 2023.</p>
<p>Affects: 9.0.0-M1 to 9.0.70</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.69"><span class="pull-right">2022-11-14</span> Fixed in Apache Tomcat 9.0.69</h3><div class="text">
<p><strong>Low: Apache Tomcat JsonErrorReportValve injection</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-45143" rel="nofollow">CVE-2022-45143</a></p>
<p>The <code>JsonErrorReportValve</code> did not escape the
<code>type</code>, <code>message</code> or <code>description</code>
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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/b336f4e58893ea35114f1e4a415657f723b1298e">b336f4e5</a>.</p>
<p>This issue was identified by the Apache Tomcat Security team on 2
September 2022. The issue was made public on 3 January 2023.</p>
<p>Affects: 9.0.40 to 9.0.68</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.68"><span class="pull-right">2022-10-07</span> Fixed in Apache Tomcat 9.0.68</h3><div class="text">
<p><strong>Low: Apache Tomcat request smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42252" rel="nofollow">CVE-2022-42252</a></p>
<p>If Tomcat was configured to ignore invalid HTTP headers via setting
<code>rejectIllegalHeader</code> to <code>false</code> (not the default),
Tomcat did not reject a request containing an invalid
<code>Content-Length</code> 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/4c7f4fd09d2cc1692112ef70b8ee23a7a037ae77">4c7f4fd0</a>.</p>
<p>This issue was reported to the Apache Tomcat Security team on 29
September 2022. The issue was made public on 31 October 2022.</p>
<p>Affects: 9.0.0-M1 to 9.0.67</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.65"><span class="pull-right">2022-07-20</span> Fixed in Apache Tomcat 9.0.65</h3><div class="text">
<p><strong>Low: Apache Tomcat XSS in examples web application</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34305" rel="nofollow">CVE-2022-34305</a></p>
<p>The Form authentication example in the examples web application displayed
user provided data without filtering, exposing a XSS vulnerability.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/8b60af90b99945379c2d1003277e0cabc6776bac">8b60af90</a>.</p>
<p>This issue was reported to the Apache Tomcat Security team on 22 June
2022. The issue was made public on 23 June 2022.</p>
<p>Affects: 9.0.30 to 9.0.64</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.63"><span class="pull-right">2022-05-16</span> Fixed in Apache Tomcat 9.0.63</h3><div class="text">
<p><strong>Low: Apache Tomcat EncryptInterceptor DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29885" rel="nofollow">CVE-2022-29885</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/eaafd28296c54d983e28a47953c1f5cb2c334f48">eaafd282</a>.</p>
<p>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.</p>
<p>Affects: 9.0.13 to 9.0.62</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.62"><span class="pull-right">1 April 2022</span> Fixed in Apache Tomcat 9.0.62</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.61 but the
release vote for the 9.0.61 release candidate did not pass. Therefore,
although users must download 9.0.62 to obtain a version that includes a
fix for these issues, version 9.0.61 is not included in the list of
affected versions.</i></p>
<p><strong>High: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43980" rel="nofollow">CVE-2021-43980</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/170e0f792bd18ff031677890ba2fe50eb7a376c1">170e0f79</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0-M1 to 9.0.60</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.58"><span class="pull-right">20 January 2022</span> Fixed in Apache Tomcat 9.0.58</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.57 but the
release vote for the 9.0.57 release candidate did not pass. Therefore,
although users must download 9.0.58 to obtain a version that includes a
fix for these issues, version 9.0.57 is not included in the list of
affected versions.</i></p>
<p><strong>Low: Local Privilege Escalation</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23181" rel="nofollow">CVE-2022-23181</a></p>
<p>The fix for bug <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a> 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/1385c624b4a1e994426e810075c850edc38a700e">1385c624</a>.</p>
<p>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.</p>
<p>Affects: 9.0.35 to 9.0.56</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.54"><span class="pull-right">1 October 2021</span> Fixed in Apache Tomcat 9.0.54</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42340" rel="nofollow">CVE-2021-42340</a></p>
<p>The fix for bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=63362">63362</a> 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/80f1438ec45e77a07b96419808971838d259eb47">80f1438e</a>.</p>
<p>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.</p>
<p>Affects: 9.0.40 to 9.0.53</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.48"><span class="pull-right">15 June 2021</span> Fixed in Apache Tomcat 9.0.48</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.47 but the
release vote for the 9.0.47 release candidate did not pass. Therefore,
although users must download 9.0.48 to obtain a version that includes a
fix for this issue, version 9.0.47 is not included in the list of
affected versions.</i></p>
<p><strong>Important: Request Smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33037" rel="nofollow">CVE-2021-33037</a></p>
<p>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.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/45d70a86a901cbd534f8f570bed2aec9f7f7b88e">45d70a86</a>,
<a href="https://github.com/apache/tomcat/commit/05f9e8b00f5d9251fcd3c95dcfd6cf84177f46c8">05f9e8b0</a> and
<a href="https://github.com/apache/tomcat/commit/a2c3dc4c96168743ac0bab613709a5bbdaec41d0">a2c3dc4c</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.46</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.46"><span class="pull-right">12 May 2021</span> Fixed in Apache Tomcat 9.0.46</h3><div class="text">
<p><strong>Low: Authentication weakness</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30640" rel="nofollow">CVE-2021-30640</a></p>
<p>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.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/c4df8d44a959a937d507d15e5b1ca35c3dbc41eb">c4df8d44</a>,
<a href="https://github.com/apache/tomcat/commit/749f3cc192c68c34f2375509aea087be45fc4434">749f3cc1</a>,
<a href="https://github.com/apache/tomcat/commit/c6b6e1015ae44c936971b6bf8bce70987935b92e">c6b6e101</a>,
<a href="https://github.com/apache/tomcat/commit/91ecdc61ce3420054c04114baaaf1c1e0cbd5d56">91ecdc61</a>,
<a href="https://github.com/apache/tomcat/commit/e50067486cf86564175ca0cfdcbf7d209c6df862">e5006748</a>,
<a href="https://github.com/apache/tomcat/commit/b5585a9e5d4fec020cc5ebadb82f899fae22bc43">b5585a9e</a>,
<a href="https://github.com/apache/tomcat/commit/329932012d3a9b95fde0b18618416e659ecffdc0">32993201</a> and
<a href="https://github.com/apache/tomcat/commit/3ce84512ed8783577d9945df28da5a033465b945">3ce84512</a>.</p>
<p>This issue was reported publicly as <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=65224">65224</a>.</p>
<p>Affects: 9.0.0.M1 to 9.0.45</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.45"><span class="pull-right">6 April 2021</span> Fixed in Apache Tomcat 9.0.45</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30639" rel="nofollow">CVE-2021-30639</a></p>
<p>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.</p>
<o>Applications that do not use non-blocking I/O are not exposed to this
vulnerability.</o>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/8ece47c4a9fb9349e8862c84358a4dd23c643a24">8ece47c4</a>.</p>
<p>This issue was reported publicly as <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=65203">65203</a>.</p>
<p>Affects: 9.0.44</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.44"><span class="pull-right">10 March 2021</span> Fixed in Apache Tomcat 9.0.44</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41079" rel="nofollow">CVE-2021-41079</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/d4b340fa8feaf55831f9a59350578f7b6ca048b8">d4b340fa</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0-M1 to 9.0.43</p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21733" rel="nofollow">CVE-2024-21733</a></p>
<p>Incomplete POST requests triggered an error response that could contain
data from a previous request from another user.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/86ccc43940861703c2be96a5f35384407522125a">86ccc439</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0-M11 to 9.0.43</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.43"><span class="pull-right">2 February 2021</span> Fixed in Apache Tomcat 9.0.43</h3><div class="text">
<p><i>Note: The issues below were fixed in Apache Tomcat 9.0.42 but the
release vote for the 9.0.42 release candidate did not pass. Therefore,
although users must download 9.0.43 to obtain a version that includes a
fix for these issues, version 9.0.42 is not included in the list of
affected versions.</i></p>
<p><strong>Low: Fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a> was incomplete</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25329" rel="nofollow">CVE-2021-25329</a></p>
<p>The fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a> was incomplete. When using a
highly unlikely configuration edge case, the Tomcat instance was still
vulnerable to <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a>. Note that both the previously
published prerequisites for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a> and the previously
published non-upgrade mitigations for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a> also apply to
this issue.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/4785433a226a20df6acbea49296e1ce7e23de453">4785433a</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.41</p>
<p><strong>Important: Request mix-up with h2c</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25122" rel="nofollow">CVE-2021-25122</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/d47c20a776e8919eaca8da9390a32bc8bf8210b1">d47c20a7</a>.</p>
<p>This issue was identified by the Apache Tomcat Security team on 11
January 2021. The issue was made public on 1 March 2021.</p>
<p>Affects: 9.0.0.M1 to 9.0.41</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.40"><span class="pull-right">17 November 2020</span> Fixed in Apache Tomcat 9.0.40</h3><div class="text">
<p><strong>Important: Information disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-24122" rel="nofollow">CVE-2021-24122</a></p>
<p>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 <code>File.getCanonicalPath()</code> which in
turn was caused by the inconsistent behaviour of the Windows API
(<code>FindFirstFileW</code>) in some circumstances.
</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/935fc5582dc25ae10bab6f9d5629ff8d996cb533">935fc558</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.39</p>
<p><strong>Moderate: HTTP/2 request header mix-up</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17527" rel="nofollow">CVE-2020-17527</a></p>
<p>While investigating issue <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=64830">64830</a> 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.
</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/d56293f816d6dc9e2b47107f208fa9e95db58c65">d56293f8</a>.</p>
<p>This issue was identified by the Apache Tomcat Security team on 10
November 2020. The issue was made public on 3 December 2020.</p>
<p>Affects: 9.0.0-M1 to 9.0.39</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.38"><span class="pull-right">15 September 2020</span> Fixed in Apache Tomcat 9.0.38</h3><div class="text">
<p><strong>Moderate: HTTP/2 request mix-up</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13943" rel="nofollow">CVE-2020-13943</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/55911430df13f8c9998fbdee1f9716994d2db59b">55911430</a>.</p>
<p>This issue was identified by the Apache Tomcat Security team on 23 July
2020. The issue was made public on 12 October 2020.</p>
<p>Affects: 9.0.0.M1 to 9.0.37</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.37"><span class="pull-right">5 July 2020</span> Fixed in Apache Tomcat 9.0.37</h3><div class="text">
<p><strong>Important: WebSocket DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13935" rel="nofollow">CVE-2020-13935</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/40fa74c74822711ab878079d0a69f7357926723d">40fa74c7</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.36</p>
<p><strong>Moderate: HTTP/2 DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13934" rel="nofollow">CVE-2020-13934</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/172977f04a5215128f1e278a688983dcd230f399">172977f0</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M5 to 9.0.36</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.36"><span class="pull-right">7 June 2020</span> Fixed in Apache Tomcat 9.0.36</h3><div class="text">
<p><strong>Important: HTTP/2 DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11996" rel="nofollow">CVE-2020-11996</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/9a0231683a77e2957cea0fdee88b193b30b0c976">9a023168</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.35</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.35"><span class="pull-right">11 May 2020</span> Fixed in Apache Tomcat 9.0.35</h3><div class="text">
<p><strong>Important: Remote Code Execution via session persistence</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484" rel="nofollow">CVE-2020-9484</a></p>
<p>If:</p>
<ul>
<li>an attacker is able to control the contents and name of a file on the
server; and</li>
<li>the server is configured to use the <code>PersistenceManager</code>
with a <code>FileStore</code>; and</li>
<li>the <code>PersistenceManager</code> is configured with
<code>sessionAttributeValueClassNameFilter="null"</code> (the default
unless a <code>SecurityManager</code> is used) or a sufficiently lax
filter to allow the attacker provided object to be deserialized;
and</li>
<li>the attacker knows the relative file path from the storage location
used by <code>FileStore</code> to the file the attacker has control
over;</li>
</ul>
<p>then, using a specifically crafted request, the attacker will be able to
trigger remote code execution via deserialization of the file under their
control.</p>
<p><strong>Note:</strong> All of conditions above must be true for the
attack to succeed.</p>
<p>As an alternative to upgrading to 9.0.35 or later, users may configure
the <code>PersistenceManager</code> with an appropriate value for
<code>sessionAttributeValueClassNameFilter</code> to ensure that only
application provided attributes are serialized and deserialized.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/3aa8f28db7efb311cdd1b6fe15a9cd3b167a2222">3aa8f28d</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.34</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.31"><span class="pull-right">11 February 2020</span> Fixed in Apache Tomcat 9.0.31</h3><div class="text">
<p><strong>Important: AJP Request Injection and potential Remote Code Execution</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1938" rel="nofollow">CVE-2020-1938</a></p>
<p>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 9.0.31, 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.</p>
<p>Prior to this vulnerability report, the known risks of an attacker being
able to access the AJP port directly were:</p>
<ul>
<li>bypassing security checks based on client IP address</li>
<li>bypassing user authentication if Tomcat was configured to trust
authentication data provided by the reverse proxy</li>
</ul>
<p>This vulnerability report identified a mechanism that allowed the
following:</p>
<ul>
<li>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()</li>
<li>processing any file in the web application as a JSP</li>
</ul>
<p>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.</p>
<p>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 9.0.31 to harden the default
configuration. It is likely that users upgrading to 9.0.31 or later
will need to make small changes to their configurations as a result.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/0e8a50f0a5958744bea1fd6768c862e04d3b7e75">0e8a50f0</a>,
<a href="https://github.com/apache/tomcat/commit/9ac90532e9a7d239f90952edb229b07c80a9a3eb">9ac90532</a>,
<a href="https://github.com/apache/tomcat/commit/64fa5b99442589ef0bf2a7fcd71ad2bc68b35fad">64fa5b99</a>,
<a href="https://github.com/apache/tomcat/commit/7a1406a3cd20fdd90656add6cd8f27ef8f24e957">7a1406a3</a> and
<a href="https://github.com/apache/tomcat/commit/49ad3f954f69c6e838c8cd112ad79aa5fa8e7153">49ad3f95</a>.</p>
<p>This issue was reported to the Apache Tomcat Security Team on 3 January
2020. The issue was made public on 24 February 2020.</p>
<p>Affects: 9.0.0.M1 to 9.0.30</p>
<p><strong>Low: HTTP Request Smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1935" rel="nofollow">CVE-2020-1935</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/8bfb0ff7f25fe7555a5eb2f7984f73546c11aa26">8bfb0ff7</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.30</p>
<p><strong>Low: HTTP Request Smuggling</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17569" rel="nofollow">CVE-2019-17569</a></p>
<p>The refactoring in 9.0.28 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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/060ecc5eb839208687b7fcc9e35287ac8eb46998">060ecc5e</a>.</p>
<p>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.</p>
<p>Affects: 9.0.28 to 9.0.30</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.30"><span class="pull-right">12 December 2019</span> Fixed in Apache Tomcat 9.0.30</h3><div class="text">
<p><strong>Low: Session fixation</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17563" rel="nofollow">CVE-2019-17563</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/1ecba14e690cf5f3f143eef6ae7037a6d3c16652">1ecba14e</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.29</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.29"><span class="pull-right">21 November 2019</span> Fixed in Apache Tomcat 9.0.29</h3><div class="text">
<p><strong>Moderate: Local Privilege Escalation</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12418" rel="nofollow">CVE-2019-12418</a></p>
<p>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.</p>
<p>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.</p>
<p>Users should also be aware of <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2684" rel="nofollow">CVE-2019-2684</a>, a JRE
vulnerability that enables this issue to be exploited remotely.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/1fc9f589dbdd8295cf313b2667ab041c425f99c3">1fc9f589</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.28</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.21"><span class="pull-right">7 June 2019</span> Fixed in Apache Tomcat 9.0.21</h3><div class="text">
<p><strong>Important: Request mix-up</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25762" rel="nofollow">CVE-2022-25762</a></p>
<p>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.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/e2d5a040b962a904db5264b3cb3282c6b05f823c">e2d5a040</a>,
<a href="https://github.com/apache/tomcat/commit/7046644bf361b89afc246b6643e24ce2ae60cacc">7046644b</a>,
<a href="https://github.com/apache/tomcat/commit/339b40bc07bdba9ded565929b9a3448c5a78f015">339b40bc</a> and
<a href="https://github.com/apache/tomcat/commit/65fb1ee548111021edde247f3b3c409ec95a5183">65fb1ee5</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 21
December 2021. The issue was made public on 12 May 2022.</p>
<p>Affects: 9.0.0.M1 to 9.0.20</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.20"><span class="pull-right">13 May 2019</span> Fixed in Apache Tomcat 9.0.20</h3><div class="text">
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10072" rel="nofollow">CVE-2019-10072</a></p>
<p>The fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0199" rel="nofollow">CVE-2019-0199</a> 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.</p>
<p>This was fixed with commits
<a href="https://github.com/apache/tomcat/commit/7f748eb6bfaba5207c89dbd7d5adf50fae847145">7f748eb6</a> and
<a href="https://github.com/apache/tomcat/commit/ada725a50a60867af3422c8e612aecaeea856a9a">ada725a5</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.19</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.19"><span class="pull-right">13 April 2019</span> Fixed in Apache Tomcat 9.0.19</h3><div class="text">
<p><i>Note: The issues below were fixed in Apache Tomcat 9.0.18 but the
release vote for the 9.0.18 release candidate did not pass. Therefore,
although users must download 9.0.19 to obtain a version that includes a
fix for these issues, version 9.0.18 is not included in the list of
affected versions.</i></p>
<p><strong>Important: Remote Code Execution on Windows</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0232" rel="nofollow">CVE-2019-0232</a></p>
<p>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. The CGI option enableCmdLineArguments is disabled by
default in Tomcat 9.0.x. For a detailed explanation of the JRE behaviour,
see
<a href="https://codewhitesec.blogspot.com/2016/02/java-and-command-line-injections-in-windows.html">Markus
Wulftange's blog</a> and this archived
<a href="https://web.archive.org/web/20161228144344/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/">MSDN
blog</a>.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/4b244d827ade2a36ef3b8734939541207b78f35c">4b244d82</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.17</p>
<p><strong>Low: XSS in SSI printenv</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0221" rel="nofollow">CVE-2019-0221</a></p>
<p>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.</p>
<p>This was fixed with commit
<a href="https://github.com/apache/tomcat/commit/15fcd166ea2c1bb79e8541b8e1a43da9c452ceea">15fcd166</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.17</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.16"><span class="pull-right">8 February 2019</span> Fixed in Apache Tomcat 9.0.16</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.15 but the
release vote for the 9.0.15 release candidate did not pass. Therefore,
although users must download 9.0.16 to obtain a version that includes a
fix for these issues, version 9.0.15 is not included in the list of
affected versions.</i></p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0199" rel="nofollow">CVE-2019-0199</a></p>
<p>The HTTP/2 implementation accepted streams with excessive numbers of
<code>SETTINGS</code> 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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852698">1852698</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852699">1852699</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852700">1852700</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852701">1852701</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852702">1852702</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852703">1852703</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852704">1852704</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852705">1852705</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1852706">1852706</a> and
<a href="https://github.com/apache/tomcat/commit/a1cb1ac77e3a8fec1b00eb0e944842555da14f7d">a1cb1ac7</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.14</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.12"><span class="pull-right">10 September 2018</span> Fixed in Apache Tomcat 9.0.12</h3><div class="text">
<p><strong>Moderate: Open Redirect</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11784" rel="nofollow">CVE-2018-11784</a></p>
<p>When the default servlet returned a redirect to a directory (e.g.
redirecting to <code>/foo/</code> when the user requested
<code>/foo</code>) a specially crafted URL could be used to cause the
redirect to be generated to any URI of the attackers choice.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1840055">1840055</a>.</p>
<p>This issue was reported to the Apache Tomcat Security Team by Sergey
Bobrov on 28 August 2018 and made public on 3 October 2018.</p>
<p>Affects: 9.0.0.M1 to 9.0.11</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.10"><span class="pull-right">25 June 2018</span> Fixed in Apache Tomcat 9.0.10</h3><div class="text">
<p><strong>Low: host name verification missing in WebSocket client</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8034" rel="nofollow">CVE-2018-8034</a></p>
<p>The host name verification when using TLS with the WebSocket client was
missing. It is now enabled by default.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1833757">1833757</a>.</p>
<p>This issue was reported publicly on 11 June 2018 and formally announced as
a vulnerability on 22 July 2018.</p>
<p>Affects: 9.0.0.M1 to 9.0.9</p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8037" rel="nofollow">CVE-2018-8037</a></p>
<p>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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1833825">1833825</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1833831">1833831</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1837530">1837530</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1833906">1833906</a>.</p>
<p>This issue was reported to the Apache Tomcat Security Team by Dmitry
Treskunov on 16 June 2018 and made public on 22 July 2018.</p>
<p>Affects: 9.0.0.M9 to 9.0.9</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.9"><span class="pull-right">not released</span> Fixed in Apache Tomcat 9.0.9</h3><div class="text">
<p><strong>Low: CORS filter has insecure defaults</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8014" rel="nofollow">CVE-2018-8014</a></p>
<p>The defaults settings for the CORS filter are insecure and enable
<code>supportsCredentials</code> 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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1831726">1831726</a>.</p>
<p>This issue was reported publicly on 1 May 2018 and formally announced as
a vulnerability on 16 May 2018.</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.8"><span class="pull-right">3 May 2018</span> Fixed in Apache Tomcat 9.0.8</h3><div class="text">
<p><strong>Important: A bug in the UTF-8 decoder can lead to DoS</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1336" rel="nofollow">CVE-2018-1336</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1830373">1830373</a>.</p>
<p>This issue was reported publicly on 6 April 2018 and formally announced as
a vulnerability on 22 July 2018.</p>
<p>Affects: 9.0.0.M1 to 9.0.7</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.5"><span class="pull-right">11 February 2018</span> Fixed in Apache Tomcat 9.0.5</h3><div class="text">
<p><strong>Important: Security constraint annotations applied too
late</strong> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1305" rel="nofollow">CVE-2018-1305</a></p>
<p>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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1823310">1823310</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1824323">1824323</a>.</p>
<p>This issue was identified by the Apache Tomcat Security on 1 February
2018 and made public on 23 February 2018.</p>
<p>Affects: 9.0.0.M1 to 9.0.4</p>
<p><strong>Important: Security constraints mapped to context root are
ignored</strong> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1304" rel="nofollow">CVE-2018-1304</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1823306">1823306</a>.</p>
<p>This issue was reported publicly as <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=62067">62067</a> 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.</p>
<p>Affects: 9.0.0.M1 to 9.0.4</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.2"><span class="pull-right">30 November 2017</span> Fixed in Apache Tomcat 9.0.2</h3><div class="text">
<p><strong>Low: Incorrectly documented CGI search algorithm</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15706" rel="nofollow">CVE-2017-15706</a></p>
<p>As part of the fix for bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=61201">61201</a>, 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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1814825">1814825</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M22 to 9.0.1</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.1"><span class="pull-right">30 September 2017</span> Fixed in Apache Tomcat 9.0.1</h3><div class="text">
<p><strong>Important: Remote Code Execution</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12617" rel="nofollow">CVE-2017-12617</a></p>
<p>When running with HTTP PUTs enabled (e.g. via setting the
<code>readonly</code> 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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1809669">1809669</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1809674">1809674</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1809684">1809684</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1809711">1809711</a>.</p>
<p>This issue was first reported publicly followed by multiple reports to
the Apache Tomcat Security Team on 20 September 2017.</p>
<p>Affects: 9.0.0.M1 to 9.0.0</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M22"><span class="pull-right">26 June 2017</span> Fixed in Apache Tomcat 9.0.0.M22</h3><div class="text">
<p><strong>Important: Security Constraint Bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7675" rel="nofollow">CVE-2017-7675</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1796090">1796090</a>.</p>
<p>The issue was originally reported as a failure to process URL path
parameters in bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=61120">61120</a> 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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M21</p>
<p><strong>Moderate: Cache Poisoning</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7674" rel="nofollow">CVE-2017-7674</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1795813">1795813</a>.</p>
<p>The issue was reported as bug <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=61101">61101</a> 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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M21</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M21"><span class="pull-right">10 May 2017</span> Fixed in Apache Tomcat 9.0.0.M21</h3><div class="text">
<p><strong>Important: Security Constraint Bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5664" rel="nofollow">CVE-2017-5664</a></p>
<p>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.</p>
<p>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.</p>
<p>Notes for other user provided error pages:</p>
<ul>
<li>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.</li>
<li>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.</li>
</ul>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1793468">1793468</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1793487">1793487</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M20</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M19"><span class="pull-right">30 March 2017</span> Fixed in Apache Tomcat 9.0.0.M19</h3><div class="text">
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5651" rel="nofollow">CVE-2017-5651</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1788544">1788544</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 24
March 2017 and made public on 10 April 2017.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M18</p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5650" rel="nofollow">CVE-2017-5650</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1788460">1788460</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M18</p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5647" rel="nofollow">CVE-2017-5647</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1788890">1788890</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 20
March 2017 and made public on 10 April 2017.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M18</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M18"><span class="pull-right">13 March 2017</span> Fixed in Apache Tomcat 9.0.0.M18</h3><div class="text">
<p><strong>Low: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5648" rel="nofollow">CVE-2017-5648</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1785774">1785774</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 20
March 2017 and made public on 10 April 2017.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M17</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M17"><span class="pull-right">16 January 2017</span> Fixed in Apache Tomcat 9.0.0.M17</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.0.M16 but the
release vote for the 9.0.0.M16 release candidate did not pass. Therefore,
although users must download 9.0.0.M17 to obtain a version that includes
the fix for this issue, version 9.0.0.M16 is not included in the list of
affected versions.</i></p>
<p><strong>Moderate: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8747" rel="nofollow">CVE-2016-8747</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1774161">1774161</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 14
December 2016 and made public on 13 March 2017.</p>
<p>Affects: 9.0.0.M11 to 9.0.0.M15</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M15"><span class="pull-right">8 December 2016</span> Fixed in Apache Tomcat 9.0.0.M15</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.0.M14 but the
release vote for the 9.0.0.M14 release candidate did not pass. Therefore,
although users must download 9.0.0.M15 to obtain a version that includes
the fix for this issue, version 9.0.0.M14 is not included in the list of
affected versions.</i></p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8745" rel="nofollow">CVE-2016-8745</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1771853">1771853</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 8 December
2016 and made public on 12 December 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M13</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M13"><span class="pull-right">8 November 2016</span> Fixed in Apache Tomcat 9.0.0.M13</h3><div class="text">
<p><i>Note: The issues below were fixed in Apache Tomcat 9.0.0.M12 but the
release vote for the 9.0.0.M12 release candidate did not pass. Therefore,
although users must download 9.0.0.M13 to obtain a version that includes
fixes for these issues, version 9.0.0.M12 is not included in the list of
affected versions.</i></p>
<p><strong>Important: Remote Code Execution</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8735" rel="nofollow">CVE-2016-8735</a></p>
<p>The <code>JmxRemoteLifecycleListener</code> was not updated to take
account of Oracle's fix for <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3427" rel="nofollow">CVE-2016-3427</a>. 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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1767644">1767644</a>.</p>
<p>This issue was reported to the Apache Tomcat Security Team on 19 October
2016 and made public on 22 November 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M11</p>
<p><strong>Important: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6817" rel="nofollow">CVE-2016-6817</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1765794">1765794</a>.</p>
<p>This issue was reported as <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=60232">60232</a> 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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M11</p>
<p><strong>Important: Information Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816" rel="nofollow">CVE-2016-6816</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1767641">1767641</a>.</p>
<p>This issue was reported to the Apache Tomcat Security Team on 11 October
2016 and made public on 22 November 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M11</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M10"><span class="pull-right">5 September 2016</span> Fixed in Apache Tomcat 9.0.0.M10</h3><div class="text">
<p><strong>Low: Unrestricted Access to Global Resources</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6797" rel="nofollow">CVE-2016-6797</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1757271">1757271</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 18
January 2016 and made public on 27 October 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M9</p>
<p><strong>Low: Security Manager Bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6796" rel="nofollow">CVE-2016-6796</a></p>
<p>A malicious web application was able to bypass a configured
SecurityManager via manipulation of the configuration parameters for the
JSP Servlet.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1758487">1758487</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1763232">1763232</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 27
December 2015 and made public on 27 October 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M9</p>
<p><strong>Low: System Property Disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6794" rel="nofollow">CVE-2016-6794</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1754445">1754445</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 27
December 2015 and made public on 27 October 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M9</p>
<p><strong>Low: Security Manager Bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5018" rel="nofollow">CVE-2016-5018</a></p>
<p>A malicious web application was able to bypass a configured
SecurityManager via a Tomcat utility method that was accessible to web
applications.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1754714">1754714</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1760300">1760300</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M9</p>
<p><strong>Low: Timing Attack</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0762" rel="nofollow">CVE-2016-0762</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1758499">1758499</a>.</p>
<p>This issue was identified by the Apache Tomcat Security Team on 1 January
2016 and made public on 27 October 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M9</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M8"><span class="pull-right">13 June 2016</span> Fixed in Apache Tomcat 9.0.0.M8</h3><div class="text">
<p><i>Note: The issue below was fixed in Apache Tomcat 9.0.0.M7 but the
release vote for the 9.0.0.M7 release candidate did not pass. Therefore,
although users must download 9.0.0.M8 to obtain a version that includes
fixes for these issues, version 9.0.0.M7 is not included in the list of
affected versions.</i></p>
<p><strong>Moderate: Denial of Service</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3092" rel="nofollow">CVE-2016-3092</a></p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1743700">1743700</a>.</p>
<p>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.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M6</p>
</div><h3 id="Fixed_in_Apache_Tomcat_9.0.0.M3"><span class="pull-right">5 January 2016</span> Fixed in Apache Tomcat 9.0.0.M3</h3><div class="text">
<p><strong>Moderate: Security Manager bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0763" rel="nofollow">CVE-2016-0763</a></p>
<p>This issue only affects users running untrusted web applications under a
security manager.</p>
<p><code>ResourceLinkFactory.setGlobalContext()</code> 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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1725926">1725926</a>.</p>
<p>This issue was identified by the Tomcat security team on 18 January 2016
and made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1 to 9.0.0.M2</p>
<p><i>Note: The issues below were fixed in Apache Tomcat 9.0.0.M2 but the
release vote for the 9.0.0.M2 release candidate did not pass. Therefore,
although users must download 9.0.0.M3 to obtain a version that includes
fixes for these issues, version 9.0.0.M2 is not included in the list of
affected versions.</i></p>
<p><strong>Low: Directory disclosure</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5345" rel="nofollow">CVE-2015-5345</a></p>
<p>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.</p>
<p>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
(<code>mapperContextRootRedirectEnabled</code> and
<code>mapperDirectoryRedirectEnabled</code>) were introduced. The initial
default was <code>false</code> for both since this was more secure.
However, due to regressions such as
<a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=58765">Bug
58765</a> the default for <code>mapperContextRootRedirectEnabled</code>
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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1715206">1715206</a>,
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1716882">1716882</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1716894">1716894</a>.</p>
<p>This issue was identified by Mark Koek of QCSec on 12 October 2015 and
made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1</p>
<p><strong>Low: Session Fixation</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5346" rel="nofollow">CVE-2015-5346</a></p>
<p>When recycling the <code>Request</code> object to use for a new request,
the <code>requestedSessionSSL</code> field was not recycled. This meant that
a session ID provided in the next request to be processed using the recycled
<code>Request</code> 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' <code>Request</code> 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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1713184">1713184</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1723414">1723414</a>.</p>
<p>This issue was identified by the Tomcat security team on 22 June 2014
and made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1</p>
<p><strong>Moderate: CSRF token leak</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5351" rel="nofollow">CVE-2015-5351</a></p>
<p>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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1720652">1720652</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1720655">1720655</a>.</p>
<p>This issue was identified by the Tomcat security team on 8 December 2015
and made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1</p>
<p><strong>Low: Security Manager bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0706" rel="nofollow">CVE-2016-0706</a></p>
<p>This issue only affects users running untrusted web applications under a
security manager.</p>
<p>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.</p>
<p>This was fixed in revision <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1722799">1722799</a>.</p>
<p>This issue was identified by the Tomcat security team on 27 December 2015
and made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1</p>
<p><strong>Moderate: Security Manager bypass</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0714" rel="nofollow">CVE-2016-0714</a></p>
<p>This issue only affects users running untrusted web applications under a
security manager.</p>
<p>Tomcat provides several session persistence mechanisms. The
<code>StandardManager</code> persists session over a restart. The
<code>PersistentManager</code> is able to persist sessions to files, a
database or a custom <code>Store</code>. 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.</p>
<p>This was fixed in revisions <a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1725263">1725263</a> and
<a href="https://svn.apache.org/viewvc?view=rev&amp;rev=1725914">1725914</a>.</p>
<p>This issue was identified by the Tomcat security team on 12 November 2015
and made public on 22 February 2016.</p>
<p>Affects: 9.0.0.M1</p>
</div><h3 id="Not_a_vulnerability_in_Tomcat">Not a vulnerability in Tomcat</h3><div class="text">
<p><strong>Critical: Remote Code Execution via log4j</strong>
<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228" rel="nofollow">CVE-2021-44228</a></p>
<p>Apache Tomcat 9.0.x has no dependency on any version of log4j.</p>
<p>Web applications deployed on Apache Tomcat may have a dependency on
log4j. You should seek support from the application vendor in this
instance.</p>
<p>It is possible to configure Apache Tomcat 9.0.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.</p>
<p>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
<a href="https://logging.apache.org/log4j/2.x/security.html">log4j 2.x
security page</a>.</p>
</div></div></div></div></main><footer id="footer">
Copyright &copy; 1999-2026, The Apache Software Foundation
<br>
Apache Tomcat, Tomcat, Apache, the Apache Tomcat logo and the Apache logo
are either registered trademarks or trademarks of the Apache Software
Foundation.
</footer></div><script src="res/js/tomcat.js"></script></body></html>