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, excha…

Affected: Maven: org.apache.camel:camel-jms, Maven: org.apache.camel:camel-sjms, Maven: org.apache.camel:camel-sjms2, Maven: org.apache.camel:camel-amqp, Maven: org.apache.camel:camel-activemq, Maven: org.apache.camel:camel-activemq6

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, excha…

eclipse-vertx/vert.x: eclipse-vertx/vert.x: Denial of Service via TLS handshake with wildcard server name io.vertx/vertx-web: Eclipse Vert.x Web Client: Information disclosure via improper cookie domain validation org.apache.camel/camel-vertx-http: Apache Camel (camel-vertx-http): Remote Code Execution via Deserialization of Untrusted Data camel-jms: Apache Camel JMS components: Arbitrary Exchange state injection io.netty/netty-codec-stomp: Netty: Denial of Service vulnerability in STOMP decoder commons-configuration: Apache Commons Configuration: Denial of Service via uncontrolled recursion with crafted YAML input org.apache.camel/camel-mail: Apache Camel Mail Component: Credential exposure and information disclosure via improper input validation of mail headers org.apache.camel/camel-cxf: Apache Camel CXF SOAP: Remote attacker can execute unintended operations via header manipulation camel-vertx-websocket: Apache Camel Vertx Websocket: Server-Side Request Forgery and sensitive data exposure jackson-databind: Jackson-databind: Denial of Service via deeply nested JSON processing org.apache.httpcomponents.core5/httpcore5: Apache HttpComponents Core: Denial of Service via excessive HTTP headers org.apache.httpcomponents.core5/httpcore5-h2: Apache HttpComponents Core: Denial of Service via oversized HTTP/2 HPACK header blocks jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass jackson-databind: Jackson-databind: Security bypass allow…

Ein Angreifer kann mehrere Schwachstellen in Apache Camel ausnutzen, um beliebigen Programmcode auszuführen, Sicherheitsmaßnahmen zu umgehen, serverseitige Request-Forgery durchzuführen, vertrauliche Informationen offenzulegen oder Daten zu manipulieren.