Gaorenyusi

#1907of 55,137
124.9Total CVSS
Vulnerabilities · 14
Medium
1
High
5
Critical
8
PT-2026-55885
7.5
2026-07-06
Apache · Apache Camel · CVE-2026-43866
**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 3.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** An issue exists in the Apache Camel JMS component where the `JmsBinding.extractBodyFromJms()` function in `camel-jms` (and equivalent bindings in `camel-sjms`, `camel-sjms2`, `camel-amqp`, `camel-activemq`, and `camel-activemq6`) improperly handles the deserialization of incoming JMS ObjectMessage payloads when the `mapJmsMessage` option is enabled. Although a post-deserialization class check was implemented to restrict allowed classes, the `org.apache.camel.support.DefaultExchangeHolder` class is included in the allow-list. An attacker can send a crafted ObjectMessage with a `DefaultExchangeHolder` as the top-level object to bypass this check. The system then calls `DefaultExchangeHolder.unmarshal()`, allowing the attacker to inject arbitrary Exchange state—including message bodies, headers, properties, and variables—using only trusted `java.lang` and `java.util` types. This allows for the manipulation of routing, headers, exchange properties, and error handling without requiring a deserialization gadget chain. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS release stream. Upgrade to version 4.18.3 for those on the 4.18.x release stream. Restrict publish access to the queues and topics consumed by Camel to trusted producers via JMS broker authorization. Avoid exposing JMS consumers that map ObjectMessage bodies to untrusted networks.
PT-2026-55884
8.1
2026-07-06
Apache · Apache Camel · CVE-2026-43865
**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** The camel-hazelcast component manages Hazelcast instances using a default configuration that lacks a Java deserialization filter. When Camel builds the Hazelcast Config without a user-supplied `HazelcastInstance`, `hazelcastConfigUri`, or referenced Config bean, objects received via the Hazelcast cluster protocol are deserialized using `ObjectInputStream.readObject()` before processing. An attacker capable of joining or reaching the Hazelcast cluster can send a crafted serialized Java object, leading to remote code execution on every Camel node. This issue affects any route using a hazelcast consumer (including hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, and hazelcast-set), as well as the `HazelcastAggregationRepository` and `HazelcastIdempotentRepository`, when the managed instance uses the default configuration. **Recommendations** Upgrade to version 4.14.8 for those on the 4.14.x LTS releases stream. Upgrade to version 4.18.3 for those on the 4.18.x releases stream. Upgrade to version 4.21.0 for all other affected versions. Configure a deserialization filter on the Hazelcast instance via `Hazelcast JavaSerializationFilterConfig` or the JVM-wide system property `-Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!*`. Enable Hazelcast cluster authentication and TLS to restrict cluster access.