Apache Tomcat 6.x vulnerabilities

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

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

Please note that Tomcat 6.0.x is no longer supported. Further
vulnerabilities in the 6.0.x branch will not be fixed. Users should
upgrade to 7.x or later to obtain security fixes.

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

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

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

7 April 2017 Fixed in Apache Tomcat 6.0.53

A bug in the handling of the pipelined requests when send file was used
resulted in the pipelined request being lost when send file processing of
the previous request completed. This could result in responses appearing
to be sent for the wrong request. For example, a user agent that sent
requests A, B and C could see the correct response for request A, the
response for request C for request B and no response for request C.

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

Affects: 6.0.0 to 6.0.52

not yet released Fixed in Apache Tomcat 6.0.50

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

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.

15 November 2016 Fixed in Apache Tomcat 6.0.48

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

The code that parsed the HTTP request line permitted invalid characters.
This could be exploited, in conjunction with a proxy that also permitted
the invalid characters but with a different interpretation, to inject
data into the HTTP response. By manipulating the HTTP response the
attacker could poison a web-cache, perform an XSS attack and/or obtain
sensitive information from requests other then their own.

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

Affects: 6.0.0 to 6.0.47

16 October 2016 Fixed in Apache Tomcat 6.0.47

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

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.

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.

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.

11 February 2016 Fixed in Apache Tomcat 6.0.45

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

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

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

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

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

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

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

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

12 May 2015 Fixed in Apache Tomcat 6.0.44

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

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

Affects: 6.0.0 to 6.0.43

22 November 2014 Fixed in Apache Tomcat 6.0.43

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

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

Affects: 6.0.0 to 6.0.41

released 23 May 2014 Fixed in Apache Tomcat 6.0.41

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

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

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

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

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

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

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

Affects: 6.0.0-6.0.39

released 31 Jan 2014 Fixed in Apache Tomcat 6.0.39

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

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

content-length header with chunked encoding over any HTTP connector

multiple content-length headers over any AJP connector

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

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

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

Previous fixes to path parameter handling
(1149220) introduced a regression that
meant session IDs provided in the URL were considered even when
disableURLRewriting was configured to true. Note that the session is only
used for that single request.

released 3 May 2013 Fixed in Apache Tomcat 6.0.37

FORM authentication associates the most recent request requiring
authentication with the current session. By repeatedly sending a request
for an authenticated resource while the victim is completing the login
form, an attacker could inject a request that would be executed using
the victim's credentials.

Note that the option to change session ID on authentication was added in
Tomcat 6.0.21. In earlier 6.0.x releases, prevention of session fixation
was an application responsibility. This vulnerability represents a bug in
Tomcat's session fixation protection that was added in 6.0.21.
Hence, only versions 6.0.21 onwards are listed as vulnerable.

When processing a request submitted using the chunked transfer encoding,
Tomcat ignored but did not limit any extensions that were included. This
allows a client to perform a limited DOS by streaming an unlimited
amount of data to the server.

released 19 Oct 2012 Fixed in Apache Tomcat 6.0.36

The checks that limited the permitted size of request headers were
implemented too late in the request parsing process for the HTTP NIO
connector. This enabled a malicious user to trigger an
OutOfMemoryError by sending a single request with very large headers.

The first issue was reported by Tilmann Kuhn to the Tomcat security team
on 19 July 2012. The second and third issues were discovered by the
Tomcat security team during the resulting code review. All three issues
were made public on 5 November 2012.

When using FORM authentication it was possible to bypass the security
constraint checks in the FORM authenticator by appending
/j_security_check to the end of the URL if some other
component (such as the Single-Sign-On valve) had called
request.setUserPrincipal() before the call to
FormAuthenticator#authenticate().

When using the NIO connector with sendfile and HTTPS enabled, if a client
breaks the connection while reading the response an infinite loop is
entered leading to a denial of service. This was originally reported as
bug
52858.

The security implications of this bug were reported to the Tomcat
security team by Arun Neelicattu of the Red Hat Security Response Team on
3 October 2012 and made public on 4 December 2012.

Affects: 6.0.0-6.0.35

