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.
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.
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:
When extensions are enabled, an attacker who can send requests to your endpoint can:
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.
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.
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.
XmlRpcServerConfigImpl config = new XmlRpcServerConfigImpl(); config.setEnabledForExtensions(true); // Noncompliant
XmlRpcServerConfigImpl config = new XmlRpcServerConfigImpl(); // Extensions are disabled by default - no action needed