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