The flaw is a deserialization issue in Apache Camel's JMS component. When the mapJmsMessage option is enabled (the default), Camel extracts the payload of an incoming JMS ObjectMessage by calling jakarta.jms.ObjectMessage.getObject(). A recent hardening added a whitelist that blocks classes outside the java.*, javax.*, and org.apache.camel.* namespaces, but org.apache.camel.support.DefaultExchangeHolder is in that namespace. Thus an ObjectMessage containing a DefaultExchangeHolder bypasses the whitelist, and the component calls unmarshal() on it without requiring transferExchange. The holder writes any non‑null field into the Camel Exchange—message body, IN/OUT headers, properties, variables, exchange id, exception—allowing an attacker who can publish an ObjectMessage to a queue or topic to inject arbitrary Exchange state, manipulate routing, modify headers, change error handling, or trick the application flow. This constitutes a high‑severity deserialization flaw (CWE‑502) that can lead to arbitrary code behavior or denial of service.

The affected product is Apache Camel (versions starting at 3.0.0). The flaw exists in camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, and camel-activemq6 JMS‑family components. Vulnerable releases include the 4.14.x stream before 4.14.8, the 4.15.x stream before 4.18.3, and the 4.19.x stream before 4.21.0. Users running any of these streams that consume JMS ObjectMessages with the default mapJmsMessage enabled are at risk.

The EPSS score is less than 1%, and the vulnerability is not listed in CISA KEV, indicating a low likelihood of current exploitation. The CVSS base score is 7.3, signifying high severity. The attack requires the ability to publish a crafted ObjectMessage to a queue or topic that Camel consumes and the mapJmsMessage option to be enabled. Since the component defaults to disabling objectMessageEnabled after the fix, the risk is only present in configurations that still have it enabled or that consume ObjectMessage bodies from untrusted networks. An attacker with broker‑level write permissions can create the malicious payload using only standard java.lang or java.util classes, avoiding a gadget chain, and thus can exert arbitrary control over the Exchange state.