Apache Log4j2 Java Deserialization Filter Bypass Could Enable Remote Code Execution ...

Affected software: Affected software: Apache Log4j2 log4j-api 2.11.0–2.26.1 and log4j-core 2.8.0–2.26.1, when used in affected serialized LogEvent receiver configurations

Type: Deserialization / Remote Code Execution

CVE/CVSS: No CVE assigned / No official CVSS score at the time of publication

Researcher Nguyen Van Hiep -

A newly disclosed weakness in Apache Log4j2 can allow remote code execution on affected systems through unsafe Java deserialization.

The exposure is significantly narrower than Log4Shell (CVE-2021-44228) . This issue does not affect ordinary applications merely because they use Log4j2 or process attacker-controlled log messages. An attacker must be able to reach a service that specifically accepts Java-serialized Log4j LogEvent objects.

Where all prerequisites are present, an unauthenticated attacker may be able to execute arbitrary code with the privileges of the affected Java process. The same attack path may also enable denial of service (DoS) through resource-exhausting object graphs.

Organisations should therefore prioritize investigation of serialized LogEvent receivers rather than treating all Log4j2 installations as exposed.

The issue concerns Log4j2's FilteredObjectInputStream (FOIS), which provides an allowlist intended to restrict Java deserialization. The allowlist permits only org.apache.logging.log4j.* , java.lang.* , java.util.* , and a few explicit classes to pass through, including java.rmi.MarshalledObject . This object can contain a second serialized object inside an opaque byte array.

During processing of a serialized Log4j LogEvent , Log4j invokes MarshalledObject.get() . This triggers a second Java deserialization operation for the object embedded within the MarshalledObject . The get() operation uses a standard ObjectInputStream to deserialize the embedded data rather than Log4j's FilteredObjectInputStream ; consequently, the nested deserialization is not subject to the original Log4j class allowlist. An attacker can therefore use the MarshalledObject to introduce an otherwise disallowed object graph, potentially enabling execution of a deserialization gadget chain and remote code execution.

The demonstrated exploitation does not generate an application-level error or Log4j log entry indicating successful exploitation: the exception resulting from the malicious payload is caught and suppressed, allowing code execution to occur without an obvious trace in the application's logs. Exploitation requires a specific combination of conditions:

Normal Log4j usage, including ordinary logger.info() calls and standard JSON or syslog logging, does not by itself expose this attack path.

Organisations should determine whether any Java applications:

The focus should not be put on the version of Log4j. The old in-core serialized socket server was removed after Log4j 2.8.2. Modern exposure therefore comes from applications, copied/adapted sample code, or legacy integrations that still feed serialized events into the attack path.

At the time of this advisory, no official Log4j release specifically fixing this issue has been identified. Organisations should monitor the Apache Log4j security advisory and issue tracker for an official remediation and apply the relevant update when available.

Until vendor remediation is available, organisations should prioritize identifying and restricting affected serialized-event receivers and apply the mitigations below.

Apache’s Log4j 2.x deserialization-hardening discussion further describes MarshalledObject.get() as an allow-list escape but also states that deserializing untrusted Log4j data is outside the project’s security guarantee. The legacy in-core serialized socket server was removed after Log4j 2.8.2. Current exposure therefore primarily comes from applications, copied or adapted sample code, or legacy integrations that continue to deserialize serialized LogEvents .

The CCB recommends organizations increase monitoring for unexpected activity from Java processes hosting serialized-event receivers to ensure a swift response in case of an intrusion, particularly:

Organizations should not rely on application logs or deserialization errors as the sole means of detecting exploitation. The published proof of concept demonstrates that successful command execution can occur while the receiver returns a normal HTTP 200 response and produces no corresponding application-level error or Log4j log entry.

Where exploitation is suspected, investigate the affected Java process and its host for evidence of command execution or persistence.

In case of an intrusion, you can report an incident via . While patching appliances or software to the newest version may protect against future exploitation, it does not remediate historic compromise.