A newly uncovered vulnerability in Apache Log4j2—tagged issue #4255—could allow malicious actors to sidestep existing security filters and execute remote code under specific circumstances. The flaw impacts applications that accept serialized Log4j events over a network and use Java deserialization paths. It stems from the behavior of Log4j’s FilteredObjectInputStream and its interaction with Java.rmi.MarshalledObject.
How the Flaw Works
Normally, FilteredObjectInputStream restricts what Java classes may be loaded when processing serialized log event data. The allowlist includes classes like Java.rmi.MarshalledObject. However, researchers discovered a method to hide a malicious object within that MarshalledObject. Because the outer container passes the allowlist check, once the system invokes MarshalledObject.get(), it deserializes the internal object using an *unfiltered* ObjectInputStream. That means the hidden object isn’t subjected to the allowlist, enabling it to execute code if certain gadget chains are present.
The vulnerable deserialization path is tied to Log4j’s LogEventProxy, which serializes a LogEvent by wrapping it in a MarshalledObject. In lab tests performed with Log4j version 2.26.1 on JDK 17, a crafted payload hidden inside a MarshalledObject triggered remote code execution via an attacker-built Commons Collections 3.2.1 gadget chain. Notably, the exploit worked without the attacker needing to supply classes to the target—an unusual and concerning behavior.
Scope, Limitations & Mitigation
This isn’t as broadly dangerous as Log4Shell. It requires a specific setup: the application must process attacker-controlled serialized Log4j events over a network receiver, use FilteredObjectInputStream, and include vulnerable gadget dependencies on its classpath. Typical production setups don’t deserialize log data from external sources this way.
Apache emphasizes that FilteredObjectInputStream was meant as a defense-in-depth precaution—not a complete safeguard. The Log4j team recommends avoiding deserialization of untrusted log event streams entirely.
Short-term mitigation steps include configuring the JVM’s serialization filter to reject Java.rmi.MarshalledObject—though this may block legitimate serialized log events in some environments. Long-term defenses involve removing Java serialization in log transport paths, eliminating eligible gadget chains, switching to structured logging formats (like JSON or RFC 5424), securing endpoints with mutual authentication, and using TLS for transport security.
As of today, the issue remains under review and has not yet been assigned a Common Vulnerabilities and Exposures (CVE) identifier. Log4j2 issue #4255 remains open with no full resolution in place.
Why This Matters: While this flaw isn’t a mass-scale replacement for Log4Shell, it underscores how tricky deserialization security can be. Attack paths once considered protected by allowlists can still be exploited under specific conditions. Organizations using Log4j2 should inventory whether they accept serialized log events over open channels, review dependencies for dangerous gadget chains, and adopt safer logging architectures going forward. Observing how this vulnerability progresses—including whether it gains a CVE and how widely it can be weaponized—will be crucial in the coming weeks.
