Deserialization of Untrusted Data in Apache Camel

Executive Summary

This vulnerability is a deserialization of untrusted data issue in Apache Camel's camel-vertx-http component. When configured with transferException=true (or allowJavaSerializedObject=true) and throwExceptionOnFailure=true, the component deserializes HTTP response bodies with the Content-Type application/x-java-serialized-object using a raw Java ObjectInputStream without applying any filtering on the classes being deserialized.

An attacker who controls the backend service or can intercept unencrypted HTTP traffic (man-in-the-middle) can send a crafted serialized Java object. If the application has a suitable gadget chain on its classpath, this can lead to remote code execution on the host running the Camel application.

The vulnerability is not exploitable in the default configuration where transferException is false. It affects Apache Camel versions from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, and from 4.19.0 before 4.20.0.

Useful 0 Not Useful 0

Impact Analysis

If exploited, this vulnerability can allow an attacker to achieve remote code execution on the host running the Apache Camel application. This means the attacker could execute arbitrary code, potentially taking full control of the system.

The attack requires the attacker to control the backend service the Camel producer communicates with or to be able to intercept and modify unencrypted HTTP traffic between the Camel application and the backend.

This can lead to severe security breaches including data theft, system compromise, and disruption of services.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if the Apache Camel camel-vertx-http or camel-netty-http components are configured with transferException=true or allowJavaSerializedObject=true, and if throwExceptionOnFailure is set to true (default). Network detection involves monitoring HTTP responses with the Content-Type application/x-java-serialized-object, especially those with 5xx status codes, which are deserialized without restrictions.

To detect potential exploitation attempts on your system or network, you can look for HTTP responses with the Content-Type header set to application/x-java-serialized-object and 5xx status codes from backend services that your Camel producer endpoints communicate with.

Suggested commands include using network traffic inspection tools such as tcpdump or Wireshark to filter HTTP traffic for this content type, for example:

• tcpdump -i <interface> -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep 'Content-Type: application/x-java-serialized-object'
• Using curl or similar tools to test backend endpoints for 5xx responses with the vulnerable content type.

Additionally, inspecting the Apache Camel configuration files or runtime settings to verify if transferException or allowJavaSerializedObject options are enabled on producer endpoints can help identify vulnerable setups.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include:

• Upgrade Apache Camel to version 4.20.0, 4.14.8 (for 4.14.x LTS), or 4.18.3 (for 4.18.x), where the vulnerability is fixed by applying a default ObjectInputFilter to constrain deserialization.
• If upgrading is not immediately possible, do not enable transferException=true or allowJavaSerializedObject=true on producers communicating with untrusted or network-exposed backends.
• Ensure that producer connections use TLS (HTTPS) to prevent man-in-the-middle attacks that could substitute malicious serialized objects.
• When the transferException or allowJavaSerializedObject option is required, set an explicit JVM-wide deserialization filter using the -Djdk.serialFilter system property or the deserializationFilter endpoint option to restrict allowed classes (for example, java.**;org.apache.camel.**;!*).

Useful 0 Not Useful 0