CVE-2026-43866
Riassunto
di VulDB • 06/07/2026
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 incoming JMS ObjectMessage tramite jakarta.jms.ObjectMessage.getObject() ogni volta che l'opzione mapJmsMessage è abilitata (impostazione predefinita) e Camel agisce come consumer JMS. L'hardening introdotto con CVE-2026-40860 ha aggiunto un controllo post-deserializzazione delle classi che rifiuta le classi al di fuori della allow-list predefinita java.**;javax.**;org.apache.camel.**;!*. Tuttavia, org.apache.camel.support.DefaultExchangeHolder risiede esso stesso nello spazio dei nomi allowlisted org.apache.camel.**, quindi un ObjectMessage il cui oggetto di primo livello è un DefaultExchangeHolder supera il controllo. Il lato ricevente chiama poi DefaultExchangeHolder.unmarshal() su tale oggetto senza richiedere che l'opzione transferExchange sia abilitata - una frontiera di fiducia asimmetrica, poiché il lato mittente limita la gestione degli ObjectMessage e della transferExchange, mentre il lato ricevente non lo fa -, scrivendo ogni campo non nullo del holder nell'Exchange: il corpo del messaggio, le intestazioni IN e OUT, le proprietà dell'exchange, le variabili, l'id dello scambio e l'eccezione. Un attaccante in grado di pubblicare un ObjectMessage su una coda o un topic consumato da un'applicazione Camel interessata può quindi iniettare stato Exchange arbitrario utilizzando solo tipi java.lang e java.util universalmente fidati, senza richiedere alcuna catena di gadget di deserializzazione, per manipolare il routing, le intestazioni, le proprietà dello scambio e la gestione degli errori. Lo stesso trattamento si applica a camel-sjms e camel-sjms2, nonché ai componenti della famiglia JMS costruiti su JmsComponent e JmsBinding: camel-amqp, camel-activemq e camel-activemq6. Si tratta di un bypass della correzione CVE-2026-40860 piuttosto che di una sua difettosità.
Questo problema interessa Apache Camel: dalla versione 3.0.0 alla 4.14.7, dalla 4.15.0 alla 4.18.2, dalla 4.19.0 alla 4.20.x; Apache Camel: dalla versione 3.0.0 alla 4.14.7, dalla 4.15.0 alla 4.18.2, dalla 4.19.0 alla 4.20.x.
Si consiglia agli utenti di effettuare l'aggiornamento alla versione 4.21.0, che risolve il problema. Se gli utenti utilizzano la serie LTS delle versioni 4.14.x, si suggerisce di aggiornare a 4.14.8. Se gli utenti utilizzano la serie delle versioni 4.18.x, si suggerisce di aggiornare a 4.18.3. Dopo l'aggiornamento, la gestione degli ObjectMessage JMS è disabilitata per impostazione predefinita in camel-jms, camel-sjms e nei componenti della famiglia JMS (una nuova opzione objectMessageEnabled ha come valore predefinito false a livello di componente ed endpoint), quindi un incoming ObjectMessage - incluso un payload DefaultExchangeHolder - non viene più deserializzato a meno che l'opzione non sia esplicitamente abilitata; impostare solo objectMessageEnabled=true quando la destinazione JMS consumata è alimentata esclusivamente da produttori fidati. Per le distribuzioni che non possono effettuare immediatamente l'aggiornamento, limitare l'accesso in pubblicazione alle code e ai topic consumati da Camel a produttori fidati tramite autorizzazione del broker JMS, ed evitare di esporre consumer JMS che mappano i corpi degli ObjectMessage su reti non attendibili; una allow-list di deserializzazione fornita dal provider JMS non mitiga questo specifico bypass poiché il payload manipolato utilizza solo classi universalmente fidate.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.