CVE-2026-43866

Riepilogo

# Vulnerabilità di deserializzazione di dati non attendibili in Apache Camel, componente Apache Camel JMS JmsBinding.extractBodyFromJms() in camel-jms - e l'equivalente JmsBinding in camel-sjms - deserializza il payload di un JMS ObjectMessage in arrivo tramite jakarta.jms.ObjectMessage.getObject() ogni volta che l'opzione mapJmsMessage è abilitata (impostazione predefinita) e Camel agisce come consumer JMS. L'indurimento CVE-2026-40860 ha aggiunto un controllo delle classi post-deserializzazione che rifiuta le classi al di fuori della allow-list predefinita java.**;javax.**;org.apache.camel.**;!*. Tuttavia, org.apache.camel.support.DefaultExchangeHolder stesso risiede nel namespace org.apache.camel.** incluso nella allow-list, quindi un ObjectMessage il cui oggetto di primo livello è un DefaultExchangeHolder supera il controllo. Il lato ricevente chiama quindi DefaultExchangeHolder.unmarshal() su di esso senza richiedere che l'opzione transferExchange sia abilitata - un confine di fiducia asimmetrico, poiché il lato mittente vincola la gestione di ObjectMessage e transferExchange ma il lato ricevente non lo faceva - scrivendo ogni campo non nullo dell'holder nell'Exchange: il corpo del messaggio, le intestazioni IN e OUT, le proprietà dell'exchange, le variabili, l'ID dell'exchange e l'eccezione. Un attaccante che può pubblicare un ObjectMessage su una coda o un topic consumato da un'applicazione Camel vulnerabile può quindi iniettare stato arbitrario dell'Exchange utilizzando solo tipi java.lang e java.util universalmente attendibili, senza richiedere una catena di gadget di deserializzazione, per manipolare routing e intestazioni, proprietà dell'exchange e gestione degli errori. La stessa gestione si applica a camel-sjms e camel-sjms2, e ai componenti della famiglia JMS basati su JmsComponent e JmsBinding: camel-amqp, camel-activemq e camel-activemq6. Questo è un bypass della correzione CVE-2026-40860 piuttosto che un difetto in essa. Il problema riguarda Apache Camel: dalla 3.0.0 prima della 4.14.8, dalla 4.15.0 prima della 4.18.3, dalla 4.19.0 prima della 4.21.0; Apache Camel: dalla 3.0.0 prima della 4.14.8, dalla 4.15.0 prima della 4.18.3, dalla 4.19.0 prima della 4.21.0. Si consiglia agli utenti di aggiornare alla versione 4.21.0, che risolve il problema. Se gli utenti sono sul flusso di release LTS 4.14.x, si consiglia di aggiornare alla 4.14.8. Se gli utenti sono sul flusso di release 4.18.x, si consiglia di aggiornare alla 4.18.3. Dopo l'aggiornamento, la gestione di JMS ObjectMessage è disabilitata per impostazione predefinita in camel-jms, camel-sjms e nei componenti della famiglia JMS (una nuova opzione objectMessageEnabled è impostata su false per impostazione predefinita a livello di componente ed endpoint), quindi un ObjectMessage in arrivo - incluso un payload DefaultExchangeHolder - non viene più deserializzato a meno che l'opzione non sia esplicitamente abilitata; impostare objectMessageEnabled=true solo quando la destinazione JMS consumata è alimentata esclusivamente da produttori attendibili. Per le distribuzioni che non possono aggiornare immediatamente, limitare l'accesso di pubblicazione alle code e ai topic consumati da Camel ai soli produttori attendibili tramite l'autorizzazione del broker JMS, e non esporre consumer JMS che mappano corpi ObjectMessage a reti non attendibili; una allow-list di deserializzazione del provider JMS non mitiga questo specifico bypass perché il payload creato utilizza solo classi universalmente attendibili.