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 HTTP call to any WSDL operation the route was not intended to expose, potentially triggering destructive actions on the backend service.

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 EPSS score is below 1% 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, which are properly filtered 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.