CVE-2023-46263: Ivanti Avalanche Arbitrary File Upload Vulnerability

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Lucas Miller and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Ivanti Avalanche enterprise mobility management program. Other Ivanti products have recently been under active exploitation, and the mobile device management system is an attractive target. This bug was originally reported to the ZDI program by an anonymous researcher and was also discovered by Lucas Miller of Trend Micro Research. Successful exploitation of this vulnerability would allow an authenticated attacker to execute code in the context of SYSTEM. The following is a portion of their write-up covering CVE-2023-46263, with a few minimal modifications.

An arbitrary file upload vulnerability has been reported for Ivanti Avalanche. This vulnerability is due to improper input validation in the FileStoreConfig app.

A remote, authenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successfully exploring this vulnerability could result in remote code execution as SYSTEM.

The Vulnerability

Ivanti Avalanche is a mobile device management system. The Central FileStore and the Central File Server in Avalanche are used to store and distribute files that are associated with payloads for mobile device configuration. For example, .apk files or OS update files could be stored in the Central FileStore. The Central FileStore is relevant to understanding this vulnerability.

The Avalanche web interface can be accessed over HTTP on TCP port 8080 as follows:

HTTP is a request/response protocol described in RFCs 7230 – 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI, or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like:

A corresponding HTTP request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

Avalanche allows users to change the location where the Central FileStore saves files by changing the FileStore path through the web interface. To change the FileStore path a request to AvalancheWeb/app/ FileStoreConfig.jsf is made and the request is handled by the com.wavelink.amc.web.view.FileStoreConfigBean class. The request includes a txtUncPath request parameter that contains the new path to store files. Before saving the new values the validateFileStoreUncPath method is called to verify the new path is allowed. The path is checked against a deny list of disallowed values and for directory traversal characters. If the path passes the checks the new path is saved. Future uploads to the FileStore will be stored in the new location.

An arbitrary file upload vulnerability exists in the Central FileStore. The vulnerability is due to insufficient sanitization of the txtUncPath field in the Central FileStore configuration settings. The validateFileStoreUncPath attempts to prevent the new path from containing the webroot folders for Avalanche servers in the path. However, the validateFileStoreUncPath method does not prevent the use of the parent folder of the RemoteControl server webroot folder at: “C:ProgramDataWavelinkAvalancheRemoteControlServerapp”. An attacker can set the txtUncPath value to “C:ProgramDataWavelinkAvalanche”, bypassing the disallowed path checks. Then an attacker can send a request to upload a malicious file to the “RemoteControlServerapp” subfolder. The RemoteControl server is typically used to control connected Windows Mobile/CE devices and can be accessed by sending an HTTP request to http://<hostname>:1900/. By default, the RemoteControl server executes Velocity macro code. By uploading a crafted file to the RemoteControl server webroot, an attacker could execute arbitrary commands on the system.

Source Code Walkthrough

The following code snippet was taken from Ivanti Avalanche version 6.4.1. Comments added by Trend Micro have been highlighted.

From app/FileStoreConfigSettings.xhtml in AvalancheWeb.jar.

From the decompiled CentralFileStoreDialog class in AvalancheWeb.jar.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on TCP ports 8080 (HTTP) and 8443 (HTTPS). Note that the traffic may be SSL encrypted. The detection device may be required to decrypt the traffic before proceeding through the next steps.

The detection device must monitor all HTTP POST requests to a request-URI containing the following path:


If such a request is found, then the detection device must search the request body for the linkFileStoreConfigSave parameter. If the linkFileStoreConfigSave parameter value is “linkFileStoreConfigSave”, the value of the txtUncPath parameter must be inspected for the following string:


If found, the request should be considered suspicious as an attack exploiting this vulnerability is likely underway. Below is an example of a malicious request:


Ivanti patched this vulnerability and several others with the release of version 6.4.2. No other mitigations are listed, so it is recommended that users of Ivanti Avalanche test and deploy this patch to fully address this vulnerability.

Special thanks to Lucas Miller and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.