Deserialization of untrusted data in Apache Camel allows an attacker who can supply a serialized Java object to a Camel consumer to trigger DNS queries. The default ObjectInputFilter permits classes such as java.net.URL, which perform network I/O during hashCode or readObject. When a HashMap containing these classes is deserialized, the JVM contacts domain names supplied in the payload, leaking which hosts were queried to an attacker‑controlled DNS server. This results in a side‑channel that can disclose network information about the system and the attacker’s host, without executing arbitrary code. This vulnerability is a deserialization flaw (CWE‑502).

Apache Camel components shipped before specific patch versions are affected. The vulnerability exists in camel‑jms, camel‑sjms, camel‑amqp, camel‑mina, camel‑netty, camel‑netty‑http, camel‑vertx‑http, camel‑infinispan, and the aggregation‑repository components camel‑leveldb, camel‑cassandraql, camel‑consul, camel‑sql (JDBC aggregation repository). The issue applies to Camel releases 4.14.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.9. The recommended fixed releases are 4.14.8, 4.18.3, and 4.21.0 respectively.

The EPSS score is less than 1 %, indicating a very low current probability of exploitation that has been observed. The vulnerability is not listed in the CISA KEV catalog, but it remains a legitimate risk because the attack requires the ability to deliver a serialized payload to a running Camel consumer, a scenario that can arise in applications exposed over JMS, AMQP, or Netty. If the attacker can reach a Camel endpoint, the side‑channel can be used to learn which domain names the application resolves, potentially revealing internal network structure. While the exploitability is restricted to deserialization of untrusted data, the potential impact of information disclosure makes it important to address promptly.