CVE-2026-43866
Received Received - Intake

Deserialization of Untrusted Data in Apache Camel JMS Components

Publication date: 2026-07-06

Last updated on: 2026-07-06

Assigner: Apache Software Foundation

Description
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 recommended to upgrade to version 4.21.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.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, JMS ObjectMessage handling is disabled by default in camel-jms, camel-sjms and the JMS-family components (a new objectMessageEnabled option defaults to false at the component and endpoint level), so an incoming ObjectMessage - including a DefaultExchangeHolder payload - is no longer deserialized unless the option is explicitly enabled; only set objectMessageEnabled=true when the consumed JMS destination is fed exclusively by trusted producers. For deployments that cannot upgrade immediately, restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization, and do not expose JMS consumers that map ObjectMessage bodies to untrusted networks; a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-06
Last Modified
2026-07-06
Generated
2026-07-06
AI Q&A
2026-07-06
EPSS Evaluated
N/A
NVD
CVE-2026-43866
EUVD
EUVD-2026-41855

Affected Vendors & Products

Showing 6 associated CPEs
Vendor Product Version / Range
apache camel to 4.14.8 (exc)
apache camel to 4.18.3 (exc)
apache camel to 4.21.0 (exc)
apache camel 4.14.8
apache camel 4.18.3
apache camel 4.21.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-502 The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

CVE-2026-43866 is a deserialization of untrusted data vulnerability in Apache Camel's JMS components. It occurs because the system deserializes incoming JMS ObjectMessage payloads by default, and a crafted object called DefaultExchangeHolder can bypass class checks designed to prevent unsafe deserialization. This allows an attacker who can send JMS ObjectMessages to inject arbitrary Exchange state, including message bodies, headers, properties, variables, and exceptions, without needing complex deserialization gadget chains.

The vulnerability affects multiple Apache Camel components such as camel-jms, camel-sjms, camel-sjms2, and JMS-family components like camel-amqp, camel-activemq, and camel-activemq6. It is essentially a bypass of a previous fix (CVE-2026-40860) and is classified under CWE-502 (Deserialization of Untrusted Data) and CWE-20 (Improper Input Validation).

Impact Analysis

This vulnerability allows an attacker who can publish JMS ObjectMessages to a queue or topic consumed by an affected Apache Camel application to inject arbitrary Exchange state. This means the attacker can manipulate routing, message headers, exchange properties, variables, and error handling within the application.

Such manipulation can lead to unauthorized control over message processing, potentially causing incorrect routing, data corruption, or bypassing security controls, which can severely impact the integrity and reliability of the messaging system.

Mitigation Strategies

To mitigate this vulnerability immediately, users should upgrade Apache Camel to a fixed version: 4.14.8 for the 4.14.x LTS stream, 4.18.3 for the 4.18.x stream, or 4.21.0 for other versions.

After upgrading, JMS ObjectMessage handling is disabled by default via the new objectMessageEnabled option at the component and endpoint level. This means incoming ObjectMessages, including those with DefaultExchangeHolder payloads, will no longer be deserialized unless objectMessageEnabled is explicitly set to true.

For deployments that cannot upgrade immediately, restrict publish access to the JMS queues and topics consumed by Camel to trusted producers using JMS broker authorization, and avoid exposing JMS consumers that map ObjectMessage bodies to untrusted networks.

Note that a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43866. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart