Severity:
CVSS 3.1: 8.8 (high) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Affected versions:
- Apache Camel (org.apache.camel:camel-spring-redis) 2.11.0 before 4.18.5
- Apache Camel (org.apache.camel:camel-spring-redis) 4.19.0 before 4.22.1
- Apache Camel (org.apache.camel:camel-spring-redis) 4.18.5 unaffected
- Apache Camel (org.apache.camel:camel-spring-redis) 4.22.1 unaffected
- Apache Camel (org.apache.camel:camel-spring-redis) 4.23.0 unaffected
Description:
Deserialization of Untrusted Data vulnerability in Apache Camel Spring Redis
component.
This issue affects Apache Camel: from 2.11.0 before 4.18.5, from 4.19.0 before
4.22.1.
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.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If
users are on the 4.22.x releases stream, then they are suggested to upgrade to
4.22.1. If users are on the 4.18.x releases stream, then they are suggested to
upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life
before this issue was resolved and will not receive a fix, so deployments on
those lines must move to a supported release. For deployments that cannot
upgrade immediately, set the JVM-wide jdk.serialFilter system property, which
the affected code path honours because it reads through a
java.io.ObjectInputStream, for example
-Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; or
set the serializer endpoint option to a serializer that does not use Java
serialization, such as StringRedisSerializer, noting that this must be set as
the serializer option and not only on a custom redisTemplate. As defence in
depth, require authentication on the Redis instance and restrict which clients
may publish to the subscribed channels, and do not expose a Redis instance
consumed by Camel to untrusted networks.
Solution:
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x
releases stream should upgrade to 4.22.1. Users on the 4.18.x releases stream
should upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of
life before this issue was resolved and will not receive a fix, so deployments
on those lines must move to a supported release. A new deserializationFilter
endpoint option 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 4.23.0 and
4.22.1 the default 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. Because JdkSerializationRedisSerializer exposes
no hook for installing a filter, the serializer is constructed through its
Converter-based constructor with a deserializing converter that sets the filter
on the stream before the graph is read. The single change covers the consumer,
the producer read commands and SpringRedisIdempotentRepository.
Work Arounds:
Set the JVM-wide jdk.serialFilter system property, which the affected code path
honours because it reads through a java.io.ObjectInputStream, for example
-Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; or
set the serializer endpoint option to a serializer that does not use Java
serialization, such as StringRedisSerializer, noting that this must be set as
the serializer option and not only on a custom redisTemplate, because the
consumer reads getSerializer directly. As defence in depth, require
authentication on the Redis instance and restrict which clients may publish to
the subscribed channels, and do not expose a Redis instance consumed by Camel
to untrusted networks.
Credit:
Leon Zlobecki (finder)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-78165.html
https://issues.apache.org/jira/browse/CAMEL-24421
https://github.com/apache/camel/pull/25587
https://github.com/apache/camel/pull/25588
https://github.com/apache/camel/pull/25589
https://github.com/apache/camel/pull/25734
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-78165
