CVE-2026-88900

Zusammenfassung

Deserialisierung nicht vertrauenswürdiger Daten – Schwachstelle in der Apache-Camel-Komponente Camel-Jgroups. Dieses Problem betrifft Apache Camel: von 4.0.0 bis vor 4.18.5, von 4.19.0 bis vor 4.22.1. JGroupsEndpoint.createExchange(Message), das von CamelJGroupsReceiver für jede Nachricht aufgerufen wird, die der jgroups-Consumer empfängt, bevor der Exchange weitergeleitet wird, setzte den Exchange-Body aus org.jgroups.Message.getObject(). Bei einer ObjectMessage – dem Nachrichtentyp, den der Camel-jgroups-Producer sendet – deserialisiert JGroups die Nutzlast in Java über einen ObjectInputStream auf seinem eigenen Empfangs-Thread, sobald die Nachricht eintrifft, und getObject() gibt das resultierende Objekt zurück. Auf diesem Pfad wurde kein java.io.ObjectInputFilter angewendet, es sei denn, die Bereitstellung hatte einen JVM-weiten Serialisierungsfilter gesetzt: camel-jgroups installierte keinen, und die mit den betroffenen Releases ausgelieferten JGroups-Versionen wenden keinen eigenen an, sodass jede serialisierbare Klasse im Klassenpfad der Anwendung instanziiert und ihre Deserialisierungs-Callbacks ausgeführt werden konnten. Sofern kein Channel oder die Option channelProperties konfiguriert ist, erstellt der Consumer seinen Channel mit new JChannel(), dem Standard-JGroups-Protokoll-Stack, der über UDP ohne das AUTH-Protokoll und ohne Verschlüsselung multicastet, sodass jeder Host, der die Multicast-Gruppe oder den Bind-Port des Clusters erreichen kann, dem Cluster ohne Anmeldedaten beitreten und Nachrichten an den Consumer senden kann. Ein solcher Host könnte ein manipuliertes serialisiertes Objekt senden, das zu einer Remote-Code-Ausführung im Camel-Prozess führt, wenn eine nutzbare Deserialisierungs-Gadget-Chain im Klassenpfad vorhanden ist, und es war keine nicht standardmäßige Option auf dem Consumer erforderlich. Da JGroups das Objekt materialisiert, bevor der Receiver von Camel läuft, kann eine von Camel durchgeführte Prüfung nur das deserialisierte Ergebnis inspizieren und keinen Code stoppen, der während der Deserialisierung ausgeführt wird; daher erfordert das Schließen des Problems auch eine Kontrolle, die greift, bevor die Nutzlast gelesen wird, wie in der Mitigation beschrieben. Die Ausnutzung erfordert Netzwerkzugriff auf die Multicast-Gruppe oder den Bind-Port des Clusters, was beim standardmäßigen UDP-Multicast-Transport einen Host in einem angrenzenden Netzwerk bedeutet, sowie eine nutzbare Gadget-Chain im Klassenpfad – weshalb der Schweregrad als hoch statt kritisch eingestuft wird. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer den Release-Stream 4.22.x verwenden, wird ihnen empfohlen, auf 4.22.1 zu aktualisieren. Wenn Benutzer den Release-Stream 4.18.x verwenden, wird ihnen empfohlen, auf 4.18.5 zu aktualisieren. Der Release-Stream 4.14.x und früher sowie die Release-Linien 4.15.x bis 4.17.x und 4.19.x bis 4.21.x haben ihr End-of-Life erreicht, bevor dieses Problem behoben wurde, und erhalten keinen Fix; Bereitstellungen auf diesen Linien müssen auf ein unterstütztes Release wechseln.