CVE-2026-46592
Camel-CXF: The SOAP operation-selection headers used non-Camel-prefixed names (operationName, operationNamespace) that bypass the HTTP header filter, allowing an HTTP client to redirect the invoked SOAP operation
Description
The camel-cxf producer selects which SOAP operation to invoke on the backend service from the operationName (and operationNamespace) Exchange header, whose constant values (CxfConstants.OPERATION_NAME / OPERATION_NAMESPACE) were the plain strings operationName / operationNamespace. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a cxf: producer, any HTTP client could therefore set the operationName header and have CxfProducer resolve and invoke a different WSDL operation than the route intended - for example replacing a read operation with a destructive one - against the backend SOAP service (a confused-deputy redirection). The constant is defined in the shared camel-cxf-common module, so the same non-prefixed names also applied to camel-cxfrs. No credentials are required when the bridging consumer is unauthenticated.
Mitigation
Credit
This issue was discovered by Yu Bao from PayPal
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23526 refers to the various commits that resolved the issue, and have more details. The fix was merged on main in https://github.com/apache/camel/pull/23326 (commit 7240570a05687792c95badfa8d11ed2644117230) and backported to camel-4.18.x (commit 36a5088b58be38317a8f974ffda2a262fa00b4e4) and camel-4.14.x (commit 0138da45fc9428172c1585ab4561d42e8868cf49). The fix renames the camel-cxf Exchange header values to the Camel convention - CxfConstants.OPERATION_NAME from operationName to CamelCxfOperationName, and CxfConstants.OPERATION_NAMESPACE from operationNamespace to CamelCxfOperationNamespace - so they are filtered on the HTTP boundary (and by other transport HeaderFilterStrategy implementations) like every other Camel control header. The Java field names are unchanged, so code referencing CxfConstants.OPERATION_NAME keeps working; this is a breaking change for routes that set or read these headers by their raw string value and for the camel-cxfrs SimpleConsumer dispatch idiom, and routes that bridge an external transport into a cxf: producer and select the operation from a sender-supplied header must now carry it in a non-Camel-prefixed application header and map it to CamelCxfOperationName between the transport from and the cxf: to (see the 4.21 upgrade guide). The issue is classified as CWE-20 (Improper Input Validation) and CWE-441 (Unintended Proxy or Intermediary - Confused Deputy). It belongs to the same Camel header-injection family as CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-46454 and CVE-2026-47323, and shares the non-Camel-prefixed-header-constant root cause with the camel-elasticsearch SEARCH_QUERY and camel-lucene QUERY siblings.