Apache Camel: Camel-Spring-Redis Unfiltered Java Deserialization of Redis Payloads

Summary

CVECVE-2026-78165
StatePUBLISHED
Assignerapache
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-10-19 11:17:19 UTC
Updated2026-10-20 14:17:01 UTC
DescriptionDeserialization 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.

Risk And Classification

Primary CVSS: v3.1 8.8 HIGH from [email protected]

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS: 0.007690000 probability, percentile 0.548460000 (date 2026-10-20)

Problem Types: CWE-502 | CWE-502 CWE-502 Deserialization of Untrusted Data


VersionSourceTypeScoreSeverityVector
3.1[email protected]Secondary8.8HIGHCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
3.1CNACVSS8.8HIGHCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVSS v3.1 Breakdown

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Apache Software Foundation Apache Camel affected 2.11.0 4.18.5 maven Not specified
CNA Apache Software Foundation Apache Camel affected 4.19.0 4.22.1 maven Not specified
CNA Apache Software Foundation Apache Camel unaffected 4.18.5 maven Not specified
CNA Apache Software Foundation Apache Camel unaffected 4.22.1 maven Not specified
CNA Apache Software Foundation Apache Camel unaffected 4.23.0 maven Not specified

References

ReferenceSourceLinkTags
camel.apache.org/security/CVE-2026-78165.html [email protected] camel.apache.org
github.com/apache/camel/pull/25589 [email protected] github.com
github.com/apache/camel/pull/25587 [email protected] github.com
github.com/apache/camel/pull/25588 [email protected] github.com
github.com/apache/camel/pull/25734 [email protected] github.com
github.com/oscerd/CVE-2026-78165 134c704f-9b21-4f2e-91b3-4a467353bcc0 github.com
issues.apache.org/jira/browse/CAMEL-24421 [email protected] issues.apache.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

Vendor Comments And Credit

Discovery Credit

CNA: Leon Zlobecki (en)

CNA: Andrea Cosentino (en)

Additional Advisory Data

Solutions

CNA: 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.

Workarounds

CNA: 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.

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report