CVE-2026-78162
Apache Camel: filtro di deserializzazione Java mancante nelle istanze gestite di Camel-Hazelcast (correzione incompleta per CVE-2026-43865)
- Pubblicato
- 19 ott 2026
- Aggiornato
- 20 ott 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 17 ott 2026
CVSS primario
cvelist · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HRiepilogo
Vulnerabilità di deserializzazione di dati non attendibili in Apache Camel. Il problema riguarda Apache Camel: dalla 4.0.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1. Il componente camel-hazelcast applica un Hazelcast JavaSerializationFilterConfig predefinito alle istanze che crea dalla propria configurazione, una protezione introdotta da CVE-2026-43865. Tale modifica non ha raggiunto due dei percorsi di configurazione che Camel costruisce autonomamente, pertanto tali percorsi hanno continuato a creare istanze Hazelcast la cui deserializzazione Java non è limitata. ReplicatedHazelcastAggregationRepository estende HazelcastAggregationRepository ma sovrascrive doStart() senza chiamare super.doStart(), mantenendo una propria copia del blocco di bootstrap, e quindi non ha mai ricevuto il filtro: una route che lo utilizza senza fornire una hazelcastInstance avvia un membro Hazelcast che deserializza i valori letti dalla ReplicatedMap sottostante senza alcuna restrizione di classe. HazelcastDefaultComponent#getOrCreateHzClientInstance() costruisce un proprio ClientConfig quando è selezionata l'opzione hazelcastMode=client e non viene fornito né un ClientConfig referenziato né hazelcastConfigUri, e analogamente non applicava alcun filtro, quindi gli endpoint in modalità client si comportavano diversamente dagli endpoint in modalità node per una configurazione altrimenti identica. In entrambi i casi un attaccante in grado di pubblicare nel cluster Hazelcast a cui è collegata l'istanza interessata può causare la deserializzazione di un oggetto Java serializzato di sua scelta all'interno del livello di serializzazione di Hazelcast stesso, prima che Camel elabori lo scambio, con conseguente esecuzione di codice remoto. I cluster Hazelcast non hanno né autenticazione né TLS abilitati per impostazione predefinita. La selezione della modalità client è una scelta di topologia e non un'opzione di sicurezza, quindi nessuno dei due percorsi richiedeva che il deployment optasse per un comportamento non sicuro. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che risolve il problema. Se gli utenti utilizzano il ramo di rilascio 4.22.x, si suggerisce di aggiornare alla 4.22.1. Se gli utenti utilizzano il ramo di rilascio 4.18.x, si suggerisce di aggiornare alla 4.18.5. Il ramo di rilascio 4.14.x e precedenti hanno raggiunto la fine del ciclo di vita prima che questo problema fosse risolto e non riceveranno una correzione, pertanto i deployment su tali linee devono passare a una release supportata. Per i deployment che non possono aggiornare immediatamente, fornire una configurazione Hazelcast esplicita che includa un JavaSerializationFilterConfig, oppure iniettare una HazelcastInstance predefinita, poiché una configurazione fornita dall'utente non viene mai sovrascritta da Camel. In alternativa, impostare il filtro a livello di JVM -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* e abilitare l'autenticazione del cluster Hazelcast e TLS per limitare chi può raggiungere il cluster.
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.