CVE-2026-63621: Apache Camel: Camel-Knative: CloudEvent extension fields received in structured content mode were mapped onto message headers without applying any header filter strategy
Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Apache Camel Knative component
The Knative consumer in camel-knative maps inbound CloudEvent attributes onto Camel message headers. In binary content mode the HTTP-header path filters Camel-internal headers through KnativeHttpHeaderFilterStrategy, but in structured content mode (Content-Type application/cloudevents+json) the CloudEvent extension fields are read directly from the JSON body and every extension key is copied into the Exchange headers without applying any HeaderFilterStrategy (CloudEventProcessors, spec versions 1.0, 1.0.1 and 1.0.2). As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelHttpUri, CamelHttpPath, CamelFileName) via a structured-mode CloudEvent request, matched case-insensitively against Camel's header map. When a route forwards messages from a Knative consumer to a header-driven component such as camel-http or camel-file, the injected headers override configured values, enabling server-side request forgery (SSRF), path traversal or message-dispatch redirection depending on the route. This is an incomplete fix of the inbound header filtering previously added for the binary content-mode path, and is the same pattern addressed in camel-cxf/camel-knative (CVE-2026-47323), camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and the non-HTTP strategies (CVE-2026-40453).
This issue affects Apache Camel: from 3.15.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.4. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. The non-LTS releases 4.15.0 through 4.17.0 and 4.19.0 through 4.21.0 are affected but do not receive a maintenance fix; users on those versions should upgrade to 4.18.4 or 4.22.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Camel (Camel-Knative / camel-knative component)to a version that resolves this vulnerability.Fixed in 4.14.9 - Upgrade
Upgrade
Apache Camel (Camel-Knative / camel-knative component)to a version that resolves this vulnerability.Fixed in 4.18.4 - Upgrade
Upgrade
Apache Camel (Camel-Knative / camel-knative component)to a version that resolves this vulnerability.Fixed in 4.22.0
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments are exposed when a Camel Knative consumer accepts structured CloudEvents with Content-Type application/cloudevents+json and forwards messages to components that act on message headers, such as camel-http or camel-file. The impact depends on the downstream route: it can include SSRF, path traversal, or message-dispatch redirection.
What does an attacker need to exploit this issue?
An attacker needs to be able to send an unauthenticated structured-mode CloudEvent request to the Knative consumer. They can place Camel-internal header names, including CamelHttpUri, CamelHttpPath, or CamelFileName, in CloudEvent extension fields; matching against Camel's header map is case-insensitive.
Is the binary CloudEvent HTTP-header path affected in the same way?
No. In binary content mode, the HTTP-header path applies KnativeHttpHeaderFilterStrategy to filter Camel-internal headers. The missing header filtering occurs when extension fields are read from the JSON body in structured content mode.
How can I identify potentially affected routes?
Review Knative consumer routes that accept application/cloudevents+json and inspect whether they pass inbound messages to header-driven endpoints. Routes using headers to determine HTTP destinations, HTTP paths, file names, or dispatch behavior are potential candidates.