New Apache Log4j2 Flaw Lets Attackers Bypass Security Checks and Execute Remote Code

A newly disclosed Apache Log4j2 issue could allow attackers to bypass a deserialization allowlist and execute code remotely in narrowly defined deployments.

The issue, tracked as Log4j2 #4255, affects applications that accept serialized Log4j events through a network-accessible Java deserialization path.

The reported weakness involves Log4j’s FilteredObjectInputStream, a utility designed to restrict which Java classes can be loaded while reading serialized log events. Its allowlist includes Java.rmi MarshalledObject, a Java container that can store another serialized object as an opaque byte array.

Researchers found that this outer object can pass the Log4j allowlist while concealing a malicious inner object. When Log4j later calls MarshalledObject.get(), Java deserializes the embedded payload using a fresh, unfiltered ObjectInputStream. This means the original allowlist does not inspect the hidden object graph.

New Apache Log4j2 Vulnerability

The vulnerable flow is linked to Log4jLogEvent$LogEventProxy, the serialized representation of a Log4j event. The proxy places the event message inside a MarshalledObject and retrieves it automatically during deserialization.

An attacker could craft a malicious serialized Log4j event, send it to a vulnerable receiver, and cause a gadget chain available on the target classpath to execute.

Dinosn reports Log4j2 #4255 on GitHub, where a public reproduction lab demonstrated the issue in Log4j 2.26.1 running on JDK 17. In the test environment, a malicious payload embedded in a MarshalledObject triggered code execution when processed by an unauthenticated TCP receiver using FilteredObjectInputStream.

The lab also showed that a Commons Collections 3.2.1 gadget chain could execute without requiring an attacker-supplied class on the victim system. However, the issue is not comparable to the widespread Log4Shell vulnerability. It cannot be triggered simply by placing a malicious string into an application log message.

Exploitation requires a specific and uncommon setup: an application must expose a receiver that accepts attacker-controlled serialized Log4j events, processes them using FilteredObjectInputStream, and includes a usable chain of Java deserialization gadgets.

Apache’s security guidance stresses that current Log4j Core production code does not normally deserialize data received from sockets, queues, or other external sources.

The project describes FilteredObjectInputStream as a defense-in-depth utility rather than a complete security boundary. It warns that applications should not deserialize untrusted log event streams.

Organizations should identify legacy serialized Log4j event receivers, especially unauthenticated network services based on old socket bridge patterns.

A temporary mitigation is to configure the JVM serialization filter to reject Java.rmi.MarshalledObject, although this may also block legitimate serialized Log4j events.

More durable defenses include removing Java serialization from log transport, upgrading or removing vulnerable gadget dependencies, using mutually authenticated endpoints, and migrating to JSON or RFC 5424 logging over TLS.

Apache specifically recommends structured formats and TLS rather than Java-serialized log transport. At the time of reporting, Log4j2 issue #4255 remained open and had no assigned CVE.

The flaw is best understood as a dangerous deserialization bypass in legacy or custom Log4j event receivers, not a universal remote code execution flaw affecting ordinary Log4j deployments.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC