CVE-2026-43866 in Camel
Zusammenfassung
von VulDB • 06.07.2026
Verwundbarkeit durch Deserialisierung von nicht vertrauenswürdigen Daten in Apache Camel, Komponente „Apache Camel JMS".
JmsBinding.extractBodyFromJms() in camel-jms – und die äquivalente Implementierung in JmsBinding für camel-sjms – deserialisiert den Payload einer eingehenden JMS ObjectMessage über jakarta.jms.ObjectMessage.getObject(), wenn die Option mapJmsMessage aktiviert ist (Standardwert) und Camel als JMS-Consumer agiert. Die mit CVE-2026-40860 eingeführte Absicherungsmaßnahme fügte eine Post-Deserialisierungs-Klassenprüfung hinzu, die Klassen außerhalb der Standard-Allowlist java.**;javax.**;org.apache.camel.**;!*. ablehnt. Da sich org.apache.camel.support.DefaultExchangeHolder selbst im allowlisted Namespace org.apache.camel.** befindet, besteht ein ObjectMessage, dessen Top-Level-Objekt eine DefaultExchangeHolder ist, diese Prüfung erfolgreich. Die empfangende Seite ruft daraufhin DefaultExchangeHolder.unmarshal() ohne die Aktivierung der Option transferExchange auf – dies stellt eine asymmetrische Vertrauensgrenze dar, da die sendende Seite die Verarbeitung von ObjectMessage und transferExchange einschränkt, die empfangende Seite jedoch nicht. Dabei werden alle Nicht-Null-Felder des Holders in den Exchange geschrieben: der Nachrichtenbody, die IN- und OUT-Headers, die Exchange-Eigenschaften, die Variablen, die Exchange-ID sowie Ausnahmen. Ein Angreifer, der eine ObjectMessage an eine Warteschlange oder ein Topic veröffentlichen kann, das von einer betroffenen Camel-Anwendung konsumiert wird, kann daher beliebigen Exchange-Zustand unter Verwendung ausschließlich allgemein vertrauenswürdiger Typen aus java.lang und java.util injizieren, ohne dass eine Deserialisierungs-Gadget-Kette erforderlich ist. Dies ermöglicht die Manipulation des Routing-Verhaltens, der Headers sowie von Exchange-Eigenschaften und dem Fehlerbehandlungsmechanismus. Die gleiche Problematik gilt für camel-sjms und camel-sjms2 sowie für JMS-Familienkomponenten, die auf JmsComponent und JmsBinding basieren: camel-amqp, camel-activemq und camel-activemq6. Dies stellt eine Umgehung der Korrektur zu CVE-2026-40860 dar und keinen Fehler in dieser Korrektur selbst.
Dieses Problem betrifft Apache Camel: ab Version 3.0.0 bis vor 4.14.8, ab 4.15.0 bis vor 4.18.3, ab 4.19.0 bis vor 4.21.0; Apache Camel: ab Version 3.0.0 bis vor 4.14.8, ab 4.15.0 bis vor 4.18.3, ab 4.19.0 bis vor 4.21.0.
Es wird empfohlen, auf die Version 4.21.0 zu aktualisieren, welche das Problem behebt. Wenn Benutzer die LTS-Release-Serie 4.14.x verwenden, wird ein Upgrade auf 4.14.8 vorgeschlagen. Befinden sich Benutzer in der Release-Serie 4.18.x, wird ein Upgrade auf 4.18.3 empfohlen. Nach dem Upgrade ist die Verarbeitung von JMS ObjectMessage standardmäßig deaktiviert (camel-jms, camel-sjms und die JMS-Familienkomponenten); eine neue Option objectMessageEnabled hat den Standardwert false sowohl auf Komponentenebene als auch auf Endpunktebene. Eine eingehende ObjectMessage – einschließlich eines DefaultExchangeHolder-Payloads – wird daher nicht mehr deserialisiert, es sei denn, diese Option wird explizit aktiviert; setzen Sie objectMessageEnabled=true nur dann, wenn das konsumierte JMS-Ziel ausschließlich von vertrauenswürdigen Produzenten gespeist wird. Für Bereitstellungen, die ein sofortiges Upgrade nicht durchführen können, sollte der Veröffentlichungszugriff auf Warteschlangen und Topics, die von Camel konsumiert werden, über JMS-Broker-Autorisierungen auf vertrauenswürdige Produzenten beschränkt werden; zudem sollten keine JMS-Consumer freigegeben werden, deren ObjectMessage-Payloads in nicht vertrauenswürdige Netzwerke gemappt werden. Eine Deserialisierungs-Allowlist des JMS-Anbieters mildert diese spezifische Umgehungsmethode nicht ab, da der manipulierte Payload ausschließlich allgemein vertrauenswürdige Klassen verwendet.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.