CVE-2026-78165
Camel-Spring-Redis: The default JdkSerializationRedisSerializer deserializes Redis payloads with no ObjectInputFilter, allowing an actor who can publish to the subscribed channel to achieve remote code execution
Description
RedisConfiguration.getSerializer lazily built a bare JdkSerializationRedisSerializer whenever no serializer option was configured, and that instance was used for every read the component performs. Spring's implementation delegates through DeserializingConverter to DefaultDeserializer, which reads the bytes with a ConfigurableObjectInputStream and installs no java.io.ObjectInputFilter on the stream, so an arbitrary serialized class graph was materialised and its readObject method executed. RedisConsumer.setBody applied that serializer to the raw bytes of every message published to the subscribed channels, before the Exchange was constructed and therefore before any route logic could inspect the message, so an actor able to issue PUBLISH on a subscribed channel reached the deserialization sink directly. The same default serializer backed the RedisTemplate built by RedisConfiguration.createDefaultTemplate, so the producer read commands GET, HGET, HGETALL and HVALS deserialized whatever was stored in the Redis keyspace, and SpringRedisIdempotentRepository shared that template. Configuring a custom redisTemplate did not close the consumer path, because RedisConsumer.setBody reads getSerializer directly rather than the serializer attached to the template, so a deployment that had wired a String serializer into its own template remained exposed on the consumer side unless it also set the serializer option. The component never constructed a java.io.ObjectInputStream itself, which is why earlier passes over the Camel codebase for unfiltered Java deserialization did not reach it. The behaviour dates back to the introduction of the component, first released in 2.11.0, and was unchanged until this fix.
Mitigation
Credit
This issue was discovered by Leon Zlobecki
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24421 refers to the commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25587 (commit 8db602a5ee105403fa40c1b821157c8d9d0c1977), and backported to camel-4.22.x in https://github.com/apache/camel/pull/25588 (commit b2ba1ed90562e10e07bfb4a3cab60b817885e6de) and to camel-4.18.x in https://github.com/apache/camel/pull/25589 (commit e721141ddcaeb9a08892730942b1b362c2da1c5c). A follow-up documentation change, https://github.com/apache/camel/pull/25734 (commit ddc7885a7add93326b3d549c565c43bbccad12dc), placed the upgrade-guide entries for every affected release line on main.
A new deserializationFilter endpoint option, labelled advanced and security, now controls the filter applied while the default serializer reads Redis payloads. When it is not set, the JVM-wide jdk.serialFilter is honoured if present, and otherwise a conservative default allow-list is applied that permits standard Java and Apache Camel types and denies java.net. On the 4.23.0 and 4.22.1 releases the default is resolved through the shared DeserializationFilterHelper and additionally enforces the JEP-290 graph-shape limits maxdepth, maxrefs and maxbytes; on 4.18.5 the equivalent local constant is applied without those limits, matching the form already used by the other components on that maintenance line. Because JdkSerializationRedisSerializer exposes no hook for installing a filter, the serializer is now constructed through its Converter-based constructor with a deserializing converter that sets the filter on the stream before the graph is read. Serialization is unchanged, and class resolution is unchanged because the same null class loader that Spring’s DefaultDeserializer uses by default is passed through. The single change covers all three paths that shared the default serializer: the consumer, the producer read commands, and SpringRedisIdempotentRepository. Setting the serializer option to a custom RedisSerializer still bypasses the filter, since Camel then no longer controls how the payload is read.
This is a change of default behaviour for routes that exchange classes outside the allow-list, which must widen it through the new option; the change is documented in the upgrade guides for each affected release line. The issue is classified as CWE-502 (Deserialization of Untrusted Data) and belongs to the same family as the unfiltered Java deserialization advisories published previously for other Camel components.