Bishop Fox Security Advisory: Critical Security Vulnerability Discovered in OpenMRS

Product Description

OpenMRS is a collaborative open-source project through which users can develop software to support healthcare in developing countries. In 2017, OpenMRS was implemented on more than 3,000 sites and stored information for over 8.7 million active patients. The application’s official website is

Vulnerabilities List

One vulnerability was identified within the OpenMRS Platform:

  • Insecure object deserialization

The vulnerability is described in detail following this summary.


This vulnerability is considered as critical because an attacker could gain a shell access to the server without an account or privileges. In addition to that, given the type of information stored in OpenMRS, an exploitation could lead to a leakage of sensitive healthcare data.

Affected Versions

Versions before and including 2.1.3. All versions of OpenMRS that use the module:
• All versions of OpenMRS Platform 1.10.X
• All versions of OpenMRS Platform 1.11.X except 1.11.8 and 1.11.9
• All versions of OpenMRS Platform 1.12.X
• All versions of OpenMRS Platform 2.0.X
• All versions of OpenMRS Platform 2.1.X

NOTE: As of November 21, 2018, the assessment team does not know why versions 1.11.8 and 1.11.9 are not affected by this vulnerability.


Update the module – the vulnerability was addressed in version 2.24.0. (Read OpenMRS instructions here.) 

We’d like to thank the developers at OpenMRS for working with us in the disclosure process. They were easy to work with, professional, and willing to put in hours during the holiday season to ensure a solution. 

Insecure Object Deserialization on the OpenMRS Platform

Vulnerability Details

CVE ID: CVE-2018-19276

Access Vector: Remote

Security Risk: Critical

Vulnerability: CWE-502

CVSS Base Score: 10.0 

CVSS vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Java 8 Environment

By injecting an XML payload in the following body request to the REST API provided by the application, an attacker could execute arbitrary commands on the remote system. The request below could be used to exploit the vulnerability:

The payload above was generated with the marshalsec tool and adapted to use multiple arguments because the original payload would not work well if the attacker need to send several arguments to a Linux host.. After the payload was sent, the handler successfully received a response:

The response should contain an error message similar to the one below:

The response above showed that the REST Web Services module was unable to process the request properly. However, the payload was deserialized before it is caught by the exception handler, which allowed the team to gain shell access.

Java 7 Environment

Java 7 could be used to run OpenMRS, although the payload used in the Java 8 exploit above would not work. However, the Java Development Kit (SDK) offers a gadget to perform the exploitation that would allow an attacker to gain shell access. The marshalsec tool was used to generate the expected payload.

Unlike the first case, the Java 7 exploitation process was conducted in multiple stages. First, a malicious Java class was written to be injected in the targeted environment. After that, an LDAP server was started on the attacker host to provide the compiled Java class within the response of all requests.

The payload, shown below, was developed as a proof-of-concept (PoC) exploitation class:

The waitFor() method is useful because it prevents the application from crashing. The IP address and the port 4444 were connected to the attacker host.

The assessment team, acting as an attacker, had to compile the previous file into a bytecode class file. The following command line was used:

The compiled Java class was moved to the /tmp/ (Temp) directory. An attacker would need to start a simple web server on the attacker host. (In this case, the team used Python to do that.)

A listener has been started using the tool Netcat. The port 4444 is the value used in the file previously created.

The team used the marshalsec tool to simulate an LDAP server by using the command line:

At this time, three terminals opened and everything was configured to provide the malicious class to the targeted application. The issue was exploited using the JdbcRowSet gadget found by @Matthias_kaiser:

The ldap connection string within the file above was changed by the attacker IP address and saved to the location /tmp/ldap.txt.

By using the following cURL command, the payload was sent to the REST API using POST method:

On some versions, the payload needs to be sent to an existing endpoint (e.g., /concept) and on others, the payload needs to a non-existing class (e.g., /conxxcept).

The cURL command sent the content of the file located at /tmp/ldap.txt, which contained the gadget. Once the gadget was executed, the Exploit.class file was provided and injected into the targeted application. The execution of the malicious Java file led to remote shell access. Port 4444 of the attacker host received the connection. Note that no error was displayed in the HTTP response:

Depending of the way the application was deployed, the remote command injection could give different permissions. For example, if the Docker image was used, an attacker would gain full administrative privileges, as shown in the figure above.

Disclosure Timeline:

  • October 6, 2018: Initial discovery on OpenMRS Reference application version 2.8.0 (with all modules)
  • November 11, 2018: Tested on OpenMRS Reference application version 2.5 (with all modules)
  • November 18, 2018: Tested all OpenMRS Platform releases


Nicolas Serra, Security Associate at Bishop Fox