[CVE-2018-11759] Apache mod_jk access control bypass

DISCLAIMER: Article originally published on immunIT

Hi fellas,

I’m exiting to introduce you to a new vulnerability found by my colleague (Xel) and me during one of our pentesting engagements :slight_smile:

I almost had my first CVE on Wordpress a year ago but now here we are!

Vulnerability summary

  1. Due to discrepancies between the specifications of httpd and Tomcat for path handling, Apache mod_jk Connector 1.2.0 to 1.2.44 access controls to endpoints defined by a JkMount httpd directive can be bypassed.

  2. Notably, if a read-only JK status manager interface is available, it is possible to disclose the internal routes of AJP services served by mod_jk.

  3. Furthermore, if a read-write JK status manager interface is available, it is possible to hijack or shutdown all traffic traversing mod_jk by altering the configuration of AJP workers, or to conduct internal port scanning.

Technical details

Patch-diffing CVE-2018-1323

During a penetration test for one of our customers involving a load balancer/reverse-proxy based on Apache mod_jk serving JBoss/Tomcat webservers, we found out about vulnerability CVE-2018-1323 (reported by Alphan YAVAS from Biznet Bilisim A.S.) affecting mod_jk up to version 1.2.42.

After analyzing the mod_jk 1.2.43 patch to understand this vulnerability, we realized it was a path traversal based on discrepancies between how Apache httpd and Tomcat or other Java servers handled the semicolon character for path resolution.

Apache httpd interprets semicolons in URL as ordinary characters for path resolution, while Tomcat interprets them as query delimiters (with a similar functionality as “?”). Thus, an attacker could fetch a path such as http://server/java_app/..; did not trigger a path traversal for the logic of httpd, it was forwarded as is to the Tomcat webserver, which interpreted the string as .. .

This allowed to fetch resources that were not supposed to be accessible on the Tomcat webserver.


We have identified that the vulnerability was not fully understood, as the mod_jk patch did fix this specific path traversal attack against mod_jk, but not the core issue revolving around the handling of semicolons by mod_jk.

Playing with the JK Status Manager

The JK status manager is an administration interface for mod_jk. When set in read-write, it allows the configuration of AJP workers to connect to Java Web servers to proxy HTTP requests to them.
It is normally possible to restrict access to the JK status manager, for example by using httpd directives such as:

<Location /jkstatus>

JKMount jk-status
Require ip


This directive is supposed to prevent any external access to the JK status manager.


We found out that by injecting a semicolon behind the /jkstatus URL, it was possible to bypass such a restriction.


It is possible to submit GET parameters after this URL, so that state-changing requests can be made to the JK manager.


The impact of acccess bypass on the JK manager could be a denial of service of all applications served by mod_jk, by changing ports used by workers if the JK status manager is set with read-write access, and possibly the hijacking of all web applications served by mod_jk if an attacker connects the corresponding AJP workers to a server in his control.

It would also be theoretically possible to conduct internal TCP port scanning, by changing the destination and port of an AJP worker to an internal host and port, because of the discrepancy of error messages returned by the manager depending on whether the submitted AJP port is valid or not (Bad Gateway versus Service Unavailable). The full impact of this type of SSRF is unknown.


The JK manager (in read-only) also discloses the hostnames, IPs and ports of internal servers, routes that are served by mod_jk, and the absolute path of the httpd server on the filesystem.

This example of access bypass has a high impact. However, it has to be noted that access control to any endpoint defined through a JkMount directive could possibly be bypassed by a semicolon injection.


A patch is available for mod_jk (version 1.2.46).
Other mitigations include the use of Location values such as /jkstatus* , which seems to fix the issue.

Bug reference


Github POC

A Docker environment is available to test this vulnerability on our GitHub


  • 06/09/2018 : First contact with Apache Tomcat security team
  • 06/09/2018 : First response from Apache Tomcat security team
  • 13/10/2018 : mod_jk v1.2.46 fix is released
  • 31/10/2018 : CVE-2018-11759 advisory is issued
  • 01/11/2018 : Full disclosure

I hope you enjoyed your reading and find this finding interesting.



Wow man, this is awesome :slight_smile:

Congrats! How does it feel to have your first CVE?

1 Like

Feeling awesome mate. What is more, it’s a well known and widely used component which is affected by this finding, signifying that thousands of companies accross the world are vulnerable to this access bypass :wink:

1 Like

Talking of thousands of companies:

Has anybody been able to make a Shodan filter or a Google dork to find vulnerable hosts?

I don’t think so cause the Jk Status Manager interface has no default endpoint. Basically, you can assume that any Apache servers running with the module mod_jk below 1.2.46 is vulnerable to access bypass whatever the endpoint concerned.

1 Like

Secure interoperability between different systems seems to be a bit of an issue. Reminds me of attacks using discrepancies between url parsing and email address handling. I think I wouldn’t be surprised to see a lot more of this in the future.


This topic was automatically closed after 30 days. New replies are no longer allowed.