oscerd opened a new pull request, #25562: URL: https://github.com/apache/camel/pull/25562
## What `camel-netty`'s object codecs were the last Java-serialization entry points in the component that did not resolve their `ObjectInputFilter` through the shared `DeserializationFilterHelper` (introduced in CAMEL-23815). `ObjectDecoder` previously installed a filter only when an explicit `deserializationFilter` pattern was passed; the single-argument constructor passed `null`, so decoders built that way (the common case — what the component docs and tests show) applied **no filter at all** and only logged a warning. `DatagramPacketObjectDecoder` inherited the same behaviour. The filter is now resolved via `DeserializationFilterHelper.resolveDeserializationFilter(...)`: an unset pattern falls back to the JVM-wide `jdk.serialFilter` and then to the shared Camel default allow-list, so a filter is **always** installed — matching what `NettyConverter` and `camel-netty-http` already do. ## Scope note (no endpoint option) The issue also proposed a `deserializationFilter` **endpoint** option for parity with `camel-netty-http`. On investigation that is not applicable: unlike netty-http, plain `camel-netty` never auto-instantiates the object codecs — `ObjectEncoder` / `ObjectDecoder` are always user-supplied via the `encoders` / `decoders` bean refs (there is no component-built codec to thread an endpoint option into, not even for `transferExchange`). The configuration surface is therefore the existing two-argument `ObjectDecoder(ClassResolver, String)` / `DatagramPacketObjectDecoder(ClassResolver, String)` constructor, documented in `netty-component.adoc`. Adding an endpoint option would have been a dead no-op. ## Testing - New `ObjectDecoderDeserializationFilterTest` (Netty `EmbeddedChannel`): the default filter allows a standard type, rejects a non-allow-listed class (`java.net.URI`), and an explicit pattern can allow an otherwise-denied class. - Removed the pre-fix `NettyUnfilteredDeserializationReproducerTest`: its `SimulatedGadget` lives under `org.apache.camel.**` and is therefore allow-listed by the default filter, so it no longer demonstrated the vulnerability (real-world gadget chains under `org.apache.commons.**` etc. are rejected by the default `!*`). - Existing object-serialization tests (`ObjectSerializationTest`, `NettyTransferExchangeOptionTest`, `NettyConcurrentTest`) pass unchanged. - `camel-netty` + dependents build cleanly. ## Docs - `netty-component.adoc` note on the default-on filter and how to configure a stricter one. - Upgrade-guide entry in `camel-4x-upgrade-guide-4_22.adoc` (behavioural change). _Claude Code on behalf of oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
