CVE-2026-85254
Camel-Platform-HTTP: request-header echo suppression bypass - the check that stops a request header being echoed into the response compared header names case sensitively, so a differently cased name defeated it, and under HTTP/2 it never matched at all
Description
The guard that prevents a request header being reflected into the response compared header names case sensitively, while HTTP header names are case insensitive. A caller could therefore defeat the suppression simply by varying the case of the header name. HTTP/2 makes the problem unconditional rather than optional: the protocol requires header names to be lowercase on the wire, so the comparison never matched and the suppression was inert for every request on an HTTP/2 connection. The consequence is that content the caller chose is echoed back in the response, which is the basis for response-splitting and cache-poisoning style attacks against whatever sits in front of the Camel endpoint.
Mitigation
Credit
This issue was discovered by Claude Security Scan Tool
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24453 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/25831 (commit 126c79bdf3f171184461f987c143b5a818df4d81), backported to camel-4.22.x in https://github.com/apache/camel/pull/25940 (commit 260989268cbc6d258b1fcba63770be8ebbec40cb) and to camel-4.18.x in https://github.com/apache/camel/pull/25942 (commit af1efbcccf5882b1ef0094db718972da3190e7e9).
The issue is classified as CWE-178 Improper Handling of Case Sensitivity. The camel-4.14.x line reached end of life before this fix and does not receive it; deployments on 4.14.x should move to 4.18.5 or later.