[backport camel-4.18.x] CAMEL-24421: camel-spring-redis - apply a deserialization filter to the default JDK serializer - #25589
Merged
Conversation
…he default JDK serializer RedisConfiguration.createDefaultSerializer() built a bare JdkSerializationRedisSerializer, whose read path runs through Spring's ConfigurableObjectInputStream with no ObjectInputFilter installed. Every other component in the codebase that performs JDK deserialization -- camel-consul, camel-leveldb, camel-mina, camel-netty, camel-netty-http, camel-vertx-http, camel-jms, camel-sjms, camel-http-common, camel-cassandraql -- resolves a filter first, so camel-spring-redis was the one path left without one. The default serializer now installs a filter resolved through DeserializationFilterHelper: the new deserializationFilter option when set, otherwise the JVM-wide jdk.serialFilter, otherwise the shared Camel allow-list. JdkSerializationRedisSerializer exposes no hook for a filter, so the serializer is built through its Converter-based constructor with a deserializing converter that sets one on the stream. Serialization is left untouched, and class resolution is unchanged: the same null class loader Spring's DefaultDeserializer uses by default is passed through. This covers the three places that share the default serializer -- the consumer, which deserializes the payload of every message published to the subscribed channels; the producer read commands, through the default RedisTemplate; and SpringRedisIdempotentRepository, which builds that same template. Note that setting a custom redisTemplate does not reach the consumer, which reads getSerializer() directly, so the option covers both paths. Setting the serializer option to a custom RedisSerializer bypasses the filter, since Camel then no longer controls how the payload is read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit d35b455)
oscerd
force-pushed
the
fix/CAMEL-24421-4.18.x
branch
from
August 24, 2026 07:38
a23c7ed to
3fe0485
Compare
gnodet
approved these changes
Aug 24, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
Clean, well-structured backport of a security hardening change that closes the last JDK deserialization path without an ObjectInputFilter. The approach is consistent with how other components (NettyHttpHelper, MinaConverter, JmsBinding) handle the same concern on the 4.18.x branch, CI passes, and tests are comprehensive.
Key observations:
- The
FilteringDeserializerclass correctly mirrors the local-constant +resolveDeserializationFilterpattern already used byNettyHttpHelperandMinaConverteroncamel-4.18.x, whereDeserializationFilterHelperdoes not exist. - The default filter value (
!java.net.**;java.**;javax.**;org.apache.camel.**;!*) is identical to those components, correctly omitting the JEP-290 graph-shape limits (maxdepth,maxrefs,maxbytes) which are a main-only addition (CAMEL-23609). - The
@UriParam(label = "advanced,security")annotation correctly categorizes the option as a security hardening parameter. - The upgrade guide entry clearly documents the behavioral change and provides a concrete example for users who need to widen the filter.
- The PR correctly notes "Do not merge before #25587" to ensure the main PR lands first.
📋 PR Metadata
| Aspect | Current | Suggested |
|---|---|---|
| Labels | (none) | bug |
| Milestone | (none) | 4.18.4 |
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of @gnodet
davsclaus
approved these changes
Aug 24, 2026
This was referenced Aug 26, 2026
oscerd
added a commit
to oscerd/camel
that referenced
this pull request
Aug 27, 2026
… 4.22 and 4.18 upgrade guides The upgrade guides for every release line live on main, which holds the canonical history across all releases. The deserialization filter shipped on three lines -- 4.23.0 (apache#25587), 4.22.1 (apache#25588) and 4.18.5 (apache#25589) -- but only the 4.23 note was added here; the 4.22 and 4.18 notes went in on the maintenance branches, where they are not part of that history. Adds both, matching the text that shipped on each branch: the 4.22 note names the JEP-290 graph-shape limits that DeserializationFilterHelper enforces there, the 4.18 note does not, because on that line the filter is the local constant without them. Both are new leading sections, keeping the reverse-chronological order the guides already use. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
oscerd
added a commit
that referenced
this pull request
Aug 27, 2026
… 4.22 and 4.18 upgrade guides (#25734) The upgrade guides for every release line live on main, which holds the canonical history across all releases. The deserialization filter shipped on three lines -- 4.23.0 (#25587), 4.22.1 (#25588) and 4.18.5 (#25589) -- but only the 4.23 note was added here; the 4.22 and 4.18 notes went in on the maintenance branches, where they are not part of that history. Adds both, matching the text that shipped on each branch: the 4.22 note names the JEP-290 graph-shape limits that DeserializationFilterHelper enforces there, the 4.18 note does not, because on that line the filter is the local constant without them. Both are new leading sections, keeping the reverse-chronological order the guides already use. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #25587 to
camel-4.18.x.Description
RedisConfiguration.createDefaultSerializer()builds a bareJdkSerializationRedisSerializer, whose read path runs through Spring'sConfigurableObjectInputStreamwith noObjectInputFilterinstalled. Every other component in the codebase that performs JDK deserialization resolves a filter first —camel-spring-rediswas the one path left without one.Adds a
deserializationFilterendpoint option (advanced,security). The default serializer now installs a filter: the configured pattern when set, otherwise the JVM-widejdk.serialFilter, otherwise a conservative default allow-list. This covers the consumer, the producer read commands, andSpringRedisIdempotentRepository, which all share the default serializer.Differences from the main PR
DeserializationFilterHelperdoes not exist on this branch, soFilteringDeserializercarries its ownDEFAULT_DESERIALIZATION_FILTERconstant and a localresolveDeserializationFilter, following the pattern already used here byNettyHttpHelper,JmsBindingandMinaConverter. As on those classes, the constant is!java.net.**;java.**;javax.**;org.apache.camel.**;!*without the JEP-290 graph-shape limits, which are main-only (CAMEL-23609) — the upgrade-guide wording reflects that.The upgrade-guide entry goes in
camel-4x-upgrade-guide-4_18.adoc.Verified that
JdkSerializationRedisSerializer(Converter, Converter),ConfigurableObjectInputStream(InputStream, ClassLoader)andDeserializer.deserializeare identical on the Spring 6.2 / Spring Data 3.5 used here, so the code compiles the same way as on main.Testing
123/123module tests pass, including the 5 new ones.Note: this branch has ~146 generated files carrying a stale
4.18.4-SNAPSHOTversion string that any local build rewrites to4.18.5-SNAPSHOT. That drift is pre-existing and unrelated to this change, so it is deliberately not included here.Do not merge before #25587.
Claude Code on behalf of oscerd