ppkarwasz opened a new pull request, #4365: URL: https://github.com/apache/logging-log4j2/pull/4365
> [!IMPORTANT] > This PR is part of the deserialization hardening work tracked in #4168. The Logging Services PMC does **not** use nor recommend Java serialization/deserialization, and [our security FAQ](https://logging.apache.org/security/faq.html#deserialization) has long documented this position. This work is submitted solely to reduce the false-positive "vulnerability" reports that keep being filed regardless of that FAQ. Its utility for end users is close to zero. Log4j takes a neutral stance on deserialization: if the user sets an `ObjectInputFilter` on the outer stream, the nested streams that Log4j creates in `SerializationUtil.readWrappedObject` get exactly that filter, nothing less and nothing more. If an object is allowed in the outer stream, it is allowed in the nested one too. - The outer `ObjectInputFilter` is now copied to the nested stream also when the outer stream is a `FilteredObjectInputStream`. Previously it was only copied for other streams. - `DefaultObjectInputFilter` is removed: for a plain `ObjectInputStream`, the nested stream no longer gets the Log4j allowlist added to the outer filter. - `SerializationUtil.assertFiltered` and all its call sites are removed: whether the stream is filtered is none of our business. - `FilteredObjectInputStream` is deprecated. Its Javadoc now documents the default allowlist and states that the class is internal and unsupported, is not a security boundary, is not used by Log4j itself, and that applications should use their own `ObjectInputFilter` or `jdk.serialFilter` (available since Java 8u121). This follows the discussion in #4255, where it was proposed that on Java 9+ Log4j should defer to the JDK filtering support. **Compatibility:** - On Java 9+, nested objects read from a plain `ObjectInputStream` without any filter are no longer checked against the Log4j allowlist. - On Java 8, `readObject` of Log4j classes no longer throws `IllegalArgumentException` when the stream is a plain `ObjectInputStream`. - `SerializationUtil.assertFiltered` is removed from the internal `org.apache.logging.log4j.util.internal` package. Older versions of `log4j-core`, `log4j-1.2-api`, `log4j-slf4j-impl` and `log4j-slf4j2-impl` call it from their `readObject` methods, so combining them with this version of `log4j-api` makes deserialization of their classes fail with `NoSuchMethodError`. - Code using `FilteredObjectInputStream` gets deprecation warnings. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
