Apache Camel Security Advisory - CVE-2026-43866

Apache Camel security advisory: CVE-2026-43866

Severity

HIGH

Summary

Camel JMS deserialization filter bypass: a forged DefaultExchangeHolder carried in a JMS ObjectMessage passes the CVE-2026-40860 class check and is unmarshalled into the Exchange, letting an attacker who can publish an ObjectMessage inject the message body, headers, exchange properties, variables and exception

Versions affected

From 3.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Versions fixed

4.14.8, 4.18.3 and 4.21.0

Description

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.

Notes

The JIRA tickets: https://issues.apache.org/jira/browse/CAMEL-23373 (camel-jms) and https://issues.apache.org/jira/browse/CAMEL-23409 (camel-sjms) refer to the various commits that resolved the issue, and have more details. The camel-jms fix was merged on main in https://github.com/apache/camel/pull/22866 (commit 6cb29c0bbd7d1c46f057eac46c4afa62c9f5e00f) and backported to camel-4.18.x (commit 844bbf8c894c5e2bfa023579db80dcd3354c0e1b) and camel-4.14.x (commit 75d7991b89265a2e8e62c7207165deb88c3a6ef3); the camel-sjms fix was merged on main in https://github.com/apache/camel/pull/22945 (commit 01ead5e8473a2b2fca4902c0236978805b990c31) and backported to camel-4.18.x (commit 81449eb6ef3edf856c84117ce708beb2ada8f650) and camel-4.14.x (commit 17f8fcb22569f4c459b9e53c1485bfc764dc0015). The fix disables the creation and reading of JMS ObjectMessage by default: a new objectMessageEnabled option (annotated security = “insecure:serialization”) defaults to false at the component and endpoint level, and JmsBinding now refuses to extract the body of a received ObjectMessage - and to create an ObjectMessage from a Serializable body or for transferExchange/transferException replies - unless the option is explicitly set, throwing IllegalStateException otherwise. Because the receiving side no longer deserializes ObjectMessage payloads by default, a forged DefaultExchangeHolder can no longer reach DefaultExchangeHolder.unmarshal(). This is a breaking change for routes that rely on JMS ObjectMessage or on transferExchange/transferException, which must now opt in with objectMessageEnabled=true and should only do so against trusted JMS providers (see the 4.21 upgrade guide). The issue is a bypass of CVE-2026-40860 - the deserialization class-filter added for JMS ObjectMessage in camel-jms, camel-sjms and camel-amqp - whose default allow-list included the org.apache.camel.** namespace that DefaultExchangeHolder itself belongs to. It is classified as CWE-502 (Deserialization of Untrusted Data) and CWE-20 (Improper Input Validation), and belongs to the same JMS deserialization-hardening series as CVE-2026-40860 and CVE-2026-42527.

Mitigation

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.

Credit

This issue was discovered by gaorenyusi

References

PGP signed advisory data: CVE-2026-43866.txt.asc
Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-43866