How I Found a Local File Inclusion in DHL

While reviewing the httpx-toolkit output for DHL subdomains, I found a host that appeared to be using both Java and Nginx.

Seeing Java and Nginx together was interesting because this often indicates a Java backend, such as Tomcat, sitting behind an Nginx reverse proxy. This setup can sometimes introduce Vulnerablities if not strictly configured.

After visiting the website, I was redirected to a login page on the same subdomain. I then tried visiting the parent directory, which returned a 401 Unauthorized response.

The response confirmed that the backend was running Apache Tomcat and the application was sitting behind Nginx as a reverse proxy.

So I tried a few easy-to-guess credentials, but none of them worked.

At that point, I remembered reading about a "path traversal inconsistency between Nginx and Tomcat". The issue is documented here The idea is that Nginx normalizes normal traversal sequences like ../ but not ..;/ .

Tomcat, on the other hand, treats ..;/ similarly to ../. This creates an inconsistency between the reverse proxy and the backend server.

For example, if the request path is /test/..;/path Nginx will forward the request as-is because it does not normalize ..;/. But when Tomcat receives the request, it interprets it as **/path.**This means an attacker can trick the reverse proxy into forwarding a path that reaches backend resources that were not meant to be exposed externally.

So I started testing a few paths manually, but I didn't find anything useful

After that, I started fuzzing the path: /dpdhltest/..;/FUZZ

I discovered that jolokia returned a 200, now I had confirmed access to a backend service through the reverse proxy mapping issue, but simply reaching Jolokia does not immediately provide strong impact by itself, so I continued testing.

Jolokia is known to expose powerful management functionality depending on its configuration. Some useful Jolokia exploitation techniques can be found in this repo. One of the techniques that worked in this case was abusing the "DiagnosticCommand" MBean to read local files. using this url :

https://subdomain.example.com/dpdhltest/..;/jolokia/exec/com.sun.management:type=DiagnosticCommand/compilerDirectivesAdd/!/etc!/passwd

https://subdomain.example.com/dpdhltest/..;/jolokia/exec/com.sun.management:type=DiagnosticCommand/compilerDirectivesAdd/!/etc!/passwd

The response contained the contents of /etc/passwd, confirming a working Local File Inclusion vulnerability.

At this point, the vulnerability had clear impact because an unauthenticated attacker could reach an internal Jolokia endpoint through the Nginx/Tomcat path normalization inconsistency and use it to read local files from the server.

I stopped testing after confirming local file read and reported the issue.

The report was accepted in DHL's VDP program on Intigriti.

2- Bypassing the Fix

About a week after the report was created, I received a notification from the team saying that the issue had been resolved.

I revisited the website to validate the fix.

At first glance, it looked like they had added an Nginx rule to block access to the jolokia endpoint. But I wanted to understand how the rule was implemented.

So I requested other non-existing backend paths through the same reverse proxy mapping issue, such as /dpdhltest/..;/test, the request was still forwarded to the backend and returned a Tomcat 404 response.

This showed that the reverse proxy mapping issue itself was still present. Only direct access to paths containing jolokia appeared to be blocked.

Based on that behavior, the fix looked like a string-based filter rather than a proper normalization or access-control fix.

To confirm this, I tried bypassing the filter by adding a normal path traversal segment before the protected endpoint: /dpdhltest/..;/test/../jolokia.

Which would bypass the rule by not starting with jolokia directly after /dpdhltest/..;/ , and at the same time having the same effect as accessing jolokia directly.

This worked ! the jolokia endpoint is successfully accessed and returns a valid response.

Now we can exploit Local File Inclusion through it the same way as before

This confirmed that the initial fix was incomplete.

In this case, the best remediation is not only to block the literal string jolokia, but to ensure that internal management endpoints could not be reached from the public reverse proxy path at all, regardless of path normalization tricks.

I reported the bypass to the program again. After that, they made additional changes at the access-control level, which was the more appropriate fix for this issue.

Thanks for reading this writeup. I'm usually too lazy to document every finding, but I'll try to publish anything interesting enough.

Here is a video by NahamSec covering a similar finding. In his case, he was able to escalate it further to RCE.