CVE-2026-40860: Apache Camel: Unsafe Deserialization of JMS ObjectMessage in camel-jms, camel-sjms, camel-sjms2 and camel-amqp
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6.
This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.
Users are recommended to upgrade to version 4.20.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.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
Security readout for executives and security teams
Plain-English summary
Apache Camel applications that consume JMS messages may deserialize attacker-supplied objects by default. If an attacker can publish to a consumed queue or topic, and a usable gadget chain exists, this can lead to remote code execution.
Executive priority
Treat as urgent for any Camel-based messaging service with reachable brokers. The CVSS 9.8 rating reflects network-reachable, unauthenticated, no-user-interaction impact when prerequisites are met.
Technical view
JmsBinding.extractBodyFromJms() and related bindings called ObjectMessage.getObject() without ObjectInputFilter, allowlist, or denylist checks. The vulnerable path applies when mapJmsMessage is enabled, which the source states is the default.
Likely exposure
Exposure is likely where Apache Camel versions 3.0.0 through affected 4.x ranges consume JMS, SJMS, SJMS2, AMQP, ActiveMQ, or ActiveMQ6 messages from queues or topics that untrusted producers can reach.
Exploitation context
The provided sources do not show active exploitation or KEV listing. Exploitation requires the attacker to publish a crafted JMS ObjectMessage to a Camel-consumed destination and a deserialization gadget chain on the application classpath.
Researcher notes
Focus triage on JMS ObjectMessage consumers and inherited bindings. RCE is conditional on publish access and classpath gadget availability, so validation should combine dependency, route, broker ACL, and deployed-version evidence.
Mitigation direction
Upgrade Apache Camel to 4.20.0 where possible.
Upgrade 4.14.x LTS deployments to 4.14.7.
Upgrade 4.18.x deployments to 4.18.2.
Restrict producer access to Camel-consumed queues and topics.
Check Apache and downstream vendor guidance for product-specific fixes.
Validation and detection
Inventory Apache Camel versions across applications and services.
Identify use of camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, or camel-activemq6.
Find Camel routes consuming JMS queues or topics.
Confirm whether mapJmsMessage is enabled or defaulted.
Verify broker permissions prevent untrusted publishing to consumed destinations.
Confirm patched Camel versions are deployed in runtime artifacts.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-502: Code execution behavior lookup
Code execution and unsafe deserialization weaknesses often justify reviewing execution behavior and process telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
3ADP providers
7Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-502 · source CWE mapping
Deserialization of Untrusted Data
Deserialization of Untrusted Data represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.