Content

Table of Contents

Apache Tomcat JK Connectors vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat Jk Connectors. 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 JK Connectors the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

This page has been created from a review of the Apache Tomcat archives and the CVE list. Please send comments or corrections for these vulnerabilities to the Tomcat Security Team.

Fixed in Apache Tomcat JK Connector 1.2.49

Important: Information disclosure CVE-2023-41081

In some circumstances, such as when a configuration included JkOptions +ForwardDirectories but the configuration did not provide explicit mounts for all possible proxied requests, mod_jk would use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected.

This was fixed with commit 0095b6cb.

This issue was reported to the Tomcat Security Team on 7 July 2023. The issue was made public on 13 September 2023.

Affects: JK 1.2.0-1.2.48 (mod_jk only)

Fixed in Apache Tomcat JK Connector 1.2.46

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

Important: Information disclosure CVE-2018-11759

The Apache Web Server (httpd) specific code that normalised the requested path before matching it to the URI-worker map did not handle some edge cases correctly. If only a sub-set of the URLs supported by Tomcat were exposed via httpd, then it was possible for a specially constructed request to expose application functionality through the reverse proxy that was not intended for clients accessing the application via the reverse proxy. It was also possible in some configurations for a specially constructed request to bypass the access controls configured in httpd. While there is some overlap between this issue and CVE-2018-1323, they are not identical.

This was fixed in revisions 1838836, 1838857, 1838871, 1838882, 1840444, 1840445, 1840448, 1840449, 1840450, 1840451, 1840491, 1840588, 1840592, 1840603, 1840604, 1840610, 1840629 and 1841463.

Affects: JK 1.2.0-1.2.44

Fixed in Apache Tomcat JK Connector 1.2.43

Important: Information disclosure CVE-2018-1323

The IIS/ISAPI specific code that normalised the requested path before matching it to the URI-worker map did not handle some edge cases correctly. If only a sub-set of the URLs supported by Tomcat were exposed via IIS, then it was possible for a specially constructed request to expose application functionality through the reverse proxy that was not intended for clients accessing the application via the reverse proxy.

This was fixed in revision 1825658.

Affects: JK 1.2.0-1.2.42

Fixed in Apache Tomcat JK Connector 1.2.42

Moderate: Buffer Overflow CVE-2016-6808

The IIS/ISAPI specific code implements special handling when a virtual host is present. The virtual host name and the URI are concatenated to create a virtual host mapping rule. The length checks prior to writing to the target buffer for this rule did not take account of the length of the virtual host name, creating the potential for a buffer overflow.

It is not known if this overflow is exploitable.

This was fixed in revision 1762057.

Affects: JK 1.2.0-1.2.41

Fixed in Apache Tomcat JK Connector 1.2.41

Important: Information disclosure CVE-2014-8111

Multiple adjacent slashes in a request URI were not collapsed to a single slash before comparing the request URI to the configured mount and unmount patterns. It is therefore possible for an attacker to use a request URI containing multiple adjacent slashes to bypass the restrictions of a JkUnmount directive. This may expose application functionality through the reverse proxy that is not intended for clients accessing the application via the reverse proxy.

As of mod_jk 1.2.41, slashes are collapsed by default. The behaviour is now configurable via a new JkOption for httpd (values CollapseSlashesAll, CollapseSlashesNone or CollapseSlashesUnmount) and via a new property collapse_slashes for IIS (values all, none, unmount).

This was fixed in revision 1647017.

Affects: JK 1.2.0-1.2.40

Fixed in Apache Tomcat JK Connector 1.2.27

Important: Information disclosure CVE-2008-5519

Situations where faulty clients set Content-Length without providing data, or where a user submits repeated requests very quickly, may permit one user to view the response associated with a different user's request.

This was fixed in revision 702540.

Affects: JK 1.2.0-1.2.26
Source shipped with Tomcat 4.0.0-4.0.6, 4.1.0-4.1.36, 5.0.0-5.0.30, 5.5.0-5.5.27

Fixed in Apache Tomcat JK Connector 1.2.23

Important: Information disclosure CVE-2007-1860

The issue is related to CVE-2007-0450, the patch for which was insufficient.

When multiple components (firewalls, caches, proxies and Tomcat) process a request, the request URL should not get decoded multiple times in an iterative way by these components. Otherwise it might be possible to pass access control rules implemented on front of the last component by applying multiple URL encoding to the request.

mod_jk before version 1.2.23 by default decoded request URLs inside Apache httpd and forwarded the encoded URL to Tomcat, which itself did a second decoding. This made it possible to pass a prefix JkMount for /someapp, but actually access /otherapp on Tomcat. Starting with version 1.2.23 by default mod_jk forwards the original unchanged request URL to Tomcat. You can achieve the same level of security for older versions by setting the forwarding option "JkOption ForwardURICompatUnparsed".

Please note, that your configuration might contain a different forwarding JkOption. In this case, please consult the forwarding documentation concerning the security implications. The new default setting is more secure than before, but it breaks interoperability with mod_rewrite.

Affects: JK 1.2.0-1.2.22 (httpd mod_jk module only)
Source shipped with Tomcat 4.0.0-4.0.6, 4.1.0-4.1.36, 5.0.0-5.0.30, 5.5.0-5.5.23

Fixed in Apache Tomcat JK Connector 1.2.21

Critical: Arbitrary code execution and denial of service CVE-2007-0774

An unsafe memory copy in the URI handler for the native JK connector could result in a stack overflow condition which could be leveraged to execute arbitrary code or crash the web server.

Affects: JK 1.2.19-1.2.20
Source shipped with: Tomcat 4.1.34, 5.5.20

Fixed in Apache Tomcat JK Connector 1.2.16

Important: Information disclosure CVE-2006-7197

The Tomcat AJP connector contained a bug that sometimes set a too long length for the chunks delivered by send_body_chunks AJP messages. Bugs of this type can cause mod_jk to read beyond buffer boundaries and thus reveal sensitive memory information to a client.

Affects: JK 1.2.0-1.2.15
Source shipped with: Tomcat 4.0.0-4.0.6, 4.1.0-4.1.32, 5.0.0-5.0.30, 5.5.0-5.5.16