camel-jms Gefälschter DefaultExchangeHolder Filter-Bypass-Reproducer (CVE-2026-43866)

Dieses Projekt demonstriert CVE-2026-43866, einen Bypass des CVE-2026-40860-Fixes in den camel-jms-Komponenten von Apache Camel (sowie camel-sjms / JMS-Familie). CVE-2026-40860 fügte eine Whitelist für Klassen nach der Deserialisierung (java.**;javax.**;org.apache.camel.**;!*) für eingehende JMS ObjectMessage-Payloads hinzu. Da org.apache.camel.support.DefaultExchangeHolder jedoch im erlaubten Namespace org.apache.camel.** lebt, passiert ein ObjectMessage, dessen Top-Level-Objekt ein DefaultExchangeHolder ist, die Prüfung. Die empfangende Seite ruft dann DefaultExchangeHolder.unmarshal() darauf auf ohne dass transferExchange erforderlich ist – und schreibt jedes nicht-null-Feld des Holders in den gerouteten Exchange (Body, IN/OUT-Header, Exchange-Eigenschaften, Variablen, Exchange-ID, Exception). Ein Angreifer, der ein ObjectMessage veröffentlichen kann, kann somit beliebigen Exchange-Zustand nur mit universell vertrauenswürdigen java.*-Typen injizieren – keine Deserialisierungs-Gadget-Kette erforderlich – um Routing, Header, Eigenschaften und Fehlerbehandlung zu manipulieren.

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

Zusammenfassung der Schwachstelle

Technische Details

// JmsBinding.extractBodyFromJms(...) - affected 4.18.2
if (message instanceof ObjectMessage objectMessage) {
    Object payload = objectMessage.getObject();
    checkDeserializedClass(payload);                        // CVE-2026-40860 allow-list: java.**;javax.**;org.apache.camel.**;!*
    if (payload instanceof DefaultExchangeHolder holder) {  // <-- DefaultExchangeHolder is org.apache.camel.** -> passes
        DefaultExchangeHolder.unmarshal(exchange, holder);  // <-- writes forged state into the Exchange; NO transferExchange gate
        Map<String, Object> jmsHeaders = extractHeadersFromJms(message, exchange);
        exchange.getIn().getHeaders().putAll(jmsHeaders);
        return exchange.getIn().getBody();
    } else {
        return payload;
    }
}

Die Asymmetrie: Die sendende Seite steuert die Erstellung von ObjectMessage/transferExchange, aber die empfangende Seite entpackt jeden DefaultExchangeHolder, den sie deserialisiert. Der Fix (4.14.8 / 4.18.3 / 4.21.0) fügt eine neue Option objectMessageEnabled hinzu (security = "insecure:serialization", Standardwert false) – eine eingehende ObjectMessage wird überhaupt nicht mehr deserialisiert, es sei denn, sie ist explizit aktiviert, sodass ein gefälschter Holder nie unmarshal() erreicht. (Dies ist eine bahnbrechende Änderung für Routen, die auf ObjectMessage / transferExchange angewiesen sind.)

Eine JMS-Provider-Whitelist hilft nicht. Dieser PoC konfiguriert den ActiveMQ-Client mit einer realistischen, restriktiven trustedPackages = [java, javax, org.apache.camel] – der Eintrag org.apache.camel ist genau das, was eine Bereitstellung, die legitimes transferExchange verwendet, vertrauen muss. Der gefälschte Holder passiert trotzdem, weil er selbst ein DefaultExchangeHolder ist, dessen Felder alle vertrauenswürdige java.*-Typen sind – nicht von einem legitimen zu unterscheiden.

Die Opfer-Route

from("jms:queue:cve")                 // mapJmsMessage defaults to true; transferExchange NOT set
    .process(exchange -> { /* observes the injected body / headers / properties */ });

Repository-Aufbau – Angreifer vs. Opfer

Das Opfer ist der Camel JMS-Consumer. Der Angreifer ist jeder Producer, der in die Queue veröffentlichen kann. Beide kommunizieren mit einem echten Apache ActiveMQ Artemis-Broker in Docker.

CVE-2026-43866/
├── pom.xml                 # camel-jms 4.18.2 + activemq-client 6.2.4  (KEINE Gadget-Bibliothek)
├── Dockerfile              # führt die App aus (kein --add-opens; kein Gadget)
├── docker-compose.yml      # Artemis-Broker (quay.io) + die Reproducer-App
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── JmsConfig.java            # OpenWire ConnectionFactory (trustedPackages inkl. org.apache.camel) + jms-Komponente
    │   ├── VictimRoute.java          # Opfer: from("jms:queue:cve"); zeichnet auf, was die Route beobachtet hat
    │   ├── CapturedState.java
    │   ├── ForgedHolderFactory.java  # erstellt einen DefaultExchangeHolder über die öffentliche marshal()-API
    │   └── ExploitController.java    # Angreifer: veröffentlicht den gefälschten Holder als ObjectMessage
    └── resources/
        └── application.properties

Voraussetzungen

• Java 17+ und Maven 3.8+
• Docker (führt den Broker und die App aus)

Reproduktionsschritte

Schritt 1: Bauen und alles starten

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

Schritt 2: Den Bypass auslösen

curl -s http://localhost:8080/exploit/attack
# -> Published a forged DefaultExchangeHolder as a JMS ObjectMessage to queue 'cve'.
#    ...
#      body      = INJECTED-BODY-...      (injected: true)
#      header    = pwned-header-...       (injected: true)
#      property  = pwned-property-...     (injected: true)
#
#    >>> Exchange-state injection proof — attacker controlled body+header+property: true

Die Route wurde mit einem Body, Header und einer Property ausgeführt, die sie nie gesetzt hatte – alle vom gefälschten Holder des Angreifers geliefert.

Bereinigung

docker compose down

Angriffsvektoren

Jeder Camel JMS-Consumer (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) mit mapJmsMessage=true (Standard), der von einem Ziel liest, auf das ein Angreifer veröffentlichen kann. transferExchange muss nicht auf dem Consumer aktiviert sein.

Ausbeutungsbedingungen

1. Ein Camel JMS-Consumer mit mapJmsMessage=true (Standard) in einer betroffenen Version.
2. Der Angreifer kann ein ObjectMessage in die Warteschlange einreihen, dessen Payload ein DefaultExchangeHolder ist.
3. Der JMS-Provider deserialisiert die Payload – was bei jeder Bereitstellung, die transferExchange verwendet, bedeutet, dass der Provider org.apache.camel bereits vertraut. Es wird keine Gadget-Bibliothek benötigt.

Empfohlener Fix

Aktualisieren Sie auf 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23373 / CAMEL-23409). Die Behandlung von JMS ObjectMessage ist standardmäßig über die neue Option objectMessageEnabled deaktiviert; aktivieren Sie sie nur für Ziele, die ausschließlich von vertrauenswürdigen Produzenten gespeist werden.

Abhilfe

Bis zur Aktualisierung:

1. Beschränken Sie die Veröffentlichungsberechtigung für Camel-konsumierte Queues/Topics auf vertrauenswürdige Produzenten mittels JMS-Broker-Autorisierung.
2. Setzen Sie keine JMS-Consumer, die ObjectMessage-Bodies mappen, ungeschützten Netzwerken aus.
3. Hinweis: Eine JMS-Provider-Deserialisierungs-Whitelist mildert diesen speziellen Bypass nicht (die Payload verwendet nur universell vertrauenswürdige Klassen plus DefaultExchangeHolder).

Haftungsausschluss

Dieser Reproducer wird nur 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.