CVE-2026-43866
Apache Camel, Apache Camel: Camel JMS - CVE-2026-40860 fix bypass via DefaultExchangeHolder
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.
INFO
Published Date :
July 6, 2026, 9:16 a.m.
Last Modified :
Oct. 25, 2026, 3:10 p.m.
Remotely Exploit :
Yes !
Source :
[email protected]
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | |||||
| CVSS 3.1 | HIGH | 134c704f-9b21-4f2e-91b3-4a467353bcc0 |
Solution
- Upgrade to Apache Camel 4.21.0 or specific LTS.
- Disable ObjectMessage deserialization by setting objectMessageEnabled=false.
- Restrict publish access to JMS queues and topics.
- Avoid exposing JMS consumers to untrusted networks.
Public PoC/Exploit Available at Github
CVE-2026-43866 has a 2 public
PoC/Exploit available at Github.
Go to the Public Exploits tab to see the list.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-43866.
| URL | Resource |
|---|---|
| https://camel.apache.org/security/CVE-2026-43866.html | Mitigation Vendor Advisory |
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-43866 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-43866
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Reproducer for CVE-2026-43866 — Apache Camel camel-jms forged DefaultExchangeHolder bypass of the CVE-2026-40860 deserialization filter (Exchange-state injection)
Dockerfile Java
📡 PoC auto collect from GitHub. ⚠️ Be careful Malware.
security cve exploit poc vulnerability
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-43866 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-43866 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Oct. 25, 2026
Action Type Old Value New Value Added Translation Title: Apache Camel de Apache Software Foundation, Description: Vulnerabilidad de deserialización de datos no confiables en Apache Camel, componente JMS de Apache Camel. JmsBinding.extractBodyFromJms() en camel-jms - y el JmsBinding equivalente en camel-sjms - deserializa la carga útil de un ObjectMessage JMS entrante a través de jakarta.jms.ObjectMessage.getObject() siempre que la opción mapJmsMessage esté habilitada (el valor predeterminado) y Camel actúe como un consumidor JMS. El endurecimiento CVE-2026-40860 añadió una verificación de clase post-deserialización que rechaza clases fuera de la lista de permitidos predeterminada java.;javax.;org.apache.camel.**;!*. Sin embargo, org.apache.camel.support.DefaultExchangeHolder en sí reside en el espacio de nombres org.apache.camel.** de la lista de permitidos, por lo que un ObjectMessage cuyo objeto de nivel superior es un DefaultExchangeHolder pasa la verificación. El lado receptor luego llama a DefaultExchangeHolder.unmarshal() en él sin requerir que la opción transferExchange esté habilitada - un límite de confianza asimétrico, ya que el lado emisor controla el manejo de ObjectMessage y transferExchange pero el lado receptor no lo hizo - escribiendo cada campo no nulo del contenedor en el Exchange: el cuerpo del mensaje, los encabezados IN y OUT, las propiedades del intercambio, las variables, el ID del intercambio y la excepción. Un atacante que puede publicar un ObjectMessage en una cola o tema consumido por una aplicación Camel afectada puede, por lo tanto, inyectar un estado de Exchange arbitrario utilizando solo tipos java.lang y java.util universalmente confiables, sin requerir una cadena de gadgets de deserialización, para manipular el enrutamiento y los encabezados, las propiedades del intercambio y el manejo de errores. El mismo manejo se aplica a camel-sjms y camel-sjms2, y a los componentes de la familia JMS construidos sobre JmsComponent y JmsBinding: camel-amqp, camel-activemq y camel-activemq6. Esto es un bypass de la corrección CVE-2026-40860 en lugar de un defecto en ella. Este problema afecta a Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0; Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0. Se recomienda a los usuarios actualizar a la versión 4.21.0, que corrige el problema. Si los usuarios están en la rama de versiones LTS 4.14.x, se sugiere que actualicen a 4.14.8. Si los usuarios están en la rama de versiones 4.18.x, se sugiere que actualicen a 4.18.3. Después de la actualización, el manejo de ObjectMessage JMS está deshabilitado por defecto en camel-jms, camel-sjms y los componentes de la familia JMS (una nueva opción objectMessageEnabled por defecto es false a nivel de componente y de endpoint), por lo que un ObjectMessage entrante - incluyendo una carga útil de DefaultExchangeHolder - ya no se deserializa a menos que la opción esté explícitamente habilitada; solo establezca objectMessageEnabled=true cuando el destino JMS consumido sea alimentado exclusivamente por productores confiables. Para implementaciones que no pueden actualizarse inmediatamente, restrinja el acceso de publicación a las colas y temas consumidos por Camel a productores confiables a través de la autorización del broker JMS, y no exponga consumidores JMS que mapeen cuerpos de ObjectMessage a redes no confiables; una lista de permitidos de deserialización del proveedor JMS no mitiga este bypass específico porque la carga útil creada utiliza solo clases universalmente confiables. -
Initial Analysis by [email protected]
Jul. 07, 2026
Action Type Old Value New Value Added CPE Configuration OR *cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:* versions from (including) 4.15.0 up to (excluding) 4.18.3 *cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:* versions from (including) 4.19.0 up to (excluding) 4.21.0 *cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:* versions from (including) 3.0.0 up to (excluding) 4.14.8 Added Reference Type Apache Software Foundation: https://camel.apache.org/security/CVE-2026-43866.html Types: Mitigation, Vendor Advisory -
CVE Modified by 134c704f-9b21-4f2e-91b3-4a467353bcc0
Jul. 06, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L Added SSVC {'id': 'CVE-2026-43866', 'role': 'CISA Coordinator', 'options': [{'exploitation': 'none'}, {'automatable': 'yes'}, {'technicalImpact': 'partial'}], 'version': '2.0.3', 'timestamp': '2026-07-06T19:09:40.858071Z'} -
New CVE Received by [email protected]
Jul. 06, 2026
Action Type Old Value New Value Added Affected [{'vendor': 'Apache Software Foundation', 'product': 'Apache Camel', 'versions': [{'status': 'affected', 'version': '3.0.0', 'lessThan': '4.14.8', 'versionType': 'semver'}, {'status': 'affected', 'version': '4.15.0', 'lessThan': '4.18.3', 'versionType': 'semver'}, {'status': 'affected', 'version': '4.19.0', 'lessThan': '4.21.0', 'versionType': 'semver'}], 'packageName': 'org.apache.camel:camel-jms', 'collectionURL': 'https://repo.maven.apache.org/maven2', 'defaultStatus': 'unaffected'}, {'vendor': 'Apache Software Foundation', 'product': 'Apache Camel', 'versions': [{'status': 'affected', 'version': '3.0.0', 'lessThan': '4.14.8', 'versionType': 'semver'}, {'status': 'affected', 'version': '4.15.0', 'lessThan': '4.18.3', 'versionType': 'semver'}, {'status': 'affected', 'version': '4.19.0', 'lessThan': '4.21.0', 'versionType': 'semver'}], 'packageName': 'org.apache.camel:camel-sjms', 'collectionURL': 'https://repo.maven.apache.org/maven2', 'defaultStatus': 'unaffected'}] Added 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. Added CWE CWE-502 Added Reference https://camel.apache.org/security/CVE-2026-43866.html