released 5 Dec 2011 Fixed in Apache Tomcat 6.0.35

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

For performance reasons, information parsed from a request is often
cached in two places: the internal request object and the internal
processor object. These objects are not recycled at exactly the same
time. When certain errors occur that needed to be added to the access
log, the access logging process triggers the re-population of the request
object after it has been recycled. However, the request object was not
recycled before being used for the next request. That lead to information
leakage (e.g. remote IP address, HTTP headers) from the previous request
to the next request. The issue was resolved be ensuring that the request
and response objects were recycled after being re-populated to generate
the necessary access log entries.

Apache Tomcat supports the AJP protocol which is used with reverse
proxies to pass requests and associated data about the request from the
reverse proxy to Tomcat. The AJP protocol is designed so that when a
request includes a request body, an unsolicited AJP message is sent to
Tomcat that includes the first part (or possibly all) of the request
body. In certain circumstances, Tomcat did not process this message as a
request body but as a new request. This permitted an attacker to have
full control over the AJP message permitting authentication bypass and
information disclosure. This vulnerability only occurs when all of the
following are true:

Configure both Tomcat and the reverse proxy to use a shared secret.
(It is "request.secret" attribute in AJP <Connector>,
"worker.workername.secret" directive for mod_jk.
The mod_proxy_ajp module currently does not support shared secrets).

Use the org.apache.jk.server.JkCoyoteHandler (BIO) AJP connector
implementation.
(It is automatically selected if you do not have Tomcat-Native library
installed. It can be also selected explicitly:
<Connector protocol="org.apache.jk.server.JkCoyoteHandler">).

Analysis of the recent hash collision vulnerability identified unrelated
inefficiencies with Apache Tomcat's handling of large numbers of
parameters and parameter values. These inefficiencies could allow an
attacker, via a specially crafted request, to cause large amounts of CPU
to be used which in turn could create a denial of service. The issue was
addressed by modifying the Tomcat parameter handling code to efficiently
process large numbers of parameters and parameter values.

released 18 Aug 2011 Fixed in Apache Tomcat 6.0.33

Note: Mitre elected to break this issue down into multiple issues and
have allocated the following additional references to parts of this
issue:
CVE-2011-5062,
CVE-2011-5063 and
CVE-2011-5064. The Apache Tomcat security team will
continue to treat this as a single issue using the reference
CVE-2011-1184.

The implementation of HTTP DIGEST authentication was discovered to have
several weaknesses:

replay attacks were permitted

server nonces were not checked

client nonce counts were not checked

qop values were not checked

realm values were not checked

the server secret was hard-coded to a known string

The result of these weaknesses is that DIGEST authentication was only as
secure as BASIC authentication.

When using the MemoryUserDatabase (based on tomcat-users.xml) and
creating users via JMX, an exception during the user creation process may
trigger an error message in the JMX client that includes the user's
password. This error message is also written to the Tomcat logs. User
passwords are visible to administrators with JMX access and/or
administrators with read access to the tomcat-users.xml file. Users that
do not have these permissions but are able to read log files may be able
to discover a user's password.

Tomcat provides support for sendfile with the HTTP NIO and HTTP APR
connectors. sendfile is used automatically for content served via the
DefaultServlet and deployed web applications may use it directly via
setting request attributes. These request attributes were not validated.
When running under a security manager, this lack of validation allowed a
malicious web application to do one or more of the following that would
normally be prevented by a security manager:

return files to users that the security manager should make
inaccessible

terminate (via a crash) the JVM

Additionally, these vulnerabilities only occur when all of the following
are true:

Due to a bug in the capabilities code, jsvc (the service wrapper for
Linux that is part of the Commons Daemon project) does not drop
capabilities allowing the application to access files and directories
owned by superuser. This vulnerability only occurs when all of the
following are true:

Tomcat is running on a Linux operating system

jsvc was compiled with libcap

-user parameter is used

Affected Tomcat versions shipped with source files for jsvc that included
this vulnerability.

This was identified by Wilfried Weissmann on 20 July 2011 and made public
on 12 August 2011.

Affects: 6.0.30-6.0.32

released 03 Feb 2011 Fixed in Apache Tomcat 6.0.32

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

