Log4j2 Has a Deserialization Bypass. No, This Is Not Another Log4Shell

• The Mess: A newly public Log4j2 issue shows that its FilteredObjectInputStream allowlist can be bypassed using Java’s MarshalledObject, allowing a malicious serialized Log4j event to hide an inner object from the filter. In a very specific network-facing configuration, that can lead to remote code execution.

This sounds terrifying.

It isn’t Log4Shell 2.0.

That’s important.

The problem is real, and researchers demonstrated the technical path on Log4j 2.26.1 with JDK 17. But ordinary applications that simply write log messages are not suddenly remotely exploitable.

The attack requires a rather unusual setup.

The application has to accept serialized Log4j events over a network, process them using FilteredObjectInputStream, and have a usable Java deserialization gadget chain available on the target classpath.

That’s a much narrower target than Log4Shell.

But the bypass itself is nasty.

The allowlist sees:

java.rmi.MarshalledObject

and says:

“Looks allowed.”

Inside that object sits another serialized object.

When Log4j later calls MarshalledObject.get(), the embedded object is deserialized using a new ObjectInputStream that doesn’t inherit the original filtering rules.

The security filter effectively checks the box.

The dangerous package is inside the box.

• The Damage: In affected custom or legacy deployments, an attacker who can submit malicious serialized Log4j events could potentially bypass the deserialization filter and trigger a gadget chain leading to remote code execution.

The interesting part is that there is no CVE assigned at the time of reporting and no upstream patch specifically for this issue.

Apache’s own maintainer had already documented the same code path as a hardening concern, arguing that FilteredObjectInputStream was never intended to be a complete security boundary for untrusted Java deserialization.

That’s a significant distinction.

Security researchers say:

the filter can be bypassed.

Apache’s position is effectively:

don’t treat Java deserialization of untrusted data as safe just because there’s an allowlist.

Both statements can be true.

And that’s why calling this “critical Log4j RCE” without qualification would be irresponsible.

The vulnerable code path is real.

The exploitation conditions are not common.

This isn’t another vulnerability where an attacker sends a malicious string into an ordinary application log field and immediately gets a shell.

• The Fix: Do not deserialize untrusted Java objects; if you operate a serialized-Log4j event receiver, isolate it, apply a JVM-wide serialization filter such as JEP 290, and avoid Java-serialized log transport in favor of structured formats over protected connections.

Apache’s guidance specifically favors structured formats and TLS instead of Java-serialized log transport.

For normal Log4j deployments, there is no reason to panic and rip out every Log4j installation tonight because of this report.

But if you’ve deliberately built a system that accepts serialized Log4j events from remote clients?

Now is a very good time to inspect it.

Look for:

• FilteredObjectInputStream;
• serialized LogEvent receivers;
• Socket or custom network-based Log4j event transport;
• Java deserialization from untrusted sources;
• legacy logging infrastructure;
• custom gadget-bearing dependencies.

And don’t assume the allowlist makes arbitrary Java deserialization safe.

It doesn’t.

That’s the deeper lesson.

Bugstoday Opinion

This is exactly the kind of story that gets destroyed by bad headlines.

“Log4j RCE!”

Everyone panics.

Security teams start scanning everything.

People remember Log4Shell.

But that’s not what this is.

The bypass is technically interesting and potentially dangerous in the right environment. The exploitation requirements, however, are narrow enough that comparing it directly with CVE-2021-44228 would be nonsense.

The bigger problem is the assumption that a deserialization allowlist turns unsafe Java deserialization into safe Java deserialization.

It doesn’t.

Bugstoday verdict: real bug, interesting attack path, very limited deployment conditions. Don’t call it Log4Shell 2.0 — but if your infrastructure accepts untrusted serialized Java objects, stop doing that.