CVE-2026-43866
published 2026-07-06CVE-2026-43866: Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component. JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent…
PriorityP352high7.3CVSS 3.1
AVNACLPRNUINSUCLILAL
EPSS
0.65%
50.7th percentile
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 DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An attacker who can publish an ObjectMessage to a queue or topic consumed by an affected Camel application can therefore inject arbitrary Exchange state using only universally-trusted java.lang and java.util types, with no deserialization gadget chain required, to manipulate routing and headers, exchange properties and error handling. The same handling applies to camel-sjms and camel-sjms2, and to the JMS-family components built on JmsComponent and JmsBinding: camel-amqp, camel-activemq and camel-activemq6. This is a bypass of the CVE-2026-40860 fix rather than a flaw in it.
This issue affects Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0; Apache Camel: from 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are rec
Affected
3 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | camel | >= 3.0.0 < 4.14.8 | 4.14.8 |
| apache | camel | >= 4.15.0 < 4.18.3 | 4.18.3 |
| apache | camel | >= 4.19.0 < 4.21.0 | 4.21.0 |
CVSS provenance
nvdv3.17.3HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
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
VulDB
Apache Camel up to 4.14.7/4.18.2/4.20.x DefaultExchangeHolder deserialization
vuldb·2026-07-08·CVSS 7.3
CVE-2026-43866 [HIGH] Apache Camel up to 4.14.7/4.18.2/4.20.x DefaultExchangeHolder deserialization
A vulnerability has been found in Apache Camel up to 4.14.7/4.18.2/4.20.x and classified as critical. This issue affects some unknown processing of the component DefaultExchangeHolder. Performing a manipulation results in deserialization.
This vulnerability was named CVE-2026-43866. The attack may be initiated remotely. There is no available exploit.
The affected component should be upgraded.
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
No detection rules found.
No public exploits indexed.
2026-07-06
Published