oscerd opened a new pull request, #23523: URL: https://github.com/apache/camel/pull/23523
## Summary Follow-up to the `CAMEL-23297` / `CAMEL-23319` / `CAMEL-23321` / `CAMEL-23322` / `CAMEL-23324` / `CAMEL-23372` series. The in-code default `ObjectInputFilter` shipped by the components below now also carries JEP-290 graph-shape limits (`maxdepth=20`, `maxrefs=10000`, `maxbytes=10485760`) in addition to the existing class allowlist. The class allowlist is unchanged. Affected sites (9): | Component | File | |---|---| | camel-infinispan | `DefaultExchangeHolderUtils.java` | | camel-mina | `MinaConverter.java` | | camel-netty | `NettyConverter.java` | | camel-netty-http | `NettyHttpHelper.java` | | camel-vertx-http | `VertxHttpHelper.java` | | camel-leveldb | `LevelDBAggregationRepository.deserializationFilter` | | camel-cassandraql | `CassandraAggregationRepository.deserializationFilter` | | camel-consul | `ConsulRegistry.deserializationFilter` | | camel-sql | `JdbcAggregationRepository.deserializationFilter` | For the 4 configurable defaults a package-private `DEFAULT_DESERIALIZATION_FILTER` constant is introduced so the value lives in one place and is referenced both by the field initializer and the `@Metadata(defaultValue = ...)` attribute. This keeps the catalog metadata JSONs, the javadoc and the field default in sync. ### Why graph-shape clauses and not just the class allowlist? The current class allowlist (`!java.net.**;java.**;javax.**;org.apache.camel.**;!*`) blocks gadget-chain RCE but does not bound how deep, how wide or how large an inbound serialized graph can be. Adding `maxdepth` / `maxrefs` / `maxbytes` is the standard JEP-290 way to bound CPU/memory cost during `readObject()` and is a pure defense-in-depth improvement. ### Operator overrides preserved * JVM-wide `-Djdk.serialFilter` still takes precedence over the Camel default in every site that ships one. * The configurable repositories and endpoint configurations (`LevelDBAggregationRepository`, `JdbcAggregationRepository`, `CassandraAggregationRepository`, `ConsulRegistry`, netty-http / vertx-http endpoint configuration) already expose a `deserializationFilter` `@UriParam` accepting a fully custom filter string, including structural clauses or none at all. ### Intentionally not changed: camel-jms / camel-sjms Both apply their filter as a post-deserialization class check (after the JMS provider has already decoded the payload via its own `ObjectInputStream`). Graph-shape limits are therefore no-ops in those sites and have not been added. DoS hardening on the JMS path must be configured at the JMS provider level (Artemis `deserializationAllowList`, ActiveMQ Classic `SERIALIZABLE_PACKAGES`) or via `-Djdk.serialFilter`. The upgrade-guide entry calls this out explicitly. ### Tests A small `DefaultFilterTest` (or equivalent test method added to an existing class) at each of the 9 sites asserts that the resolved default filter contains `maxdepth=`, `maxrefs=` and `maxbytes=`. For the 4 configurable sites the test additionally constructs the repository and asserts `getDeserializationFilter()` returns the same `DEFAULT_DESERIALIZATION_FILTER` constant. ### Upgrade guide `docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_21.adoc` gains a "Tightened default ObjectInputFilter across deserialization sites - potential breaking change" entry listing the affected components, the new defaults and the override paths, and noting the JMS exclusion. ## Test plan - [x] Module-level `mvn -B -DskipITs test` on each of the 9 changed modules - all pass locally. (One unrelated `NettyTCPSyncUDSTest` failure on local FS with long UDS path; not related to this change.) - [x] Full reactor `mvn -B clean install -DskipTests` succeeds; downstream catalog mirrors in `catalog/camel-catalog/.../beans/` regenerated and committed. - [ ] CI green. ## Notes for reviewers The new structural defaults are conservative (`maxdepth=20`, `maxrefs=10000`, `maxbytes=10MB`). They are intended to comfortably handle a `DefaultExchangeHolder` carrying a typical Exchange payload but to reject extremely deep / very wide / multi-megabyte graphs. If a route legitimately needs to deserialize a graph that exceeds any of these, the per-endpoint `deserializationFilter` option or `-Djdk.serialFilter` is the existing escape hatch. --- _Claude Code on behalf of Andrea Cosentino_ -- 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]
