CVE-2026-43866

High [CVE-2026-40860 +1] Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component

CVE-2026-43866Source published Jul 6, 2026Source updated Jul 7, 2026

This bulletin covers 2 CVEs. The products, versions, score and guidance below describe the bulletin; check its source for applicability to this specific CVE.

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…

Affected products in this advisory

• Apache Camel JMS

Source-reported affected versions

• 3.0.0 through 4.14.8
• 4.15.0 through 4.18.3
• 4.19.0 through 4.21.0
• 4.19.0 through 4.21.0.

Source-reported fixed versions

• 4.21.0
• 4.14.8
• 4.18.3

Mitigation guidance

• 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.

Workarounds

• 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.

High [CVE-2026-43866] Apache Camel JMS components: Arbitrary Exchange state injection

CVE-2026-43866Source published Jul 6, 2026Source updated Jul 6, 2026

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…

Affected products in this advisory

• Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16

Source-reported affected versions

• < 3.0.0
• < 4.14.8
• < 4.15.0
• < 4.18.3

2 more entries in the full advisory.

Source-reported fixed versions

• 4.21.0
• 4.14
• 4.14.8
• 4.18

3 more entries in the full advisory.

Mitigation guidance

• Restrict publish access to JMS queues and topics consumed by Camel applications via broker authorization. Note that a JMS-provider deserialization allow-list does not mitigate this specific bypass because the crafted payload uses only universally-trusted classes within the org.apache.camel namespace.