This is an issue when extension support is enabled in an XML RPC configuration object (either server-side or client-side configuration).

In Java, this specifically occurs when calling setEnabledForExtensions(true) on XmlRpcServerConfigImpl or XmlRpcClientConfigImpl objects.

Why is this an issue?

This library implements a remote procedure call protocol that communicates over HTTP using structured data encoding.

By default, the library supports a standard set of data types defined in the protocol specification. However, the library also provides optional extension types that are disabled by default for security reasons.

When you enable extensions, you activate several extension types, including a type that allows arbitrary objects from the programming language to be serialized, transmitted as encoded binary data, and then deserialized on the receiving end.

The Deserialization Risk

Deserialization is a process where a byte stream is converted back into an object. The problem is that during deserialization, the runtime automatically invokes certain lifecycle methods on the object being reconstructed.

Attackers can exploit this by crafting malicious serialized objects that, when deserialized, trigger a chain of method calls known as a "gadget chain." These chains can execute arbitrary code on the server.

This vulnerability is particularly dangerous because:

How This Affects Remote Procedure Calls

When extensions are enabled, an attacker who can send requests to your endpoint can:

  1. Craft a malicious serialized object using known gadget chains
  2. Encode it as binary data
  3. Send it in a request using the serializable object extension type
  4. Trigger code execution when your server deserializes the object

This attack works even if your remote procedure call methods don’t explicitly accept serialized objects - the deserialization happens at the protocol level, before your application code runs.

This specifically refers to the Apache XML RPC library, which implements the XML-RPC protocol. The extension types are enabled by calling setEnabledForExtensions(true), which activates the <ex:serializable> type that allows Java object serialization.

What is the potential impact?

An attacker who can send requests to your XML RPC endpoint can achieve remote code execution on the server. This allows them to:

The impact is critical because the attacker gains the same privileges as the application user running the XML RPC server.

How to fix it

Do not enable extensions on your Apache XML RPC configuration. The default behavior (extensions disabled) is secure and sufficient for most use cases.

If your application genuinely requires extension types for non-serialization features, consider migrating to a safer RPC framework that does not bundle arbitrary object deserialization with its extension mechanism. The Apache XML RPC library is no longer actively maintained, and modern alternatives such as gRPC or JSON-RPC libraries provide richer type support without exposing a deserialization attack surface.

If the finding is intentional and you accept the risk, ensure that the XML RPC endpoint is not exposed to untrusted clients, and add a Java deserialization filter (via ObjectInputFilter) to restrict which classes can be deserialized. Mark the issue as "Won’t Fix" only when these compensating controls are in place. If the endpoint is not reachable by untrusted input, the finding is a false positive.

Code examples

Noncompliant code example

XmlRpcServerConfigImpl config = new XmlRpcServerConfigImpl();
config.setEnabledForExtensions(true); // Noncompliant

Compliant solution

XmlRpcServerConfigImpl config = new XmlRpcServerConfigImpl();
// Extensions are disabled by default - no action needed

Resources

Documentation

Standards