Untrusted deserialisation in Xen Mobile 10.6 through 10.8 allows network adjacent unauthenticated users to remotely execute code


Last revised:

Xen Mobile includes a service listening on port 5001 within its firewall that accepts unauthenticated input. If this service is supplied with raw serialised Java objects, it deserialises them back into Java objects in memory, giving rise to a remote code execution vulnerability.

Current state: Reported

CVSS Summary

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

Proof of concept

In any situation where untrusted input is deserialised, there is a risk that remote code execution attacks are made possible because an attacker can control the code and data that are deserialised and executed.

Exactly what attacks are possible depend on the classes available within the application at the point at which the deserialisation occurs.

In Java, a serializable class can define a method named readObject which can be used to perform special handling during deserialization. The following code is from DiskFileItem in commons-fileupload-1.3.1.jar, which is available on the class path set in Xen Mobile:

private void readObject(ObjectInputStream in)
        throws IOException, ClassNotFoundException
    // ...
        FileInputStream input = new FileInputStream(this.dfosFile);
        IOUtils.copy(input, output);
        this.dfosFile = null;

    this.cachedContent = null;

Accepting serialised raw objects from untrusted sources is unsafe and should be avoided across the codebase in favour of safe data formats. As we control the value passed into this method, and we control the values of the attributes in this class, we can write a file to a location of our choosing with content of our choosing.

As we have write privileges to the Tomcat web directory, we can use this vulnerability to upload a JSP file containing arbitrary code.

Advisory timeline

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

2018-05-21 – Citrix report that they do not consider this issue to be a vulnerability:

Mitigation/further actions

Citrix have acknowledged this issue but have not addressed it on the basis that it is already mitigated:

[This issue is] already mitigated by the internal firewall that limits access to configuration services to localhost.  Because these are already mitigated, we did not list them in the Citrix security bulletin.

We acknowledge that the firewall does prevent this issue from being exploited externally. However the issue nonetheless exists, making the service vulnerable to local attack, and potentially to remote attack in the case that another vulnerability is found that allows the firewall to be circumvented.

As such, we still consider the issue relevant.