Apache Camel’s JMS component deserializes the payload of an incoming JMS ObjectMessage whenever the mapJmsMessage option is enabled, which is the default. A hardening change added a class whitelist that rejects classes outside the java., javax., and org.apache.camel. namespaces, but the DefaultExchangeHolder class itself resides in the allowed namespace. This allows an attacker to send a JMS ObjectMessage whose top‑level object is a DefaultExchangeHolder, which passes the whitelist check. The component then calls DefaultExchangeHolder.unmarshal() on that payload and writes every non‑null field into the Camel Exchange without requiring the transferExchange option, thereby injecting arbitrary Exchange state such as headers, properties, variables, the message body, the exchange id, and exception information. This bypasses the intended security hardening and gives an attacker the ability to manipulate routing decisions, override headers, alter properties, and trigger exception handling logic, but the description does not explicitly state successful remote code execution.

Apache Camel versions from 3.0.0 through 4.19.0 prior to 4.21.0 are affected, including the Camel JMS family components—camel‑jms, camel‑sjms, camel‑sjms2—and the JMS‑family components built on JmsComponent such as camel‑amqp, camel‑activemq, and camel‑activemq6. The vulnerable releases are the 4.14.x stream before 4.14.8, the 4.18.x stream before 4.18.3, and the 4.19.x stream before 4.21.0.

The CVSS score of 7.3 indicates high severity, but the EPSS score is below 1 % and the vulnerability is not listed in CISA’s KEV catalog, suggesting a low current exploitation probability. An attacker must be able to publish a JMS ObjectMessage to a queue or topic consumed by Camel, and the message must contain a DefaultExchangeHolder object. The attack does not rely on exotic gadget chains and requires only universally trusted java.lang and java.util types for the payload, lowering the technical barrier. Availability of the mapJmsMessage option means the risk applies only when that option is enabled; disabling that option or setting objectMessageEnabled=false mitigates the risk. In the absence of those mitigations, an attacker can inject state that could potentially alter application behavior and, depending on the logic of the consumer application, could lead to unintended side effects.