CVE-2026-40860
published 2026-04-27CVE-2026-40860: JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values…
PriorityP266critical9.8CVSS 3.1
AVNACLPRNUINSUCHIHAH
EPSS
1.23%
66.8th percentile
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6.
This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.
Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | camel | — | — |
| apache | camel | >= 3.0.0 < 4.14.7 | 4.14.7 |
| apache | camel | >= 3.0.0 < 4.14.8 | 4.14.8 |
| apache | camel | >= 4.15.0 < 4.18.2 | 4.18.2 |
| apache | camel | >= 4.15.0 < 4.18.3 | 4.18.3 |
| apache | camel | >= 4.19.0 < 4.21.0 | 4.21.0 |
| apache_software_foundation | apache_camel | >= 3.0.0 < 4.14.8 | 4.14.8 |
| apache_software_foundation | apache_camel | >= 4.15.0 < 4.18.3 | 4.18.3 |
| apache_software_foundation | apache_camel | >= 4.19.0 < 4.21.0 | 4.21.0 |
Detection & IOCsextracted from sources · hover to see the quote
- →Trigger condition: attack is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer — monitor for JMS ObjectMessage consumption in Camel applications with default configuration ↗
- →Attack vector: crafted JMS ObjectMessage published to a queue or topic consumed by a Camel application — alert on unexpected ObjectMessage types arriving at Camel-consumed JMS destinations ↗
- →Vulnerable code path: JmsBinding.extractBodyFromJms() deserializes via javax.jms.ObjectMessage.getObject() with no ObjectInputFilter, allowlist, or denylist — instrument or monitor this method for unexpected class deserialization ↗
- →Affected components to inventory: camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6 — flag any deployment of these components in versions from 3.0.0 before 4.14.7, 4.15.0 before 4.18.2, or 4.19.0 before 4.20.0 ↗
- →Affected version ranges for detection/inventory: Apache Camel 3.0.0 through <4.14.7, 4.15.0 through <4.18.2, 4.19.0 through <4.20.0 ↗
- ·The mapJmsMessage option is enabled by default, meaning all default-configured Camel JMS consumer deployments are vulnerable without any attacker-controlled configuration change required ↗
- ·Exploitation requires a deserialization gadget chain to be present on the classpath; environments with minimal or controlled classpaths may have reduced RCE risk, but the vulnerability still exists ↗
- ·camel-amqp is affected via AMQPJmsBinding extending JmsBinding; camel-sjms2 is affected via Sjms2Endpoint extending SjmsEndpoint — transitive exposure means components not obviously named 'jms' are still vulnerable ↗
- ·Red Hat Fuse 7 camel-amqp and camel-jms-starter are listed as Not Affected, while camel-jms in Fuse 7 is Affected — do not conflate package names across distributions ↗
CVSS provenance
nvdv3.19.8CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
ghsa9.8CRITICAL
vendor_redhat9.8CRITICAL
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
vendor_redhat·2026-07-06·CVSS 9.8
CVE-2026-43866 [CRITICAL] CWE-502 camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchange
Red Hat
Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
vendor_redhat·2026-04-27·CVSS 9.8
CVE-2026-40860 [CRITICAL] CWE-502 Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
A flaw was found in Apache Camel. A remote attacker could exploit a deserialization vulnerability by sending a specially crafted Java Message Service (JMS) ObjectMessage to a Camel application acting as a JMS consumer. This vulnerability arises because the application deserializes the message payload without proper validation. Successful exploitation could lead to remote code execution on the system consuming the message, provided a deserialization gadget chain is present on the classpath.
Package: camel-amqp (Red Hat build of Apache Camel 4 for Quarkus 3) - Affected
Package: camel-jms (Red Hat build of Apache Camel 4
GHSA
Apache Camel JMS deserialization filter bypass
ghsa·2026-07-06·CVSS 9.8
CVE-2026-43866 [CRITICAL] CWE-502 Apache Camel JMS deserialization filter bypass
Apache Camel JMS deserialization filter bypass
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. Th
GHSA
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
ghsa_unreviewed·2026-07-06·CVSS 9.8
CVE-2026-43866 [CRITICAL] CWE-502 Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolde
GHSA
Apache camel-jms, camel-sjms, camel-sjms2 and camel-amqp: Unsafe Deserialization of JMS ObjectMessage
ghsa·2026-04-27
CVE-2026-40860 [CRITICAL] CWE-502 Apache camel-jms, camel-sjms, camel-sjms2 and camel-amqp: Unsafe Deserialization of JMS ObjectMessage
Apache camel-jms, camel-sjms, camel-sjms2 and camel-amqp: Unsafe Deserialization of JMS ObjectMessage
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extend
GHSA
GHSA-m5vh-3fw5-5wgh: JmsBinding
ghsa_unreviewed·2026-04-27
CVE-2026-40860 [CRITICAL] CWE-502 GHSA-m5vh-3fw5-5wgh: JmsBinding
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-fami
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-43866 camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
bugzilla·2026-07-06·CVSS 9.8
CVE-2026-43866 [CRITICAL] CVE-2026-43866 camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
CVE-2026-43866 camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.
JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a
Bugzilla
CVE-2026-40860 Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
bugzilla·2026-04-27·CVSS 9.8
CVE-2026-40860 [CRITICAL] CVE-2026-40860 Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
CVE-2026-40860 Apache Camel: camel-jms: camel-sjms: camel-sjms2: camel-amqp: camel-activemq: camel-activemq6: Apache Camel: Remote Code Execution via deserialization of JMS ObjectMessage
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The s
https://camel.apache.org/security/CVE-2026-40860.htmlhttp://www.openwall.com/lists/oss-security/2026/04/26/10https://access.redhat.com/errata/RHSA-2026:17668https://access.redhat.com/errata/RHSA-2026:22453https://access.redhat.com/security/cve/CVE-2026-40860https://bugzilla.redhat.com/show_bug.cgi?id=2463172https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40860.json
2026-04-27
Published