Please note that, except in rare circumstances, binary patches are not
produced for individual vulnerabilities. To obtain the binary fix for a
particular vulnerability you should upgrade to an Apache Tomcat version
where that vulnerability has been fixed.
Source patches, usually in the form of references to SVN commits, may be
provided in either in a vulnerability announcement and/or the
vulnerability details listed on these pages. These source patches may be
used by users wishing to build their own local version of Tomcat with just
that security patch rather than upgrade. Please note that an exercise is
currently underway to add links to the svn commits for all the
vulnerabilities listed on these pages.
Lists of security problems fixed in released versions of Apache Tomcat
Lists of security problems fixed in versions of Apache Tomcat that may
be downloaded from the archives are also available:
The Apache Software Foundation takes a very active stance in eliminating
security problems and denial of service attacks against Apache Tomcat.
We strongly encourage folks to report such problems to our private
security mailing list first, before disclosing them in a public forum.
Please note that the security mailing list should only be used
for reporting undisclosed security vulnerabilities in Apache Tomcat and
managing the process of fixing such vulnerabilities. We cannot accept
regular bug reports or other queries at this address. All mail sent to
this address that does not relate to an undisclosed security problem in
the Apache Tomcat source code will be ignored.
If you need to report a bug that isn't an undisclosed security
vulnerability, please use the bug reporting
- how to configure Tomcat securely
- if a vulnerability applies to your particular application
- obtaining further information on a published vulnerability
- availability of patches and/or new releases
should be addressed to the users mailing list. Please see the
mailing lists page for details of how to
The private security mailing address is:
Note that all networked servers are subject to denial of service attacks,
and we cannot promise magic workarounds to generic problems (such as a
client streaming lots of data to your server, or re-requesting the same
URL repeatedly). In general our philosophy is to avoid any attacks which
can cause the server to consume resources in a non-linear relationship to
the size of inputs.
Please report any errors or omissions to