CVE-2026-88900

Riepilogo

Vulnerabilità di deserializzazione di dati non attendibili nel componente Camel-Jgroups di Apache Camel. Il problema interessa Apache Camel: dalla 4.0.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1. JGroupsEndpoint.createExchange(Message), che CamelJGroupsReceiver invoca per ogni messaggio ricevuto dal consumer jgroups prima che lo scambio venga instradato, impostava il corpo dello scambio a partire da org.jgroups.Message.getObject(). Per un ObjectMessage, ovvero il tipo di messaggio inviato dal producer Camel jgroups, JGroups deserializza in Java il payload tramite un ObjectInputStream sul proprio thread di ricezione non appena il messaggio arriva, e getObject() restituisce l'oggetto risultante. Su quel percorso non veniva applicato alcun java.io.ObjectInputFilter, a meno che il deployment non avesse impostato un filtro di serializzazione a livello di JVM: camel-jgroups non ne installava alcuno, e le versioni di JGroups distribuite con le release interessate non ne applicano di propri, quindi qualsiasi classe serializzabile presente nel classpath dell'applicazione poteva essere istanziata e i suoi callback di deserializzazione eseguiti. A meno che non sia configurato un channel o l'opzione channelProperties, il consumer crea il proprio channel con new JChannel(), lo stack di protocolli JGroups predefinito, che effettua multicast su UDP senza il protocollo AUTH e senza cifratura, quindi qualsiasi host in grado di raggiungere il gruppo multicast o la porta di bind del cluster può unirsi al cluster e inviare messaggi al consumer senza credenziali. Un tale host potrebbe inviare un oggetto serializzato appositamente costruito che porta all'esecuzione di codice remoto nel processo Camel quando nel classpath è presente una catena di gadget di deserializzazione utilizzabile, e sul consumer non era richiesta alcuna opzione non predefinita. Poiché JGroups materializza l'oggetto prima che il receiver di Camel venga eseguito, un controllo effettuato da Camel può solo ispezionare il risultato deserializzato e non può fermare il codice che viene eseguito durante la deserializzazione, quindi per chiudere il problema è necessario anche un controllo che agisca prima che il payload venga letto, come descritto nella mitigazione. Lo sfruttamento richiede accesso di rete al gruppo multicast o alla porta di bind del cluster, il che con il trasporto multicast UDP predefinito significa un host su una rete adiacente, e una catena di gadget utilizzabile nel classpath, motivo per cui la gravità è valutata come alta anziché critica. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che risolve il problema. Se gli utenti si trovano sul ramo di release 4.22.x, si suggerisce di aggiornare alla 4.22.1. Se gli utenti si trovano sul ramo di release 4.18.x, si suggerisce di aggiornare alla 4.18.5. Il ramo di release 4.14.x e precedenti, e le linee di release dalla 4.15.x alla 4.17.x e dalla 4.19.x alla 4.21.x, hanno raggiunto l'end of life prima che questo problema fosse risolto e non riceveranno una correzione, quindi i deployment su tali linee devono passare a una release supportata.