Xen Mobile: Insufficient path validation in unzip API call allows attackers to write to arbitrary files and remotely execute code


Last revised:

It is possible to upload JSP files to Xen Mobile’s Tomcat server, leading to arbitrary code execution.

Current state: Fixed

CVSS Summary

CVSS base scores for this vulnerability
Score 9 High
Vector Network
Complexity Low
Authentication Single
Confidentiality Complete
Integrity Complete
Availability Complete
You can read more about CVSS base scores on Wikipedia or in the CVSS specification.

Proof of concept

Using the unauthenticated file upload vulnerabilities described in dxw-2018-3564 (see finding unauthenticated file upload), it is possible to upload a zip file crafted by the attacker.  Xen Mobile provides an API to unzip files by posting to:


Combining this vulnerability with the unzip API allowed us to create arbitrary files, leading to arbitrary code execution on the server.

POST /controlpoint/rest/application/mobile/process? HTTP/1.1
X-Requested-With: XMLHttpRequest
Cookie: JSESSIONID=validsession

Xen Mobile does not check to see if the zip file contains relative paths. This meant the tester could write files to arbitrary locations on the server by crafting zip files containing relative paths. In this case, the zip file crafted by the tester was encoded to contain a file with the path:


test9.jsp contained code written by the attacker to allow us to run arbitrary commands on the server.

When Xen Mobile unzips this file, it creats test9.jsp within the web root of the Tomcat server, making it available to be executed via the web. The tester was then able to call it via HTTP from an external location, running arbitrary commands and viewing their output.

Advisory timeline

2018-03-28 – Reported to Citrix and acknowledged immediately

2018-05-21 – Issue reported fixed

Mitigation/further actions

  1. Change the directory permissions on Tomcat, making it unable to write files within the web root
  2. Where recommendation #1 would break application functionality, adjust the Tomcat configuration such that Tomcat will not execute scripts in any directory it can write to
  3. Consider additional monitoring on servers to detect and report the execution of unexpected processes
  4. Remove public access to this service by moving it inside your network and configuring mobile devices to access it via a VPN or proxy that requires authentication
  5. Install an update rectifying this issue as soon as one is available