CVE-2026-46592: Apache Camel CXF Confused Deputy Vulnerability – HTTP Header Injection

Technical summary

The camel-cxf producer uses Exchange headers operationName and operationNamespace (defined as plain strings in CxfConstants, without the 'Camel/' namespace prefix) to determine which WSDL operation to invoke on the backend service. The HttpHeaderFilterStrategy is designed to block headers in the Camel namespace at HTTP transport boundaries, but because these operation-selection headers lack the protective prefix, they are not filtered when ingressed from HTTP requests. In routes that chain an HTTP consumer (e.g., platform-http) to a cxf: producer without proper isolation, this allows an unauthenticated HTTP client to inject or modify these headers, causing the CXF producer to resolve and execute an arbitrary WSDL operation instead of the one the route developer intended. This is a classic confused-deputy vulnerability in which an intermediary (the Camel route) is tricked into performing an action on behalf of the attacker against a backend service that trusts the intermediary.

Business impact

Organizations deploying Apache Camel to bridge HTTP APIs to SOAP backends face significant risk: an attacker could invoke unintended backend operations without authentication. Depending on the backend service's capabilities, this could result in unauthorized data modification, deletion, or exposure. For example, a route intended to expose a read-only data lookup could be exploited to trigger account creation, fund transfers, or configuration changes on the backend. The impact is highest in multi-tenant or open-network deployments where the HTTP consumer is exposed to untrusted clients.

Affected systems

Apache Camel versions 4.0.0 through 4.21.0 (exclusive) are vulnerable. This spans three release streams: 4.0.0–4.14.7, 4.15.0–4.18.2, and 4.19.0–4.20.x. The vulnerability also affects camel-cxfrs due to shared code in camel-cxf-common. Any Camel deployment using the cxf: producer component in a route that accepts HTTP input is at risk, particularly in microservices and API gateway architectures.

Exploitability

Exploitability is very high. No authentication is required if the HTTP consumer is unauthenticated, and the attack requires only a crafted HTTP header—no special knowledge of backend credentials or WSDL details beyond what the route exposes. The attack is reliable and deterministic, executed by any HTTP client capable of setting custom headers. There is no user interaction or complex environmental setup required.

Remediation

Upgrade immediately to Apache Camel 4.21.0, or to 4.14.8 / 4.18.3 if remaining on those LTS/release branches. After upgrading, the operation-selection headers are renamed to CamelCxfOperationName and CamelCxfOperationNamespace and are properly filtered at transport boundaries. Consult the Camel 4.21 upgrade guide for guidance on the cross-transport carrier-header pattern if your route relies on passing operation names across transport layers. For organizations unable to patch immediately, implement compensating controls: strip operationName and operationNamespace headers from all untrusted HTTP ingress before the cxf: producer, and hard-code or derive the operation name from trusted route logic only.

Patch guidance

Verify and apply upgrades according to your Camel release stream: upgrade to 4.21.0 (or later) for current deployments, 4.14.8 for 4.14.x LTS users, or 4.18.3 for 4.18.x branch users. Test the upgrade in a staging environment, as the header rename will affect any route logic that explicitly references the old constant names (CxfConstants.OPERATION_NAME). Review the Camel 4.21 release notes and upgrade guide for migration details. If your routes programmatically set or pass these headers internally, update your code to use the new CamelCxf-prefixed constants.

Detection guidance

Monitor HTTP request logs and Camel route metrics for attempts to inject or modify operationName and operationNamespace headers in requests destined for cxf: producers. Look for header values that differ from the intended operation or that match WSDL operations not exposed by the route's API contract. If you have access to Camel's Exchange debug logs, correlate unexpected SOAP operation invocations with concurrent HTTP requests carrying these headers. In a WAF or API gateway layer, create rules to strip or reject these headers at the boundary before they reach Camel.

Why prioritize this

This vulnerability warrants immediate action because it combines high exploitability (no auth required, trivial attack), high impact (arbitrary operation invocation on backend services), and broad scope (any HTTP-to-SOAP bridge). The CVSS 7.5 (HIGH) score reflects the integrity risk and network-accessible attack vector. Organizations bridging HTTP and SOAP should prioritize this above lower-scoring issues affecting less critical integrations.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects an attack requiring no privileges or user interaction, network accessibility, and high impact on confidentiality (an attacker could invoke operations that expose data) and integrity (unintended state changes on the backend). The scope is unchanged (impact is within the backend service only, not on the Camel system itself). The score does not account for environmental factors such as whether your HTTP consumer is exposed to the public internet or restricted to internal networks—assess your specific deployment topology when determining remediation urgency.

Frequently asked questions