CVE-2026-49086
Camel-Dapr: The Dapr Pub/Sub consumer copied the inbound CloudEvent's pub/sub-name and topic into producer-direction routing headers, allowing an actor who can publish to the subscribed topic to redirect the re-published message to an arbitrary Dapr Pub/Sub component and topic
Description
The camel-dapr Dapr Pub/Sub consumer (DaprPubSubConsumer) copied two fields from each inbound CloudEvent - its Pub/Sub component name and its topic - into the CamelDaprPubSubName and CamelDaprTopic Exchange headers. These two headers are producer-direction routing headers: when the route republishes through a Dapr producer, DaprConfigurationOptionsProxy reads them back and prefers them over the destination configured on the endpoint. As a result, in a route that consumes from one Dapr Pub/Sub topic and republishes to another (for example from('dapr-pubsub:p:t').to('dapr-pubsub:p:other')), an actor able to publish a message to the subscribed topic could set the CloudEvent's pub/sub-name and topic to values of their choosing and cause the re-published message to be delivered to an arbitrary Dapr Pub/Sub component and topic instead of the configured destination - redirecting or exfiltrating the message and bypassing the route's intended routing and any topic-level access controls in the underlying broker. Exploitation requires the ability to publish to the topic the route subscribes to; no other authentication or user interaction is needed.
Mitigation
Credit
This issue was discovered by Leon Zlobecki
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23630 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/23886 (commit 72d13bd13fb5960ea1b367a2e379f017c1720c5c) and backported to camel-4.18.x (commit 86276a2ccc2cf8b09d7efeb38d9770845c4e1bea) and camel-4.14.x (commit c6fc9bb21670e5c65ea14df0f3f29baef78c2028). The fix stops DaprPubSubConsumer from setting the CamelDaprPubSubName and CamelDaprTopic headers (they are producer-direction routing headers read back by DaprConfigurationOptionsProxy and should not be carried out of a consumer); the remaining CloudEvent metadata headers (CamelDaprID, CamelDaprSource, CamelDaprType, CamelDaprSpecificVersion, CamelDaprDataContentType, CamelDaprBinaryData, CamelDaprTime, CamelDaprTraceParent, CamelDaprTraceState) are unchanged. The fix also adds a DaprHeaderFilterStrategy and the standard headerFilterStrategy endpoint option for consistency with the messaging-component family; because the Dapr SDK CloudEvent type exposes a fixed, closed set of fields rather than an arbitrary sender-controlled header map, that strategy is not invoked over the consumer’s fixed-field mapping and the routing-header change is the effective fix. The issue is a routing-override (confused-deputy) problem - untrusted inbound message data was allowed to drive the producer’s destination - classified as CWE-20 (Improper Input Validation) and CWE-441 (Unintended Proxy or Intermediary). It is conceptually related to the Camel message-header-injection family (CVE-2025-27636 and follow-ons), although here the headers are Camel-prefixed and the issue is the consumer propagating producer-direction routing headers rather than a missing inbound header filter.