CVE-2026-43866

Zusammenfassung

# Deserialisierung nicht vertrauenswürdiger Daten – Schwachstelle in Apache Camel, Apache Camel JMS-Komponente JmsBinding.extractBodyFromJms() in camel-jms – sowie das äquivalente JmsBinding in camel-sjms – deserialisiert die Nutzlast einer eingehenden JMS ObjectMessage über jakarta.jms.ObjectMessage.getObject(), sofern die Option mapJmsMessage aktiviert ist (Standard) und Camel als JMS-Consumer fungiert. Die Härtung durch CVE-2026-40860 fügte eine Klassenprüfung nach der Deserialisierung hinzu, die Klassen außerhalb der Standard-Allowlist java.**;javax.**;org.apache.camel.**;!* ablehnt. Allerdings befindet sich org.apache.camel.support.DefaultExchangeHolder selbst im erlaubten Namensraum org.apache.camel.**, sodass eine ObjectMessage, deren Objekt der obersten Ebene ein DefaultExchangeHolder ist, die Prüfung besteht. Die empfangende Seite ruft anschließend DefaultExchangeHolder.unmarshal() darauf auf, ohne dass die Option transferExchange aktiviert sein muss – eine asymmetrische Vertrauensgrenze, da die sendende Seite die Verarbeitung von ObjectMessage und transferExchange absichert, die empfangende Seite dies jedoch nicht tat – und schreibt jedes nicht-null Feld des Holders in den Exchange: den Nachrichtentext, die IN- und OUT-Header, die Exchange-Eigenschaften, die Variablen, die Exchange-ID und die Exception. Ein Angreifer, der eine ObjectMessage in eine Warteschlange oder ein Topic veröffentlichen kann, das von einer betroffenen Camel-Anwendung konsumiert wird, kann daher beliebigen Exchange-Zustand injizieren, indem er ausschließlich universell vertrauenswürdige Typen aus java.lang und java.util verwendet – ohne dass eine Deserialisierungs-Gadget-Kette erforderlich ist –, um Routing und Header, Exchange-Eigenschaften und Fehlerbehandlung zu manipulieren. Dieselbe Behandlung gilt für camel-sjms und camel-sjms2 sowie für die JMS-Familienkomponenten, die auf JmsComponent und JmsBinding aufbauen: camel-amqp, camel-activemq und camel-activemq6. Hierbei handelt es sich um eine Umgehung des CVE-2026-40860-Fixes und nicht um einen Fehler darin. Dieses Problem betrifft Apache Camel: von 3.0.0 vor 4.14.8, von 4.15.0 vor 4.18.3, von 4.19.0 vor 4.21.0; Apache Camel: von 3.0.0 vor 4.14.8, von 4.15.0 vor 4.18.3, von 4.19.0 vor 4.21.0. Benutzern wird empfohlen, auf Version 4.21.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer den 4.14.x-LTS-Release-Stream verwenden, wird empfohlen, auf 4.14.8 zu aktualisieren. Wenn Benutzer den 4.18.x-Release-Stream verwenden, wird empfohlen, auf 4.18.3 zu aktualisieren. Nach dem Upgrade ist die Verarbeitung von JMS ObjectMessage in camel-jms, camel-sjms und den JMS-Familienkomponenten standardmäßig deaktiviert (eine neue Option objectMessageEnabled ist standardmäßig auf false auf Komponenten- und Endpunkt-Ebene gesetzt), sodass eine eingehende ObjectMessage – einschließlich einer DefaultExchangeHolder-Nutzlast – nicht mehr deserialisiert wird, es sei denn, die Option wird explizit aktiviert; setzen Sie objectMessageEnabled nur dann auf true, wenn das konsumierte JMS-Ziel ausschließlich von vertrauenswürdigen Produzenten gespeist wird. Für Bereitstellungen, die nicht sofort aktualisieren können, beschränken Sie den Veröffentlichungszugriff auf die von Camel konsumierten Warteschlangen und Topics auf vertrauenswürdige Produzenten über die JMS-Broker-Autorisierung und setzen Sie keine JMS-Consumer ungeschützten Netzwerken aus, die ObjectMessage-Nachrichtentexte abbilden; eine Deserialisierungs-Allowlist des JMS-Providers mindert diese spezifische Umgehung nicht, da die konstruierte Nutzlast ausschließlich universell vertrauenswürdige Klassen verwendet.