Apache Camel’s CXF SOAP component uses two Exchange headers, operationName and operationNamespace, to invoke SOAP operations on a backend service. The header names are defined as plain strings instead of camel‑prefixed identifiers, allowing them to bypass the HttpHeaderFilterStrategy that normally blocks non‑Camel headers at the HTTP boundary. When a route bridges an HTTP consumer into a CXF producer, an attacker can set these headers in an inbound request and the vulnerability is not listed in CISA’s KEV catalog, indicating a low probability of exploitation under typical conditions. However the attack vector is an external HTTP request to a route that bridges a consumer (for example platform-http) into a CXF producer and no authentication is required, making it easy for a malicious client to alter the headers. The CVSS score of 7.5 signals high severity. The official fix renames the headers to CamelCxfOperationName and CamelCxfOperationNamespace and filters them at transport boundaries. Until a patch can be applied, removing the untrusted headers before they reach the CXF producer and setting the desired operation from a trusted source mitigates the risk.

All Apache Camel releases from 4.0.0 up to, but not including, 4.14.8; from 4.15.0 up to, but not including, 4.18.3; and from 4.19.0 up to, but not including, 4.21.0. The vulnerable code resides in both the camel‑cxf producer and the shared camel‑cxf‑common module that defines the operationName and operationNamespace constants.

The vulnerability carries a CVSS score of 7.5, indicating a high severity scenario. The EPSS is below 1% and the vulnerability is not listed in the CISA KEV catalog, suggesting a low probability of real-world exploitation under typical conditions. The attack vector is an external HTTP request to a Camel route that bridges a consumer like platform-http into a CXF producer; authentication is not required when the consumer is unauthenticated, making the route publicly exposed to manipulation. Because the HTTP header filter does not block the non‑Camel prefixed headers, an attacker can directly control the SOAP operation selected by the backend service, potentially redirecting read actions to destructive ones. This vulnerability should be treated with high priority and addressed promptly with the available patch or interim controls.