CVE-2026-63621
Camel-Knative: CloudEvent extension fields received in structured content mode were mapped onto message headers without applying any header filter strategy, so an untrusted sender could inject Camel-internal headers
Description
The camel-knative consumer accepts CloudEvents in two content modes. In binary mode the event attributes arrive as HTTP headers, and KnativeHttpConsumer maps them onto the message through a HeaderFilterStrategy, so Camel-internal headers are not propagated. In structured content mode, selected by the Content-Type application/cloudevents+json, the whole event is a JSON document in the request body: AbstractCloudEventProcessor parses that body and CloudEventProcessors then mapped every remaining field - the CloudEvent extension attributes, whose names are chosen by the sender - directly onto the message headers with setHeader(key.toLowerCase(Locale.US), value), applying no HeaderFilterStrategy at all. The structured path therefore bypassed the filtering that the binary path performed, and it did so for every supported CloudEvents spec version. The CloudEvent processor runs in a pipeline ahead of the route, so any header injected this way is already present when the route begins. Because Camel message headers are held in a case-insensitive map, a lower-cased extension name collides with the equivalently named Camel-internal header - for example an extension named camelhttpuri lands on the same entry as CamelHttpUri. An untrusted sender able to reach the Knative consumer could therefore set Camel-internal headers that the route and its downstream components act on. The concrete impact depends on the route: as one example, a downstream HTTP producer overrides its target URI from CamelHttpUri unless bridgeEndpoint is enabled, so an injected value can redirect the outbound request and produce server-side request forgery. This was an incomplete fix - inbound header filtering had previously been added to the Knative header filter strategy, which covers the binary path only, leaving the structured path bypassing the strategy entirely. It belongs to the same family as the Camel header-injection issues published previously for other consumers.
Mitigation
Credit
This issue was discovered by Andrea Cosentino from Apache Software Foundation
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24084 refers to the various commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/24724 (commit bbf680af8af4a39f808727758e72d469c2eec539) and backported to camel-4.18.x in https://github.com/apache/camel/pull/24753 (commit 5c7a8dbf1f1ed92bb4f289a50cc1765095054112) and to camel-4.14.x in https://github.com/apache/camel/pull/24751 (commit 4eb26807d40420abf45253286ce3d07c2fba448c). A follow-up documentation change, https://github.com/apache/camel/pull/24768 (commit 7a46dbbca88fba647c89da86ed172251c4622fc3), synchronised the upgrade-guide note for the maintenance branches onto main.
The fix gives AbstractCloudEventProcessor a HeaderFilterStrategy and a shared mapExtensionAsHeader helper, and routes the structured-mode extension mapping for all supported CloudEvents spec versions through that helper, so the same filtering is applied on both content modes and Camel-internal header names are matched case-insensitively. Ordinary CloudEvent extension attributes are unaffected and continue to be propagated. The strategy is obtained differently per branch: on main the component relies on the DefaultHeaderFilterStrategy default that already filters Camel-prefixed headers inbound, whereas the 4.18.4 and 4.14.9 backports construct the strategy explicitly with setInFilterStartsWith, because that default is not present on those branches. The issue is classified as CWE-20 (Improper Input Validation) and is a header-injection issue of the same class as the Camel consumer advisories published previously, where a consumer maps sender-controlled names into the Exchange header map without a strict, case-insensitive HeaderFilterStrategy.