Apache Camel CVE-2026-42527

Requires an affected Camel component (4.14.0-4.14.7, 4.15.0-4.18.2, or 4.19.0-4.20.x) that deserializes attacker-controlled Java-serialized input; the highest exposure is camel-jms/camel-sjms/camel-amqp routes with mapJmsMessage=true (the default), where JmsBinding.extractBodyFromJms unconditionally calls ObjectMessage.getObject(). The attacker must be able to deliver a serialized payload (e.g., an ObjectMessage) to the vulnerable consumer - typically meaning access to publish to the JMS destination/queue or to the relevant network endpoint (mina/netty/vertx-http/infinispan or a JDBC/Cassandra/Consul/LevelDB aggregation repository fed with untrusted data). Exploitation is LIMITED by: the CVSS AC:H (a crafted serialized object must reach a listening consumer), reliance on the vulnerable default filter still being in place (any provider-side allow-list or overridden deserializationFilter/-Djdk.serialFilter neutralizes it), and the demonstrated impact being a blind DNS out-of-band channel rather than direct code execution. No end-user interaction is required (UI:N) and no Camel-level authentication is modeled (PR:N), though publishing to a broker destination may in practice require broker credentials.

Signals conflict and should be weighed carefully. The vendor CVSS of 8.1 (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H) rates confidentiality, integrity, and availability all High, but the concretely described impact is a blind DNS out-of-band side channel (leaking whether/where a lookup occurs), which is far narrower than the full compromise those C:H/I:H/A:H ratings imply - treat the high C/I/A as generous relative to the described mechanism, or as an acknowledgement that the same allow-list weakness could enable broader gadget chains not detailed here. AC:H reflects that an attacker must actually deliver a crafted serialized object to a listening consumer and rely on default configuration. EPSS is low at 0.31% (23rd percentile) and the CVE is not in CISA KEV, consistent with no known active exploitation; no public exploit was identified. Net: this is a real, patch-worthy issue for organizations running affected camel-jms deployments that accept serialized messages, but the low EPSS, high attack complexity, and side-channel-only demonstrated impact place it below drop-everything priority - prioritize based on whether untrusted parties can reach your JMS/consumer endpoints.

An attacker with the ability to publish messages to a JMS destination consumed by a vulnerable Camel route (mapJmsMessage=true by default) sends an ObjectMessage whose body is a serialized HashMap keyed on java.net.URL objects pointing to an attacker-controlled DNS domain. When Camel calls ObjectMessage.getObject(), the JVM deserializes the map and resolves the URL host during hashCode, and the attacker observes the resulting DNS query on their authoritative name server, confirming reachability and enabling blind out-of-band signalling. No public exploit was identified at time of analysis, and the CVSS AC:H reflects the need to reach a listening consumer with a crafted serialized payload.