JmsBinding.extractBodyFromJms() in camel-jms and equivalent classes in camel-sjms, camel-sjms2, and camel-amqp deserialized incoming JMS ObjectMessage payloads without any filtering or allowlist. Because this code path is taken whenever the mapJmsMessage option is enabled, an attacker who can publish a crafted ObjectMessage to a queue or topic that a Camel application consumes can trigger arbitrary code execution via a deserialization gadget chain present on the classpath. The vulnerability is a classic unsafe deserialization flaw (CWE‑502) that allows remote attackers to execute code with the privileges of the Camel process.

Apache Software Foundation’s Apache Camel is affected. The flaw exists in camel‑jms, camel‑sjms, camel‑sjms2, camel‑amqp, as well as JMS‑family components such as camel‑activemq and camel‑activemq6. The vulnerable versions are 3.0.0 through 4.14.6, 4.15.0 through 4.18.1, and 4.19.0 through 4.19.9. 4.14.x LTS users should upgrade to 4.14.7, 4.18.x users to 4.18.2, and all other users to 4.20.0 to fix the issue.

The CVSS score of 9.8 marks this as critical. Current EPSS indicates a very low probability of exploitation (<1%), and the vulnerability is not listed in the CISA KEV catalog. The attack requires the ability to publish a crafted ObjectMessage to a Camel-consumed JMS destination; no authentication constraints are described, so the threat exists wherever the application exposes a JMS broker entry point. Presence of a gadget chain on the classpath is also required for RCE to occur.