ppkarwasz opened a new pull request, #4269: URL: https://github.com/apache/logging-log4j2/pull/4269
> [!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. On Java 8, `FilteredObjectInputStream` is the only deserialization protection available, but dynamic proxy class descriptors are resolved through `ObjectInputStream#resolveProxyClass`, not `resolveClass`, so they bypassed the allowlist entirely. A stream could thus instantiate a proxy of arbitrary interfaces on the Java 8 code path. On Java 9 and later, the JEP 290 filter already rejects proxies, because their synthetic class names (`com.sun.proxy.$ProxyN`, `jdk.proxy1.$ProxyN`, …) never match the allowlist. This PR aligns the Java 8 path by overriding `resolveProxyClass` to reject proxies outright — no supported Log4j serialized form contains one. The rejection also applies when extra allowed classes are supplied to the constructor; proxies are never legitimate in a Log4j stream, so there is no opt-out. -- 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]
