ManageEngine Exchange Reporter Plus is a web-based tool for managing and monitoring Exchange Server and Exchange Online environments. It offers over 450 built-in reports on mailboxes, email traffic, user activity, and permissions. The tool supports real-time alerts, change auditing, and mailbox content search to ensure compliance. It also provides 24/7 health monitoring to detect and resolve issues proactively. This is a comprehensive solution for Exchange administrators—no scripting required.

Introduction

I would like to sincerely thank my brother Linhdd8, as well as the team leads in our team, for their trust in recommending ManageEngine Exchange Reporter Plus as a target — and for giving me the time and freedom to dive into it. This exploration became a valuable opportunity to understand how enterprise monitoring systems work and laid the foundation for analyzing similar applications in corporate environments.

This write-up details the discovery and exploitation of two Remote Code Execution (RCE) design flaws in Exchange Reporter Plus version 5721.

After approximately 5 hours of reverse engineering and environment setup, I was able to deploy Exchange Reporter Plus and integrate it with a functioning mail server. Within the next 2 hours of dynamic testing and traffic inspection, I identified two vulnerabilities—both stemming from flawed design decisions—that under specific conditions could be leveraged for remote code execution.

Both vulnerabilities were located within the Content Search module, which is responsible for handling mailbox queries.

The First Clue

While using this feature under normal conditions, I noticed something suspicious about the file preview functionality. Specifically, I had to click twice to view the contents of an attachment, which seemed unusual.

The file is rendered at the following path /exchange/mail-attachments/<random>+filename:

http://localhost:8181/exchange/mail-attachments/201document.txt

As seen, several concerns arise:

• The filename is not sanitized and is directly reflected in the browser context → Possible XSS.

• Accessing the file requires two clicks, and the file is originally an attachment from an Exchange mail → This suggests that Exchange Reporter Server might be fetching the file from the Exchange Server on demand → Potential for Path Traversal.

Path Traversal to RCE

A quick review of the code execution flow when clicking "view file" reveals the following:

ContentSearchHandler.getBody
 ->  customReportsHandler.gatherReportData
     ->  ContentSearchProfile.downlaodAttachment

On the first click, the application invokes CustomReportsHandler.gatherReportData to silently fetch the file using native code (which I won’t analyze in detail here). After that, the file is served through the API via ContentSearchProfile.downlaodAttachment (yes, that’s a typo in the method name—an indication that this processing flow may contain deeper issues).

The downlaodAttachment method parses the file content and wraps it into a JSON response, which is then returned to the user via the API. It does not handle file storage on the server—this part is implemented separately in native code, outside the Java source.

That said, the overall code logic strongly suggests that data returned from the Exchange Server is fully trusted, without proper validation or sanitization. As a result, this behavior may be exploitable via a path traversal attack.

  public static JSONObject downlaodAttachment(Long reportId, String id, String filename) throws Exception {
        JSONObject jSONObject = new JSONObject();
        try {
                    ......
            String attName = row.get("FILE_NAME").toString().replace("][", ",").replace("[", "").replace("]", "");
            String fileLocation = row.get("FILE_DOWNLOADED_LOCATION").toString().replace("][", ",").replace("[", "").replace("]", "");
            String file_size = row.get("FILE_SIZE").toString().replace("][", ",").replace("[", "").replace("]", "");
            String[] split = attName.split(",");
            String[] down = fileLocation.split(",");
            String[] size = file_size.split(",");
            JSONArray jsonArray = new JSONArray();
            String mailAttachment = null;
            for (int i = 0; i < split.length && i < down.length && i < size.length; i++) {
                JSONObject jsonObject = new JSONObject();
                String name = split[i];
                jsonObject.put("tileName", name);
                if (name.length() > 18) {
                    name = name.substring(0, 15) + Constants.ATTRVAL_PARENT;
                }
                jsonObject.put("fileName", name);
                if (down[i].indexOf("mail-attachments") != -1) {
                    mailAttachment = "true";
                    jsonObject.put("downloadedLocation", "../exchange/" + down[i].substring(down[i].indexOf("mail-attachments")));
                } else {
                    mailAttachment = null;

After reviewing the documentation, I found that email attachments are stored at:

C:\Program Files\ManageEngine\Exchange Reporter Plus\webapps\erp\mail-attachments

By simply sending an email with an attachment named ..\test.txt, I was able to confirm a path traversal vulnerability.

Since the Exchange Reporter Server runs with elevated privileges, I demonstrated Remote Code Execution (RCE) by uploading a .exe file that overwrites a scheduled task (cronjob).

From XSS to RCE via UNC Path

As previously mentioned, the file is displayed at /exchange/mail-attachments/+filename. The application allows viewing the file on the web without changing its extension. It has a filter to prevent rendering of .html files, but it misses svg files. As a result, it's easy to trigger an unauthenticated XSS bug.

Turning XSS into RCE — but how?

With some focused analysis, I eventually identified a viable attack chain. One of the application's features allows users to create automated daily reports, and it includes a configuration option called storage path, which accepts user-supplied absolute paths on the server filesystem.

This report generation feature was vulnerable to path traversal, which allowed the injection of UNC paths (e.g., \attacker.com\share) — a flaw that was later patched in version 5724.

When a UNC path was supplied instead of a valid local server path, the application would display an error on the frontend. However, under the hood, it still attempted to access the remote share, resulting in the SMB server controlled by the attacker receiving an incoming request.

👉 This allowed the attacker to harvest NTLM challenge-response hashes from the Exchange Reporter Plus server.

Full Exploitation Chain

The complete attack chain looks like this:

1. Unauthenticated XSS via a malicious .svg file.

2. Use the XSS payload to send a crafted request to the server that creates a scheduled report, setting the storage path to a UNC location.

3. The server attempts to write to the UNC path → NTLM authentication request is sent.

4. Attacker captures the NTLM response and cracks it offline.

5. Use the recovered credentials to log into other internal services → potential for lateral movement or full RCE.

End of the Week

Additional Findings Besides the two RCE chains discussed above, further vulnerabilities were discovered in Exchange Reporter Plus version 5721, including:

• ReDoS (Regular Expression Denial of Service) vulnerability.

• 5+ unauthenticated XSS vulnerabilities.

Update

Following responsible disclosure, the Exchange Reporter Plus team acknowledged the vulnerabilities and assigned CVE identifiers. The issues were addressed in a series of patches released from version 5722 through 5724.

https://www.manageengine.com/products/exchange-reports/release-notes.html