This vulnerability arises from the default ObjectInputFilter pattern in Apache Camel components that permits deserialization of classes whose methods perform network I/O, such as java.net.URL and java.net.InetAddress. When a malicious serialized payload containing a HashMap with java.net.URL keys is deserialized, it causes the JVM to issue DNS queries to attacker-controlled hosts as a side effect. The filter allows the HashMap class, so the check passes, enabling this side channel. The issue is most pronounced in the camel-jms components where ObjectMessage.getObject() is called unconditionally with mapJmsMessage=true (default). Affected components include camel-jms, camel-sjms, camel-amqp, camel-mina, camel-netty, camel-netty-http, camel-vertx-http, camel-infinispan, and aggregation repository components camel-leveldb, camel-cassandraql, camel-consul, and camel-sql. The vulnerability affects Apache Camel versions 4.14.0 up to but not including 4.14.8, 4.15.0 up to but not including 4.18.3, and 4.19.0 up to but not including 4.21.0. The recommended fix is to upgrade to versions 4.14.8, 4.18.3, or 4.21.0. Alternatively, users can mitigate by configuring JMS-provider allow-lists or overriding the deserialization filter with explicit deny rules to block java.net.** classes.

The vulnerability allows an attacker who can deliver a Java-serialized payload to an affected Apache Camel consumer to cause the JVM to perform DNS queries to attacker-controlled hosts during deserialization. This creates an out-of-band side channel that can be used to confirm exploitation or exfiltrate data indirectly. The impact is primarily information disclosure via DNS query observation. There is no direct code execution or data corruption described. The highest exposure is in the camel-jms family due to unconditional deserialization behavior by default.

A fix is available in Apache Camel versions 4.14.8, 4.18.3, and 4.21.0. Users are strongly recommended to upgrade to these versions. For deployments that cannot upgrade immediately, primary mitigation involves configuring JMS-provider-side allow-lists such as Apache ActiveMQ Artemis 'deserializationAllowList' or Apache ActiveMQ Classic 'org.apache.activemq.SERIALIZABLE_PACKAGES'. Additionally, users can override the default deserialization filter by setting the endpoint-level 'deserializationFilter' option or the JVM-wide '-Djdk.serialFilter' system property with explicit deny rules like '!java.net.**;java.**;javax.**;org.apache.camel.**;!*' (or '!java.net.**;java.**;org.apache.camel.**;!*' for aggregation repository components). These mitigations reduce the risk of deserialization of classes that cause network I/O side effects.