# Two RCE Design Flaws in ManageEngine Exchange Reporter Plus 5721

**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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753804384099/7ea99625-558f-41a9-b60f-fc9a433ed8b0.png align="center")

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

```plaintext
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:

```plaintext
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).

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753804396962/53c99ae5-92fb-4ca6-9ab9-dcd440f98b15.png align="center")

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.

```plaintext
  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:

```plaintext
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).

%[https://www.youtube.com/watch?v=jkk8eTgd6aM] 

# 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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753805323694/5eb0bb44-35ec-4a46-8b65-49f16d47f8bc.png align="center")

# **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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753805858829/0cbdd352-85fc-4a56-be1b-a94a16a09ab6.png align="center")

This report generation feature was vulnerable to path traversal, which allowed the injection of UNC paths (e.g., \\[attacker.com](http://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**.
    

%[https://www.youtube.com/watch?v=NYgNPvhv-90] 

# 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](https://www.manageengine.com/products/exchange-reports/release-notes.html)