Apache Camel Security Advisory - CVE-2026-63621

Apache Camel security advisory: CVE-2026-63621

Severity

MEDIUM

Summary

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

Versions affected

From 3.15.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.

Versions fixed

4.14.9, 4.18.4 and 4.22.0

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.

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.

Mitigation

Users are recommended to upgrade to version 4.22.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.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. The fix landed on the maintenance lines and on main only; the non-LTS 4.15.x, 4.16.x, 4.17.x, 4.19.x, 4.20.x and 4.21.x releases are affected and are no longer maintained, so users on those lines should move to 4.18.4 or 4.22.0. For deployments that cannot upgrade immediately, strip Camel-internal headers at the start of any route fed by a Knative consumer, for example with removeHeaders(“Camel*”) placed before any processor that dispatches on header values, and set bridgeEndpoint on downstream HTTP producers so that their target URI cannot be overridden by an inbound header. As defence in depth, treat CloudEvent extension attributes arriving from an untrusted sender as untrusted input and do not let them reach a Camel-internal header name.

Credit

This issue was discovered by Andrea Cosentino from Apache Software Foundation

References

PGP signed advisory data: CVE-2026-63621.txt.asc
Mitre CVE Entry: https://www.cve.org/CVERecord?id=CVE-2026-63621