New Apache Log4j2 Flaw Enables Remote Code Execution via Deserialization Bypass
A newly discovered vulnerability in Apache Log4j2, tracked as #4255, allows attackers to bypass deserialization allowlists and achieve remote code execution in specific, uncommon scenarios.
A recently disclosed vulnerability in the popular Apache Log4j2 logging library, identified as Log4j2 #4255, presents a risk of remote code execution (RCE) for applications that accept serialized Log4j events over a network. This flaw specifically targets scenarios where applications process network-received serialized events using Log4j's FilteredObjectInputStream, a mechanism intended to restrict deserialization.
The vulnerability arises from a bypass of the allowlist mechanism within FilteredObjectInputStream. While this utility is designed to permit only specific Java classes during deserialization, researchers found that a malicious object can be concealed within a legitimate-looking outer object, such as Java.rmi.MarshalledObject. This outer object passes the allowlist check, but when Log4j subsequently deserializes the embedded malicious payload, it uses a fresh, unfiltered ObjectInputStream, thereby circumventing the initial security restrictions.
Exploitation requires a specific and somewhat uncommon configuration: an application must expose a network-accessible receiver that accepts attacker-controlled serialized Log4j events. This receiver must then process these events using FilteredObjectInputStream, and critically, the target system must have a usable Java deserialization gadget chain available on its classpath. The vulnerability is not comparable to the widespread Log4Shell (CVE-2021-44228), as it cannot be triggered by simply logging a malicious string.
Proof-of-concept demonstrations have shown the issue affecting Log4j 2.26.1 running on JDK 17, where a malicious payload embedded within a MarshalledObject led to code execution when processed by an unauthenticated TCP receiver. In these tests, a Commons Collections gadget chain was sufficient to achieve RCE without requiring an attacker to deploy custom code on the victim system.
Apache's security guidance emphasizes that standard Log4j Core production code does not typically deserialize data from external sources like sockets or queues. The FilteredObjectInputStream is considered a defense-in-depth measure rather than a complete security boundary. The project strongly advises against deserializing untrusted log event streams.
Organizations are urged to identify and secure any legacy or custom receivers that accept serialized Log4j events, particularly unauthenticated network services. While temporarily configuring the JVM serialization filter to reject Java.rmi.MarshalledObject can serve as a mitigation, it may also impact legitimate deserialization processes.
More robust and recommended defenses include eliminating Java serialization for log transport altogether, upgrading or removing vulnerable gadget dependencies, implementing mutually authenticated endpoints, and migrating to more secure structured logging formats like JSON or RFC 5424, preferably transmitted over TLS.
As of the reporting, Log4j2 issue #4255 has not been assigned a CVE identifier and remains an open issue. The vulnerability is best understood as a significant risk for specific deserialization-heavy legacy or custom receiver implementations, rather than a universal RCE flaw affecting typical Log4j deployments.