When running under a SecurityManager, access to the file system is
limited but web applications are granted read/write permissions to the
work directory. This directory is used for a variety of temporary files
such as the intermediate files generated when compiling JSPs to Servlets.
The location of the work directory is specified by a ServletContect
attribute that is meant to be read-only to web applications. However,
due to a coding error, the read-only setting was not applied. Therefore,
a malicious web application may modify the attribute before Tomcat
applies the file permissions. This can be used to grant read/write
permissions to any area on the file system which a malicious web
application may then take advantage of. This vulnerability is only
applicable when hosting web applications from untrusted sources such as
shared hosting environments.

This was discovered by the Tomcat security team on 12 Oct 2010 and
made public on 5 Feb 2011.

Affects: 6.0.0-6.0.29

released 9 Jul 2010 Fixed in Apache Tomcat 6.0.28

Important: Remote Denial Of Service and Information Disclosure
VulnerabilityCVE-2010-2227

Several flaws in the handling of the 'Transfer-Encoding' header were
found that prevented the recycling of a buffer. A remote attacker could
trigger this flaw which would cause subsequent requests to fail and/or
information to leak between requests. This flaw is mitigated if Tomcat is
behind a reverse proxy (such as Apache httpd 2.2) as the proxy should
reject the invalid transfer encoding header.

This was first reported to the Tomcat security team on 14 Jun 2010 and
made public on 9 Jul 2010.

Affects: 6.0.0-6.0.27

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

The WWW-Authenticate HTTP header for BASIC and DIGEST
authentication includes a realm name. If a
<realm-name> element is specified for the application
in web.xml it will be used. However, a <realm-name>
is not specified then Tomcat will generate realm name using the code
snippet request.getServerName() + ":" +
request.getServerPort(). In some circumstances this can expose
the local host name or IP address of the machine running Tomcat.

This was first reported to the Tomcat security team on 31 Dec 2009 and
made public on 21 Apr 2010.

Affects: 6.0.0-6.0.26

released 21 Jan 2010 Fixed in Apache Tomcat 6.0.24

Note:These issues were fixed in Apache Tomcat 6.0.21 but the
release votes for the 6.0.21, 6.0.22 and 6.0.23 release candidates did
not pass. Therefore, although users must download 6.0.24 to obtain a
version that includes fixes for these issues, versions 6.0.21 onwards
are not included in the list of affected versions.

When deploying WAR files, the WAR files were not checked for directory
traversal attempts. This allows an attacker to create arbitrary content
outside of the web root by including entries such as
../../bin/catalina.sh in the WAR.

By default, Tomcat automatically deploys any directories placed in a
host's appBase. This behaviour is controlled by the autoDeploy attribute
of a host which defaults to true. After a failed undeploy, the remaining
files will be deployed as a result of the autodeployment process.
Depending on circumstances, files normally protected by one or more
security constraints may be deployed without those security constraints,
making them accessible without authentication. This issue only affects
Windows platforms.

When deploying WAR files, the WAR file names were not checked for
directory traversal attempts. For example, deploying and undeploying
...war allows an attacker to cause the deletion of the
current contents of the host's work directory which may cause problems
for currently running applications.

The Windows installer defaults to a blank password for the administrative
user. If this is not changed during the install process, then by default
a user is created with the name admin, roles admin and manager and a
blank password.

This was first reported to the Tomcat security team on 26 Oct 2009 and
made public on 9 Nov 2009.

Affects: 6.0.0-6.0.20

released 3 Jun 2009 Fixed in Apache Tomcat 6.0.20

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

When using a RequestDispatcher obtained from the Request, the target path
was normalised before the query string was removed. A request that
included a specially crafted request parameter could be used to access
content that would otherwise be protected by a security constraint or by
locating it in under the WEB-INF directory.

If Tomcat receives a request with invalid headers via the Java AJP
connector, it does not return an error and instead closes the AJP
connection. In case this connector is member of a mod_jk load balancing
worker, this member will be put into an error state and will be blocked
from use for approximately one minute. Thus the behaviour can be used for
a denial of service attack using a carefully crafted request.

