CVE-2026-43866: Apache Camel Deserialization Vulnerability

CVE-2026-43866 Overview

CVE-2026-43866 is a deserialization of untrusted data vulnerability [CWE-502] affecting the Apache Camel JMS component and related JMS-family components. The flaw bypasses the hardening introduced by CVE-2026-40860 by abusing the allow-listed org.apache.camel.support.DefaultExchangeHolder class. An attacker who can publish a jakarta.jms.ObjectMessage to a queue or topic consumed by an affected Camel application can inject arbitrary Exchange state, including message bodies, headers, properties, variables, exchange IDs, and exceptions. Exploitation uses only universally-trusted java.lang and java.util types, requiring no gadget chain.

Critical Impact
A remote attacker with publish access to a consumed JMS destination can manipulate routing, headers, exchange properties, and error handling by sending a crafted ObjectMessage containing a DefaultExchangeHolder.

Affected Products

Apache Camel 3.0.0 through versions before 4.14.8 (LTS stream)
Apache Camel 4.15.0 through versions before 4.18.3
Apache Camel 4.19.0 through versions before 4.21.0 (affects camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6)

Discovery Timeline

2026-07-06 - CVE-2026-43866 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-43866

Vulnerability Analysis

The vulnerability resides in JmsBinding.extractBodyFromJms() within camel-jms and the equivalent JmsBinding in camel-sjms. When Camel acts as a JMS consumer with the mapJmsMessage option enabled (the default), the binding deserializes incoming ObjectMessage payloads through jakarta.jms.ObjectMessage.getObject().

The fix for CVE-2026-40860 introduced a post-deserialization class check enforcing the allow-list java.**;javax.**;org.apache.camel.**;!*. This check accepts classes that reside in the org.apache.camel.** namespace, including org.apache.camel.support.DefaultExchangeHolder.

Once the top-level object passes the allow-list, the receiving side invokes DefaultExchangeHolder.unmarshal() on it. The unmarshal routine writes every non-null field into the current Exchange, covering the message body, IN and OUT headers, exchange properties, variables, the exchange id, and any exception. This constitutes a bypass of the CVE-2026-40860 mitigation rather than a defect in it.

Root Cause

The root cause is an asymmetric trust boundary between JMS producer and consumer logic. The sending side gates ObjectMessage and transferExchange handling behind explicit options, but the receiving side did not require transferExchange to be enabled before applying DefaultExchangeHolder.unmarshal(). Combined with an allow-list that includes internal Camel serialization holders, this permits attacker-controlled Exchange state injection without any gadget chain.

Attack Vector

An attacker with publish rights to a JMS queue or topic consumed by an affected Camel application crafts an ObjectMessage whose top-level object is a DefaultExchangeHolder. The holder is populated with attacker-chosen values built from java.lang and java.util classes only. When the Camel consumer receives the message, JmsBinding.extractBodyFromJms() deserializes the holder, passes the allow-list check, and unmarshals attacker-supplied state into the live Exchange. This enables manipulation of routing decisions, header-driven authorization logic, exchange properties, and error handling flows.

No verified public exploit code is available at the time of publication. Refer to the Apache Camel CVE-2026-43866 Advisory for authoritative technical detail.

Detection Methods for CVE-2026-43866

Indicators of Compromise

Inbound JMS ObjectMessage traffic on destinations consumed by Camel routes, particularly messages whose serialized payload references org.apache.camel.support.DefaultExchangeHolder.
Unexpected changes to Exchange headers, properties, or routing behavior in Camel applications that do not explicitly use transferExchange.
Anomalous exceptions surfacing inside Camel error handlers that were not thrown by application code.

Detection Strategies

Inspect broker audit logs for producers publishing ObjectMessage to destinations that Camel consumers subscribe to, and correlate them against expected trusted producers.
Enable Java serialization filtering (jdk.serialFilter) at the JVM level to log deserialization of DefaultExchangeHolder on consumer JVMs, while noting that filters restricted to allow-list classes cannot block the payload itself.
Review Camel route definitions for JMS-family endpoints where mapJmsMessage is unset or true and transferExchange is not intentionally required.

Monitoring Recommendations

Alert on JMS producers connecting from untrusted network segments to brokers that back Camel consumers.
Monitor Camel application logs for DefaultExchangeHolder.unmarshal invocations correlated with messages from unexpected sources.
Track version inventory for camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, and camel-activemq6 across all deployments.

How to Mitigate CVE-2026-43866

Immediate Actions Required

Upgrade Apache Camel to a fixed release: 4.21.0, 4.18.3, or 4.14.8 (LTS) depending on the release stream in use.
After upgrading, leave the new objectMessageEnabled option at its default value of false unless the destination is fed exclusively by trusted producers.
Audit all JMS broker ACLs to confirm that only trusted principals can publish to destinations consumed by Camel.

Patch Information

Apache Camel 4.21.0, 4.18.3, and 4.14.8 remediate CVE-2026-43866. The fix disables ObjectMessage handling by default in camel-jms, camel-sjms, and the JMS-family components. A new objectMessageEnabled option is introduced at both the component and endpoint level, defaulting to false. Incoming ObjectMessage payloads, including DefaultExchangeHolder, are no longer deserialized unless this option is explicitly enabled. See the Apache Camel CVE-2026-43866 Advisory for the full remediation notice.

Workarounds

Restrict publish access to JMS queues and topics consumed by Camel to trusted producers using broker-side authorization such as ActiveMQ authorization plugins or Artemis role-based ACLs.
Do not expose JMS consumers that map ObjectMessage bodies to untrusted or internet-adjacent networks; keep them on isolated broker segments.
Recognize that a JMS-provider deserialization allow-list does not block this bypass, because the crafted payload uses only universally-trusted java.lang and java.util classes.
Where feasible, refactor routes to consume TextMessage or BytesMessage payloads and disable ObjectMessage support at the broker.

bash

# Configuration example: explicitly disable ObjectMessage handling on a Camel JMS endpoint
# (default in 4.21.0 / 4.18.3 / 4.14.8, shown here for clarity)
from("jms:queue:orders?objectMessageEnabled=false&mapJmsMessage=true")
    .to("direct:process");