Full Report
Client-side path traversal (CSPT) is a vulnerability where routing decisions can be controlled by a user-controlled value in the PATH parameter. For instance, the ID in the URL is set to ../../ID. On the frontend, this is then used on an API request. However, the ../../ID can change the routing of the request. Cross-site request forgery (CSRF) is a classic vulnerability that has become harder and harder to do over time with A) knowledge of it and B) browser protections like same-site cookies. They wanted to combine these issues to allow for CSRF to still work in some cases. CSPT will route a legitimate request. This can be used for CSRF-like attacks. Much of the time, there is no control over the HTTP method, headers, or body of the requests. Sometimes, data is returned and then acted upon. When using a GET sink for CSPT, there is sometimes a response that contains the ID that is then used on future requests, such as state-changing POST requests. This allows for forcing the user to create arbitrary requests that shouldn't usually be possible. There's a key to this though: what data do we want to be returned from the GET request? The attacker must control the ID or routing value of the JSON. This can be achieved by exploiting file upload/download features to contain the content initially. Then, the state-changing action can occur. They found an instance of this on the Mattermost chat application. An ID for telem_run_id in the URL was used in the routing that was vulnerable to CSPT. The only data being returned in the response that can be used is the action. This provides a minimal CSRF vuln with specific restrictions. The whitepaper describes how important it is to know the limitations. Once you have this, you can explore more effective ways to exploit the issue. In this case, a single parameter is controlled in the POST request. However, arbitrary data can be put onto the path, including parameters. Knowing these restrictions, they noticed that the plugin installation process only required a single URL parameter. So, this led to RCE! On Mattermost, they discovered a GET-to-POST-based sink. They uploaded a file to /api/v4/files to then use the returned data from the GET request in the POST request. Same as the previous issue, this led to RCE via URL parameters. Overall, this is a good bug class to call out. It's somewhat new, which means many applications are likely to be vulnerable to it. It's a first-come-first-server game!
Analysis Summary
# Vulnerability: RCE via Client-Side Path Traversal (CSPT) in Mattermost
## CVE Details
* **CVE ID:** Not explicitly stated in the text (often associated with Mattermost's internal tracking for CSPT findings).
* **CVSS Score:** Estimated 9.8 (Critical) – Based on the Remote Code Execution (RCE) outcome.
* **CWE:** CWE-352 (Cross-Site Request Forgery), CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).
## Affected Systems
* **Products:** Mattermost Chat Application.
* **Versions:** Specific versions not listed in the text, but applies to versions prior to the patching of the `telem_run_id` routing flaw.
* **Configurations:** Systems allowing plugin installations via URL parameters and featuring file upload capabilities at `hXXps://[domain]/api/v4/files`.
## Vulnerability Description
The vulnerability leverages **Client-Side Path Traversal (CSPT)** to bypass modern CSRF protections (like SameSite cookies).
1. **The Root Cause:** A front-end routing parameter (`telem_run_id`) was used to construct API requests without proper sanitization. By injecting path traversal sequences (e.g., `../../`), an attacker can redirect a legitimate, authenticated client-side request to an unintended API endpoint.
2. **The Sink:** The application uses a "GET-to-POST" pattern where data returned from an initial GET request is automatically used as a parameter in a subsequent state-changing POST request.
3. **The Chain:** By first uploading a malicious file to the server, an attacker can control the JSON response of a GET request. The CSPT vulnerability then forces the victim's browser to fetch this malicious file and pass its contents into a sensitive POST sink (in this case, the plugin installation endpoint).
## Exploitation
* **Status:** PoC available (described in whitepaper research).
* **Complexity:** Medium (Requires chaining file upload, path traversal, and knowledge of internal API routing).
* **Attack Vector:** Network (Web-based).
## Impact
* **Confidentiality:** High (Full system compromise via RCE).
* **Integrity:** High (Ability to install malicious plugins and modify application state).
* **Availability:** High (Potential for service disruption via malicious code execution).
## Remediation
### Patches
* Mattermost has released updates to address CSPT in their routing logic. Users should update to the latest stable version of Mattermost Server.
### Workarounds
* Disable the ability for non-admin users to install or manage plugins.
* Implement strict Content Security Policies (CSP) to limit where the frontend can fetch data from.
## Detection
* **Indicators of Compromise:**
* URL logs containing `../` or encoded equivalents (e.g., `%2e%2e%2f`) in the `telem_run_id` or similar routing parameters.
* Unexpected POST requests to `/api/v4/plugins` originating from client-side automated actions.
* **Detection Methods:** Monitor for unusual file uploads followed immediately by API routing calls that traverse outside the standard `/api/v4/telemetry` paths.
## References
* Mattermost Security Advisories: `hXXps://mattermost[.]com/security-updates/`
* Original Research: `hXXps://[redacted-source-whitepaper-link]` (Refer to the CSPT/CSRF whitepaper mentioned in the context).