Due to insufficient error checking in some authentication classes, Tomcat
allows for the enumeration (brute force testing) of user names by
supplying illegally URL encoded passwords. The attack is possible if FORM
based authentication (j_security_check) is used with the MemoryRealm.

Bugs 29936 and 45933 allowed a web application
to replace the XML parser used by
Tomcat to process web.xml, context.xml and tld files. In limited
circumstances these bugs may allow a rogue web application to view and/or
alter the web.xml, context.xml and tld files of other web applications
deployed on the Tomcat instance.

This was first reported to the Tomcat security team on 2 Mar 2009 and
made public on 4 Jun 2009.

Affects: 6.0.0-6.0.18

released 31 Jul 2008 Fixed in Apache Tomcat 6.0.18

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

The message argument of HttpServletResponse.sendError() call is not only
displayed on the error page, but is also used for the reason-phrase of
HTTP response. This may include characters that are illegal in HTTP
headers. It is possible for a specially crafted message to result in
arbitrary content being injected into the HTTP response. For a successful
XSS attack, unfiltered user supplied data must be included in the message
argument.

The Host Manager web application did not escape user provided data before
including it in the output. This enabled a XSS attack. This application
now filters the data before use. This issue may be mitigated by logging
out (closing the browser) of the application once the management tasks
have been completed.

When using a RequestDispatcher the target path was normalised before the
query string was removed. A request that included a specially crafted
request parameter could be used to access content that would otherwise be
protected by a security constraint or by locating it in under the WEB-INF
directory.

The JULI logging component allows web applications to provide their own
logging configurations. The default security policy does not restrict
this configuration and allows an untrusted web application to add files
or overwrite existing files where the Tomcat process has the necessary
file permissions to do so.

When Tomcat's WebDAV servlet is configured for use with a context and
has been enabled for write, some WebDAV requests that specify an entity
with a SYSTEM tag can result in the contents of arbitary files being
returned to the client.

When using the native (APR based) connector, connecting to the SSL port
using netcat and then disconnecting without sending any data will cause
tomcat to handle a duplicate copy of one of the recent requests.

If an exception occurs during the processing of parameters (eg if the
client disconnects) then it is possible that the parameters submitted for
that request will be incorrectly processed as part of a subsequent
request.

Affects: 6.0.5-6.0.15

released 13 Aug 2007 Fixed in Apache Tomcat 6.0.14

JSPs within the examples web application did not escape user provided
data before including it in the output. This enabled a XSS attack. These
JSPs now filter the data before use. This issue may be mitigated by
undeploying the examples web application. Note that it is recommended
that the examples web application is not installed on a production
system.

The Manager and Host Manager web applications did not escape user
provided data before including it in the output. This enabled a XSS
attack. These applications now filter the data before use. This issue may
be mitigated by logging out (closing the browser) of the application once
the management tasks have been completed.

not released Fixed in Apache Tomcat 6.0.11

The JSP and Servlet included in the sample application within the Tomcat
documentation webapp did not escape user provided data before including
it in the output. This enabled a XSS attack. These pages have been
simplified not to use any user provided data in the output.

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

Affects: 6.0.0-6.0.10

released 28 Feb 2007 Fixed in Apache Tomcat 6.0.10

Tomcat permits '\', '%2F' and '%5C' as path delimiters. When Tomcat is used
behind a proxy (including, but not limited to, Apache HTTP server with
mod_proxy and mod_jk) configured to only proxy some contexts, a HTTP request
containing strings like "/\../" may allow attackers to work around the context
restriction of the proxy, and access the non-proxied contexts.

The following Java system properties have been added to Tomcat to provide
additional control of the handling of path delimiters in URLs (both options
default to false):

released 8 Feb 2007 Fixed in Apache Tomcat 6.0.9

When using the SingleSignOn Valve via https the Cookie JSESSIONIDSSO is
transmitted without the "secure" attribute, resulting in it being
transmitted to any content that is - by purpose or error - requested via
http from the same server.

Affects: 6.0.0-6.0.8

released 18 Dec 2006 Fixed in Apache Tomcat 6.0.6

