A currently unconfirmed vulnerability in Apache Log4j could allow remote code execution (RCE) by bypassing the allowlist enforced by FilteredObjectInputStream (FOIS) during Java deserialization.
Exploitation requires an uncommon configuration in which an application or logging service accepts serialized Log4j LogEvent objects through an FOIS-based receiver, as well as a suitable deserialization gadget on the target classpath. Unlike Log4Shell, the issue cannot be triggered simply by causing an application to log attacker-controlled data.
The initial Log4j GitHub issue was scrubbed, but is preserved here:
PoCs (unconfirmed) of the issue have been published.
Affected Products
Apache Log4j API: 2.11.0–2.26.1
Apache Log4j Core: 2.8.0–2.26.1
Actions
Mitigations, per the PoC:
Remove java.rmi.MarshalledObject from REQUIRED_JAVA_CLASSES.
Replace the MarshalledObject<Message> field in LogEventProxy with a byte[] serialized via SerializationUtil.writeWrappedObject() / readWrappedObject(). That’s the same pattern ObjectMessage already uses correctly.
Notes
The PoCs appear valid, but there are two important conditions for exploitation:
The application must expose a FOIS-based serialized LogEvent receiver to untrusted input
A usable gadget library must be on the classpath (e.g., Commons Collections 3.2.1)
This latter is critical, as apparently the exploitability of the gadgets used in the PoCs (Common Collections 3.2.1) was patched in 3.2.2.
However, per the hypnguyen PoC:
The filter bypass exists regardless of CC version. CC’s guard is defense-in-depth at the gadget layer, not a fix for the broken filter. Any other unguarded gadget library (Groovy, BeanShell, Spring Beans, etc.) enables the same attack.
Exploitation requires an uncommon configuration in which an application or logging service accepts serialized Log4j LogEvent objects through an FOIS-based receiver, as well as a suitable deserialization gadget on the target classpath. Unlike Log4Shell, the issue cannot be triggered simply by causing an application to log attacker-controlled data.
In order for this vulnerability to be exploitable, an attacker would need to find an application that exposes an unauthenticated, network-facing serialized-log receiver, which is not a default configuration - it’s merely anecdotal, but the two Java-developers I asked about it both told me that in their entire career they have never seen this be a thing.
This article has some interesting additional details that change the perspective as well:
On 1 July 2026, Log4j maintainer Piotr P. Karwasz opened a public GitHub discussion listing five deserialization findings surfaced during a review. The first, marked “High” priority, describes the marshalledMessage field, the readResolve() → message() → marshalledMessage.get() call chain, and the fact that MarshalledObject’s private stream “does not inherit Log4j’s per-stream filter” — the same finding U-Sec would post as a critical vulnerability on 24 August.
The framing is the whole story. Karwasz’s post opens by stating plainly, “These are not security issues.” It reiterates the project’s threat model: “Log4j does not deserialize data as part of normal operation,” and filtering the stream by Java package is “not sufficient to make deserialization safe.” The list is explicitly labeled “hardening” — the defensive tightening of a layer that was never a security boundary, not the patching of an exposed hole.
And on the likelihood of exploitation the authors say:
A containerised proof-of-concept published after the report does achieve code execution — but its own documentation states it requires “an unauthenticated FOIS-based serialized-LogEvent receiver,” a component the lab has to build for itself because stock Log4j no longer ships one. That is the precise condition Apache warns against: its security policy says there is “no guarantee that deserializing a stream … is safe, regardless of the source.” The bypass is genuine; the exposure is opt-in and rare.
