CAMEL-24296: camel-support - apply a JEP-290 deserialization filter on CamelObjectInputStream by default - #25378
Merged
Merged
Conversation
…n CamelObjectInputStream by default CamelObjectInputStream is the shared ObjectInputStream used by Camel's Java-object deserialization paths but installed no ObjectInputFilter, leaving any direct caller unprotected. It now resolves a filter via DeserializationFilterHelper and installs it with setObjectInputFilter(): when no explicit pattern is supplied the JVM-wide jdk.serialFilter is honoured if set, otherwise the default Camel allow-list is applied (permits standard Java and Apache Camel types, denies java.net.**, enforces JEP-290 graph-shape limits). A new (InputStream, CamelContext, String) constructor accepts an explicit filter pattern. HttpHelper now passes its configured pattern through that constructor instead of calling setObjectInputFilter() separately; the built-in HTTP path already applied the default filter, so its behaviour is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
approved these changes
Aug 6, 2026
Contributor
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 556 tested, 28 compile-only — current: 555 all testedMaveniverse Scalpel detected 584 affected modules (current approach: 555).
|
gnodet
reviewed
Aug 6, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
Good security hardening — centralizing JEP-290 filter application in the CamelObjectInputStream constructor is the right approach. The deny-by-default posture (!*) and the fallback chain (explicit pattern → JVM-wide jdk.serialFilter → Camel default) give operators appropriate control. Tests cover the meaningful code paths well.
Two minor observations below.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of @gnodet
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.
What
CamelObjectInputStreamis the sharedObjectInputStreamused by Camel's Java-object deserialization paths (e.g. the HTTP components), but it installed nojava.io.ObjectInputFilter, so any code constructing it directly deserialized without a JEP-290 filter.This change makes
CamelObjectInputStreamresolve a filter via the existingDeserializationFilterHelperand install it withsetObjectInputFilter():jdk.serialFilteris honoured if set, otherwise the default Camel allow-list (DEFAULT_DESERIALIZATION_FILTER) is applied — permits standard Java and Apache Camel types, deniesjava.net.**, and enforces JEP-290 graph-shape limits.CamelObjectInputStream(InputStream, CamelContext, String)constructor accepts an explicit filter pattern.HttpHelpernow passes its configured pattern through the new constructor instead of callingsetObjectInputFilter()separately. The built-in HTTP path already applied the default filter (viaDeserializationFilterHelper), so its runtime behaviour is unchanged — this closes the gap for any direct instantiation and centralizes the filter on the stream itself.Why
Defense-in-depth against unsafe deserialization: the shared stream is now safe-by-default and configurable, consistent with the deserialization filtering already applied by
camel-jms,camel-mina,camel-nettyandcamel-netty-http.Testing
CamelObjectInputStreamTest(4 tests): the default filter allows standard types, rejects a class outside the allow-list, a blank pattern falls back to the default, and an explicit pattern can allow an otherwise-denied class.mvn clean install -DskipTestspasses.Docs
camel-4x-upgrade-guide-4_22.adoc(publiccamel-supportclass default change).Claude Code on behalf of oscerd