CVE-2026-46592: Apache Camel CXF SOAP RCE Vulnerability

CVE-2026-46592 Overview

CVE-2026-46592 is an improper input validation vulnerability in the Apache Camel CXF SOAP component that enables a confused deputy attack [CWE-20]. The camel-cxf producer selects SOAP operations from the operationName and operationNamespace Exchange headers. Because these constants lack the Camel/camel prefix, the HttpHeaderFilterStrategy does not block them at the HTTP boundary. Remote attackers can inject these headers into HTTP requests and redirect the producer to invoke arbitrary WSDL operations on the backend SOAP service. The same defect applies to camel-cxfrs through the shared camel-cxf-common module.

Critical Impact
Unauthenticated attackers can force the cxf: producer to invoke unintended SOAP operations against backend services, potentially replacing read operations with destructive ones without any credentials.

Affected Products

Apache Camel 4.0.0 through 4.14.7
Apache Camel 4.15.0 through 4.18.2
Apache Camel 4.19.0 through 4.20.x

Discovery Timeline

2026-07-06 - CVE-2026-46592 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-46592

Vulnerability Analysis

Apache Camel routes commonly bridge an HTTP consumer such as platform-http into a cxf: producer that forwards requests to a backend SOAP service. The producer chooses which WSDL operation to invoke by reading the operationName and operationNamespace values from the Exchange headers. These constants are defined in CxfConstants.OPERATION_NAME and CxfConstants.OPERATION_NAMESPACE.

Camel applies HttpHeaderFilterStrategy at the HTTP boundary to prevent inbound headers from silently controlling internal routing. That filter only blocks header names beginning with the Camel or camel prefix. The two operation-selection headers use plain, unprefixed names and therefore pass through the filter untouched. An attacker sending an HTTP request to the bridging consumer can inject either header and control which SOAP operation the producer invokes.

The result is a confused deputy: the Camel route holds trusted access to the backend SOAP endpoint, but the operation to invoke is chosen from attacker-controlled input. A route intended to expose a read-only query can be steered into invoking a destructive operation exposed by the same WSDL.

Root Cause

The root cause is naming and filter scope. The Camel-internal constants used to select CXF operations were never prefixed with Camel, and the HTTP header filter only rejects the prefixed namespace. Trust boundary enforcement between untrusted HTTP ingress and trusted CXF producer state was therefore incomplete.

Attack Vector

The attack is network-based and requires no authentication when the bridging HTTP consumer is unauthenticated. An attacker submits a normal HTTP request to the Camel endpoint and adds an operationName header, optionally with operationNamespace. The CxfProducer resolves the specified operation on the target WSDL and invokes it, bypassing the operation implied by the route logic.

No verified public proof of concept is available. See the Apache Camel CVE-2026-46592 Advisory for vendor technical details.

Detection Methods for CVE-2026-46592

Indicators of Compromise

HTTP requests to Camel endpoints containing operationName or operationNamespace headers from untrusted clients.
Backend SOAP service logs showing invocations of operations that are not referenced by any deployed Camel route.
Unexpected write, delete, or administrative SOAP operations executed shortly after inbound HTTP requests to a Camel bridge.

Detection Strategies

Inspect HTTP access logs and reverse proxy telemetry for the header names operationName and operationNamespace on requests reaching Camel HTTP consumers.
Correlate inbound HTTP requests with downstream CXF producer activity to identify mismatches between route-declared operations and actually invoked WSDL operations.
Enumerate deployed Camel routes that bridge platform-http, jetty, netty-http, or servlet consumers into cxf: or cxfrs: producers, and treat them as high-priority monitoring targets.

Monitoring Recommendations

Enable verbose logging on CxfProducer to record the resolved operation name for every invocation.
Alert on any SOAP operation invocation that falls outside an allow-list of operations expected for each route.
Baseline normal HTTP header sets reaching Camel endpoints and flag deviations that include CXF operation-selection headers.

How to Mitigate CVE-2026-46592

Immediate Actions Required

Upgrade Apache Camel to a fixed release: 4.21.0, 4.18.3, or 4.14.8 depending on the release stream in use.
Audit all routes that bridge HTTP consumers into cxf: or cxfrs: producers and identify any exposed to untrusted networks.
Strip operationName and operationNamespace headers from untrusted ingress before the request reaches the CXF producer.
Set the CXF operation from a trusted source inside the route, not from inbound headers.

Patch Information

Apache Camel 4.21.0 fixes the issue and renames the operation-selection headers to CamelCxfOperationName and CamelCxfOperationNamespace, which are filtered at transport boundaries by the standard Camel prefix rule. Backports are available in 4.18.3 and 4.14.8. Review the 4.21 upgrade guide for the cross-transport carrier-header pattern before upgrading production routes. Refer to the Apache Camel CVE-2026-46592 Advisory for the full remediation notes.

Workarounds

Add a removeHeaders step in the route to drop operationName and operationNamespace immediately after the HTTP consumer, for example .removeHeaders("operationName|operationNamespace").
Explicitly set the intended operation with .setHeader(CxfConstants.OPERATION_NAME, constant("expectedOp")) before the cxf: producer.
Place authentication in front of any HTTP consumer that bridges to CXF, and validate inbound headers at a reverse proxy or API gateway.

bash

# Configuration example: strip untrusted CXF operation headers in a Camel route
from("platform-http:/orders")
    .removeHeaders("operationName|operationNamespace")
    .setHeader("operationName", constant("getOrder"))
    .to("cxf:bean:orderService");