Apache Camel CVE-2026-85254

Exploitation requires that traffic reach a vulnerable Apache Camel platform-http endpoint (4.0.0 before 4.18.5, or 4.19.0 before 4.22.1) and that one of the COMMON_HTTP_REQUEST_HEADERS (e.g. Authorization, Cookie, Proxy-Authorization) is submitted. The bypass is unconditional for any request over an HTTP/2 connection (HTTP/2 mandates lowercase field names, which never matched the canonically-capitalized suppression set); over HTTP/1.1 it requires the attacker to vary the header casing to defeat the exact-case comparison. Real-world impact is further gated by what sits in front of the endpoint - meaningful response-splitting or cache-poisoning requires a downstream cache or proxy that will act on the reflected content; endpoints with no fronting cache and no sensitive reflected headers face limited practical risk. Mitigations without upgrading: strip the affected headers in front of the Camel endpoint or remove them from the response within the route.

This is a moderate-severity information-handling flaw, not an emergency. The input CVSS of 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) indicates a network-reachable, low-complexity, unauthenticated issue with low confidentiality and low integrity impact and no availability impact, which is consistent with the described response-splitting/cache-poisoning primitive rather than direct code execution. No EPSS score, CISA KEV listing, or POC is present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the practical risk is therefore driven by the vulnerability class and the attacker's ability to influence whatever cache/proxy sits in front of the Camel endpoint rather than by any observed campaign. A notable nuance confirmed by the vendor advisory and the PR diff is that the flaw is unconditional over HTTP/2 (field names are lowercase on the wire, so the case-sensitive suppression never matched) but only opportunistically bypassable over HTTP/1.1 by varying header casing - a real-world severity amplifier for the increasingly common HTTP/2 deployments. The signals are internally consistent (network vector, low complexity, no auth all align with the described remote header-reflection behavior); the main missing data points are EPSS and any exploitation telemetry, so prioritization should be routine patching within normal cycles unless the Camel endpoint fronts a shared cache or sensitive headers (Authorization, Cookie) are in play.

An attacker sends an HTTP request to a Camel platform-http endpoint over HTTP/2 (or over HTTP/1.1 using non-canonical header casing) containing attacker-controlled values in headers that Camel is supposed to suppress from the response. Because the suppression guard compared header names case-sensitively, the chosen content is echoed back in the response, which the attacker uses as the basis for response-splitting or cache-poisoning against a downstream cache or proxy. No public exploit is identified at time of analysis, but the preconditions are low given AC:L and no authentication requirement (PR:N).