ppkarwasz opened a new pull request, #4270: URL: https://github.com/apache/logging-log4j2/pull/4270
> [!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. The `SerialUtil` test helper returned a plain, unfiltered `ObjectInputStream` on Java 9 and later, so our test suite only exercised the deserialization allowlist when running on a Java 8 toolchain. This made it possible for a change to the serialized forms to pass CI while being rejected by the filter at runtime. `SerialUtil` now installs `DefaultObjectInputFilter` on Java 9+ (reflectively, since the helper must still compile and run on Java 8), combined with an `ObjectInputFilter.Config.createFilter` delegate built from the caller-supplied extra allowed classes — reproducing `FilteredObjectInputStream`'s semantics on modern JDKs. When `DefaultObjectInputFilter` is unavailable — it only exists in the packaged multi-release `log4j-api` jar, not in classes-dir reactor builds — the helper falls back to `FilteredObjectInputStream`, which enforces the same allowlist on any Java version. `SerializationTestHelper` in `log4j-1.2-api` now delegates to `SerialUtil`, so its `org.apache.log4j.*` extras are honored on all Java versions as well. Test-only change; no user-visible behavior is affected. -- 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]