Web pages that display the Accept-Language header value sent by the
client are susceptible to a cross-site scripting attack if they assume
the Accept-Language header value conforms to RFC 2616. Under normal
circumstances this would not be possible to exploit, however older
versions of Flash player were known to allow carefully crafted malicious
Flash files to make requests with such custom headers. When generating
the response for getLocale() and getLocales(),
Tomcat now ignores values for Accept-Language headers that do not conform
to RFC 2616. Applications that use the raw header values directly should
not assume that the headers conform to RFC 2616 and should filter the
values appropriately.

Affects: 6.0.0-6.0.5

Not a vulnerability in Tomcat

Sending an HTTP request 1 byte at a time will consume a thread from the
connection pool until the request has been fully processed if using the
BIO or APR/native HTTP connectors. Multiple requests may be used to
consume all threads in the connection pool thereby creating a denial of
service.

Since the relationship between the client side resources and server side
resources is a linear one, this issue is not something that the Tomcat
Security Team views as a vulnerability. This is a generic DoS problem and
there is no magic solution. This issue has been discussed several times
on the Tomcat mailing lists. The best place to start to review these
discussions is the report for
bug
54236.

This was first discussed on the public Tomcat users mailing list on 19
June 2009.

A JVM bug could cause Double conversion to hang JVM when accessing to a
form based security constrained page or any page that calls
javax.servlet.ServletRequest.getLocale() or
javax.servlet.ServletRequest.getLocales(). A specially crafted request
can be used to trigger a denial of service.

A work-around for this JVM bug was provided in
revision 1066315.
This work-around is included in Tomcat 6.0.32 onwards.

This was first reported to the Tomcat security team on 01 Feb 2011 and
made public on 31 Jan 2011.

A vulnerability exists in the TLS protocol that allows an attacker to
inject arbitrary requests into an TLS stream during renegotiation.

The TLS implementation used by Tomcat varies with connector. The blocking
IO (BIO) and non-blocking (NIO) connectors use the JSSE implementation
provided by the JVM. The APR/native connector uses OpenSSL.

The BIO connector is vulnerable if the JSSE version used is vulnerable.
To workaround this until a fix is available in JSSE, a new connector
attribute allowUnsafeLegacyRenegotiation has been added to
the BIO connector. It should be set to false (the default)
to protect against this vulnerability.

The NIO connector is not vulnerable as it does not support
renegotiation.

Users should be aware that the impact of disabling renegotiation will
vary with both application and client. In some circumstances disabling
renegotiation may result in some clients being unable to access the
application.

A workaround was implemented in
revision 881774 and
revision 891292
that provided the new allowUnsafeLegacyRenegotiation
attribute. This work around is included in Tomcat 6.0.21 onwards.

Support for the new TLS renegotiation protocol (RFC 5746) that does not
have this security issue:

For connectors using JSSE implementation provided by JVM:
Added in Tomcat 6.0.32.
Requires JRE that supports RFC 5746. For Oracle JRE that is
known
to be 6u22 or later.

Originally reported as a Tomcat vulnerability the root cause of this
issue is that the JVM does not correctly decode UTF-8 encoded URLs to
UTF-8. This exposes a directory traversal vulnerability when the
connector uses URIEncoding="UTF-8". This directory traversal
is limited to the docBase of the web application.

If a context is configured with allowLinking="true" then the
directory traversal vulnerability is extended to the entire file system
of the host server.

It should also be noted that setting
useBodyEncodingForURI="true" has the same effect as setting
URIEncoding="UTF-8" when processing requests with bodies
encoded with UTF-8.

Although the root cause was quickly identified as a JVM issue and that it
affected multiple JVMs from multiple vendors, it was decided to report
this as a Tomcat vulnerability until such time as the JVM vendors
provided updates to resolve this issue. For further information on the
status of this issue for your JVM, contact your JVM vendor.

A workaround was implemented in
revision 678137
that protects against this and any similar character
encoding issues that may still exist in the JVM. This work around is
included in Tomcat 6.0.18 onwards.

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

An explanation of how to deterine whether you are vulnerable and what
steps to take, see the Tomcat Wiki's
Heartbleed
page.