CVE-2026-78165

Riepilogo

Vulnerabilità di deserializzazione di dati non attendibili nel componente Apache Camel Spring Redis. Questo problema interessa Apache Camel: dalla 2.11.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1. RedisConfiguration.getSerializer creava in modo lazy un JdkSerializationRedisSerializer nudo ogni volta che non era configurata alcuna opzione serializer, e tale istanza veniva utilizzata per ogni lettura eseguita dal componente. L'implementazione di Spring delega tramite DeserializingConverter a DefaultDeserializer, che legge i byte con un ConfigurableObjectInputStream e non installa alcun java.io.ObjectInputFilter sullo stream, cosicché un grafo di classi serializzate arbitrario veniva materializzato e il suo metodo readObject eseguito. RedisConsumer.setBody applicava quel serializer ai byte grezzi di ogni messaggio pubblicato sui canali sottoscritti, prima che l'Exchange fosse costruito e quindi prima che qualsiasi logica di route potesse ispezionare il messaggio, cosicché un attore in grado di emettere PUBLISH su un canale sottoscritto raggiungeva direttamente il sink di deserializzazione. Lo stesso serializer predefinito alimentava il RedisTemplate costruito da RedisConfiguration.createDefaultTemplate, quindi i comandi di lettura del producer GET, HGET, HGETALL e HVALS deserializzavano qualunque cosa fosse memorizzata nel keyspace Redis, e SpringRedisIdempotentRepository condivideva quel template. La configurazione di un redisTemplate personalizzato non chiudeva il percorso del consumer, perché RedisConsumer.setBody legge getSerializer direttamente anziché il serializer associato al template, quindi un deployment che aveva collegato un serializer String al proprio template restava esposto sul lato consumer a meno che non impostasse anche l'opzione serializer. Il componente non costruiva mai direttamente un java.io.ObjectInputStream, motivo per cui precedenti analisi del codebase Camel alla ricerca di deserializzazione Java non filtrata non lo raggiungevano. Il comportamento risale all'introduzione del componente, rilasciato per la prima volta nella 2.11.0, ed è rimasto invariato fino a questa correzione. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che corregge 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 ha raggiunto l'end of life prima che questo problema fosse risolto e non riceverà una correzione, quindi i deployment su tali linee devono passare a una release supportata. Per i deployment che non possono aggiornare immediatamente, impostare la proprietà di sistema jdk.serialFilter a livello di JVM, che il percorso di codice interessato rispetta perché legge tramite un java.io.ObjectInputStream, ad esempio -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; oppure impostare l'opzione endpoint serializer su un serializer che non utilizzi la serializzazione Java, come StringRedisSerializer, tenendo presente che questa deve essere impostata come opzione serializer e non solo su un redisTemplate personalizzato. Come difesa in profondità, richiedere l'autenticazione sull'istanza Redis e limitare quali client possono pubblicare sui canali sottoscritti, e non esporre a reti non attendibili un'istanza Redis consumata da Camel.