Apache Camel JMS deserialization filter bypass

Beschreibung

Deserialisierung der Sicherheitslücke für nicht vertrauenswürdige Daten in Apache Camel, Apache Camel JMS-Komponente. JmsBinding.extractBodyFromJms() in camel-jms - und das Äquivalent JmsBinding in camel-sjms - deserialisiert die Nutzlast einer eingehenden JMS ObjectMessage über jakarta.jms. ObjectMessage.getObject() immer dann, wenn die mapJmsMessage-Option aktiviert ist (Standard) und Camel als JMS-Konsument fungiert. Die CVE-2026-40860-Härtung fügte eine Klassenüberprüfung nach der Deserialisierung hinzu, die Klassen außerhalb der Standard-Erlaubnisliste ablehnt java.**; javax.**; org.apache.camel.**;!*. Allerdings org.apache.camel.support.DefaultExchangeHolder selbst lebt in der allow-listed org.apache.camel.** Namespace, so dass ein ObjectMessage, dessen Top-Level-Objekt ein DefaultExchangeHolder ist, den Scheck besteht. Die empfangende Seite ruft dann DefaultExchangeHolder.unmarshal() auf, ohne dass die transferExchange-Option aktiviert werden muss - eine asymmetrische Vertrauensgrenze, da die sendende Seite ObjectMessage und transferExchange-Handling, aber die empfangende Seite nicht - jedes Nicht-Null-Feld des Inhabers in die Exchange schreibt: der Nachrichtenkörper, die IN- und OUT-Header, die Exchange-Eigenschaften, die Variablen, die Exchange-ID und die Ausnahme. Ein angreifer, der eine objectmessage in einer warteschlange oder einem thema veröffentlichen kann, das von einer betroffenen camel-anwendung konsumiert wird, kann daher einen beliebigen exchange-zustand mit nur universell vertrauenswürdigem java einfügen. lang und java.util-Typen, ohne Deserialisierungs-Gadget-Kette erforderlich, um Routing und Header zu manipulieren, Eigenschaften und Fehlerbehandlung auszutauschen. Die gleiche Handhabung gilt für Kamel-sjms und Kamel-sjms2 und für die Komponenten der JMS-Familie, die auf JmsComponent und JmsBinding aufbauen: Kamel-amqp, Kamel-activemq und Kamel-activemq6. Dies ist ein Bypass des CVE-2026-40860-Fixes und kein 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, wodurch das Problem behoben wird. Wenn Benutzer auf dem 4.14.x LTS-Releases-Stream sind, wird empfohlen, auf 4.14.8 zu aktualisieren. Wenn Benutzer auf dem 4.18.x-Releases-Stream sind, wird empfohlen, auf 4.18.3 zu aktualisieren. Nach dem Upgrade wird die JMS ObjectMessage-Handhabung standardmäßig in camel-jms, camel-sjms und den JMS-Familienkomponenten deaktiviert (eine neue objectMessageEnabled-Option ist standardmäßig auf false auf Komponenten- und Endpunktebene), so dass eine eingehende ObjectMessage - einschließlich einer DefaultExchangeHolder-Nutzlast - nicht mehr deserialisiert wird, es sei denn, die Option ist explizit aktiviert; setze objectMessageEnabled=true nur, wenn das verbrauchte JMS-Ziel ausschließlich von vertrauenswürdigen Produzenten gespeist wird. Für Bereitstellungen, die nicht sofort aktualisiert werden können, beschränken Sie den Zugriff auf die Warteschlangen und Themen, die von Camel verwendet werden, auf vertrauenswürdige Produzenten über die JMS-Broker-Autorisierung und setzen JMS-Konsumenten, die ObjectMessage-Körper nicht vertrauenswürdigen Netzwerken zuordnen, nicht aus; eine Deserialisierungserlaubnis für JMS-Anbieter

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 4.14.8, 4.18.3, 4.21.0.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Apache Software Foundation org.apache.camel:camel-jms, org.apache.camel:camel-sjms, org.apache.camel:camel-sjms2, org.apache.camel:camel-amqp, org.apache.camel:camel-activemq, org.apache.camel:camel-activemq6.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.