Log4j Deserialization Bypass Is Real but Not Log4Shell

A security researcher using the handle U-Sec (Wujie Security) published brief details of a deserialization filter bypass in Apache Log4j 2, reporting that the framework's FilteredObjectInputStream allowlist can be sidestepped with java.rmi.MarshalledObject to smuggle arbitrary objects past its class checks.

Two days later, the report was stripped of its contents, renamed, and closed, and the researcher's GitHub account was deleted — but by then, a Log4j maintainer had already documented the same behavior publicly as a hardening item rather than a vulnerability.

No CVE has been assigned, and the report listed no CVSS score. The flaw is a deserialization allowlist bypass (a safety filter meant to block dangerous classes is tricked into permitting them), said to affect log4j-api 2.11.0 through the current 2.26.1.

Cyber Kendra archived the original report before it was removed, independently verified its technical claims against Apache's published source code, and found that the Log4j project itself had catalogued the exact same code path seven weeks earlier. The mechanism is real. The "critical RCE" framing is not the one Apache uses.

How the Log4j Filter Bypass Works

Log4j added FilteredObjectInputStream in 2017, after CVE-2017-5645, a socket-server flaw that allowed a crafted binary payload to run code when deserialized. The fix, shipped in 2.8.2, introduced an allowlist of classes permitted during the rebuilding of a serialized log event — everything else is rejected.

The reported weakness lies in what the allowlist lets through. It permits java.rmi.MarshalledObject, a standard Java class that stores its wrapped object as an opaque byte array. The filter inspects only the top-level class of each object it resolves; it never looks inside that byte array. 

When Log4j reconstructs the event, Log4jLogEvent.LogEventProxy calls .get() on a marshalled-message field, and .get() spins up a fresh ObjectInputStream with no filter attached. Whatever classes sit inside those bytes are then deserialized unchecked, so any usable gadget class on the application's classpath becomes reachable. Cyber Kendra is withholding payload specifics.

What Cyber Kendra Confirmed in the Source

We checked each link in the chain against the shipping Log4j 2.26.1 source rather than relying on either the researcher's or the maintainer's description. All four are present in the current release:

On the technical merits, this is not a fabrication. The bypass mechanism exists in code, and the allowlist entry is deliberate.

Apache Already Documented This — as Hardening, Not a Bug

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.

Which Log4j Versions Are Affected

The report listed log4j-api 2.11.0–2.26.1 and log4j-core 2.8.0–2.26.1. Version 2.26.1 is the current release, published on 2 July 2026, so the code is present in the newest build.

The socket-server classes that once received serialized log events over the network — TcpSocketServer and UdpSocketServer in the net.server package — were removed from log4j-core in version 2.9.0 and moved to a separate, unreleased tools module. Every version of the report flags already shipped without that listener.

Why This Is Not a Second Log4Shell

Log4Shell (CVE-2021-44228, CVSS 10.0) was catastrophic because it needed nothing from the victim beyond logging a string. Any attacker-controlled value that reached a log call triggered a JNDI lookup, fetching remote code. The attack surface was on by default in effectively every application using Log4j, and it was wormable at internet scale.

To reach the deserialization sink, an application must deliberately stand up a service that reads serialised LogEvent objects through FilteredObjectInputStream, expose it to untrusted input, and carry exploitable gadget classes on its classpath. 

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.

What Happened to the Report

Cyber Kendra verified the following directly against the live issue page:

No Apache maintainer replied on #4255 itself — it carries no comments and still holds its waiting-for-maintainer label — so the withdrawal came from the reporting side, not the project. The likeliest reading is straightforward: the report re-raised, as a "critical" zero-day, a behaviour the project had already triaged in the open as expected and non-critical. 

Confronted with #4168, the "storm the internet" framing no longer holds, and an advisory built on it has little left to stand on. Why the account was deleted rather than simply corrected, we cannot say, and we are not going to guess. 

There is history around Log4j disclosure — in December 2021, China's industry ministry suspended a partnership with Alibaba Cloud for reporting Log4Shell to Apache before notifying the government — but that concerned a different flaw, and nothing links it to this withdrawal. The verification above stands on Apache's own source and does not depend on the report or the account continuing to exist.

Has Apache Patched It?

There is nothing to patch in terms of the vulnerability, and no CVE or advisory has been issued. Apache's public position, via discussion #4168, is that the allowlist is defence-in-depth and its gaps are hardening work, not exposures. 

The maintainer's list does propose tightening — removing MarshalledObject from the allowlist is the obvious candidate. The three Log4j CVEs published earlier in 2026 (CVE-2026-34477 TLS hostname bypass, CVE-2026-34478 log injection, CVE-2026-34480 XML log loss) are unrelated.

How to Reduce Your Exposure

• Do not deserialize untrusted data, and do not expose services that accept serialized LogEvent objects to networks you do not control.
• If a serialized-log receiver is unavoidable, apply a JVM-wide serialization filter (jdk.serialFilter, JEP 290). The Log4j allowlist does not propagate into MarshalledObject.get(), so a process-wide filter is the layer that actually covers the nested bytes.
• Trim unused libraries that provide deserialization gadgets from the classpath.
• Keep Log4j current and watch logging.apache.org for any allowlist change.

Updates

2026-08-26: Issue #4255 has been renamed to "Something wrong Happen", its body deleted, and the issue closed; the reporting account now shows as ghost. Cyber Kendra has confirmed the underlying code paths in Log4j 2.26.1 and located maintainer discussion #4168 (1 July), which documents the same behaviour as a hardening measure, not a vulnerability. No CVE or patch has been issued. We have contacted Apache's security team and will update this article with any response.