Critical Apache Log4j2 Flaw Lets Attackers Bypass Security and Execute Code

Key Takeaways

• A new vulnerability, Log4j2 #4255, has been identified in Apache Log4j2.
• The flaw allows attackers to bypass deserialization allowlists and execute code remotely under very specific conditions.
• Affected systems are those that accept serialized Log4j events from untrusted network sources and process them with a specific filter.
• This issue is not comparable to the widespread Log4Shell vulnerability and requires a rare deployment scenario for exploitation.
• No CVE has been assigned yet, but mitigations are available for organizations with vulnerable configurations.

A recently disclosed vulnerability in Apache Log4j2 could enable threat actors to circumvent a deserialization allowlist, potentially leading to remote code execution in specific application environments. This issue is distinct from the widely publicized Log4Shell vulnerability and necessitates a very particular set of circumstances to be exploitable.

The flaw, internally tracked as Log4j2 #4255, impacts applications configured to accept serialized Log4j events via a network-accessible Java deserialization path.

At the core of this weakness is Log4j’s FilteredObjectInputStream, a component designed to restrict which Java classes can be loaded during the processing of serialized log events. Its allowlist notably includes Java.rmi.MarshalledObject, a Java container capable of holding another serialized object as an opaque byte array.

Researchers discovered that this outer MarshalledObject can successfully pass the Log4j allowlist, effectively concealing a malicious inner object. When Log4j subsequently invokes MarshalledObject.get(), Java proceeds to deserialize the embedded payload using a new, unfiltered ObjectInputStream. This critical step means the original allowlist does not scrutinize the hidden object graph, allowing a malicious object to bypass security controls.

New Apache Log4j2 Vulnerability Details

Exploitation Mechanism

The vulnerable execution flow is tied to Log4jLogEvent$LogEventProxy, which represents a serialized Log4j event. This proxy embeds the event message within a MarshalledObject and automatically retrieves it during deserialization.

An attacker could craft a specially designed malicious serialized Log4j event and transmit it to a vulnerable receiver. If processed, this could trigger the execution of a gadget chain present on the target system’s classpath.

A public reproduction lab, detailed in Dinosn reports Log4j2 #4255 on GitHub, successfully demonstrated this issue in Log4j 2.26.1 running on JDK 17. In the test environment, a malicious payload, nested within a MarshalledObject, achieved code execution when processed by an unauthenticated TCP receiver utilizing FilteredObjectInputStream.

The lab also confirmed that a Commons Collections 3.2.1 gadget chain could be executed without requiring the attacker to supply a class on the victim system. However, it’s crucial to distinguish this from the Log4Shell vulnerability; this flaw cannot be triggered simply by embedding a malicious string into an application log message.

Specific Conditions for Exploitation

Exploitation of Log4j2 #4255 demands a highly specific and uncommon configuration. An application must expose a receiver that accepts attacker-controlled serialized Log4j events, processes these events using FilteredObjectInputStream, and simultaneously includes a usable chain of Java deserialization gadgets.

Apache’s security guidance emphasizes that standard Log4j Core production code typically does not deserialize data received from external sources such as sockets or queues. The project describes FilteredObjectInputStream as a defense-in-depth utility rather than a comprehensive security boundary, cautioning that applications should never deserialize untrusted log event streams.

The flaw is best characterized as a dangerous deserialization bypass within legacy or custom Log4j event receivers, rather than a generalized remote code execution vulnerability impacting typical Log4j deployments. At the time of this report, Log4j2 issue #4255 remained an open issue without an assigned CVE.

What You Should Do

• Identify Legacy Receivers: Actively search for and identify any legacy serialized Log4j event receivers within your infrastructure, particularly unauthenticated network services based on older socket bridge patterns.
• Avoid Untrusted Deserialization: Ensure that applications do not deserialize untrusted log event streams from external sources.
• Configure JVM Serialization Filter: As a temporary mitigation, configure the JVM serialization filter to reject Java.rmi.MarshalledObject. Be aware that this may also block legitimate serialized Log4j events.
• Remove Java Serialization: For long-term security, consider removing Java serialization from log transport mechanisms entirely.
• Upgrade/Remove Gadget Dependencies: Upgrade or remove any vulnerable gadget dependencies that could be exploited through deserialization.
• Implement Mutual Authentication: Utilize mutually authenticated endpoints for any log transport that involves serialization.
• Migrate to Secure Formats: Transition to structured logging formats like JSON or RFC 5424 over TLS, which are more secure than Java-serialized log transport.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.