ppkarwasz commented on issue #4255: URL: https://github.com/apache/logging-log4j2/issues/4255#issuecomment-5434666570
In case you are wondering what this was, this was an independent discovery of a known security non-finding: [FAQ entry about deserialization of untrusted data](https://logging.apache.org/security/faq.html#deserialization). **TL;DR**: if your application uses `java.io.ObjectInputStream` to deserialize untrusted data, this can lead to remote code execution (see warning in [OpenJDK Javadoc](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/io/ObjectInputStream.html)). The same applies to deserializing untrusted data using `o.a.l.l.util.FilteredObjectInputStream`, which is a hardening measure and never was a trust boundary. The report itself is accurate on the details: `java.rmi.MarshalledObject` is on the allowlist, `MarshalledObject.get()` opens a fresh unfiltered stream. None of that changes the precondition. You still need an application feeding untrusted bytes to a Java deserialization endpoint, and once you have that, you have remote code execution with or without this allowlist entry. We have been aware of the limitation for some time and discussion #4168 is open since July to see if any user is interested in implementing the missing hardening. No one is, which means our limited **volunteer** time can be spent on more useful tasks. Patches are welcome. No CVE, no embargo, nothing here that needs to be kept confidential. What made the news in this issue is that it was nearly deleted before anyone had triaged it. Let me remind you the first rule of security response: brew some good ☕ . -- 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]
