On August 24, 2026 a researcher posting as U-Sec opened issue #4255 on the Apache Logging Services repository, describing a way to defeat Log4j’s allowlist-based deserialization filter. By August 26 the issue had been retitled “Something wrong Happen,” its body deleted, and the thread closed. The account that filed it no longer exists; GitHub now attributes the issue to “ghost.”
That is what changed this week, and it changed on the 26th. What did not change is the surrounding material: public reproduction labs and exploit repositories built against the report are still up, downstream vendors are fielding customer questions about it, and no CVE has been assigned. The Log4j maintainers’ position, published on the project’s own security page well before any of this, is that the filter in question was never a security boundary and that defeating it is not a vulnerability in Log4j. Both of those things are true at once, and the vulnerability record has no way to say so.
What happened
The reported technique concerns FilteredObjectInputStream, a utility Log4j ships in log4j-api to help applications that deserialize log event streams. The report’s claim, as reproduced in third-party write-ups and in a public lab, is that the filter’s allowlist includes java.rmi.MarshalledObject, and that a MarshalledObject carries its payload as opaque bytes the class-name filter cannot see. When the object is unwrapped, MarshalledObject.get() constructs a plain, unfiltered ObjectInputStream over those bytes. Anything the filter was meant to exclude then deserializes normally.
As of this writing the issue page at github.com/apache/logging-log4j2/issues/4255 loads, shows the title “Something wrong Happen,” the state Closed, the author “ghost,” the label waiting-for-maintainer, and the text “No description provided.” The technical description is not retrievable from it.
The maintainers’ view is on the record, though not on that page. The Apache Logging Services security page states the project’s position on deserialization plainly, and it is worth quoting in full because it is the primary document that governs this dispute:
“We provide no guarantee that deserializing a stream containing classes from these projects is safe, regardless of the source of the stream.”
“Filtering such a stream by the
org.apache.loggingJava package, thelog4net.NET namespace, or any allowlist derived from project-owned types is not sufficient to make deserialization safe.”“The hardening utilities we ship are partial and not exhaustive; bypasses are treated as opportunities for further hardening, not as vulnerabilities in the project.”
“The application performing the deserialization is responsible for ensuring that the byte stream originates from a trusted source.”
The same page notes that Log4j does not deserialize data as part of normal operation, and that FilteredObjectInputStream exists to assist applications that choose to do so anyway.
Reporting by Cyber Kendra and SecurityWeek, both dated August 28, attributes to Log4j maintainer Piotr Karwasz a response in the issue thread describing the submission as an independent discovery of a known security non-finding, restating that the filter “is a hardening measure and never was a trust boundary,” and saying there was “no CVE, no embargo, nothing here that needs to be kept confidential.” We could not verify those words against the issue page, because the thread’s contents are gone. The Apache security page above says the same thing in the project’s own published voice, and that is the version we rely on.
What is independently checkable is the exploitation surface. A public Docker lab, dinosn/log4j-4255, reproduces the technique end to end against official Log4j 2.26.1 artifacts on JDK 17, verifying jar checksums against Maven Central. Its README is candid about what the attack needs: “an app that exposes an unauthenticated FOIS-based serialized-LogEvent receiver and has a usable gadget version on its classpath,” and it is explicit that the outcome is gadget-dependent—commons-collections 3.2.1 yields code execution, 3.2.2 blocks it. A second repository publishes an exploit. Elastic users have opened a public thread asking whether Elastic products are affected.
Why it matters
Strip out the drama and this is a records problem, and a familiar one: the vulnerability database has exactly two states for a thing, and this thing is in a third.
The project’s position is coherent. A filter documented as partial, non-exhaustive, and explicitly not a trust boundary cannot be “bypassed” in the security sense, any more than a spam folder can be bypassed. If you deserialize untrusted bytes, you have already lost, and Log4j says so in writing. Under that reading there is no Log4j vulnerability, no affected version range, and nothing for a CVE to describe. The maintainers, who are volunteers, have said as much before—in discussion #4168 on July 1, per Cyber Kendra.
The operator’s position is also coherent, and it is not the same position. Some applications wired FilteredObjectInputStream into a network-facing receiver precisely because it looked like a boundary, following patterns from Log4j’s own samples. For those applications, the reported technique is a live unauthenticated remote code execution path, and it does not become less live because the library documented itself out of responsibility. Nobody disputes the mechanism. Apache does not dispute it; the maintainers’ answer is that it is not theirs to own.
Between those two coherent positions falls everything that makes vulnerability management work. There is no CVE, so no scanner rule fires. There is no affected-version range, so no SBOM query resolves. There is no advisory, so no vendor has a document to link when a customer asks. There is no fix, so no patch level tells you where you stand. And the original technical report—the document that would let an engineer decide in ten minutes whether their receiver is one of the exposed ones—has been deleted from the authoritative location and survives only in third-party reproductions and a lab someone built from it. The most reliable description of the attack is now a Docker container maintained by a stranger.
This is the same shape as several stories this site has covered in the last week, and the pattern is worth naming. When the authoritative record is unreadable—a directive whose deadline table ships as a screenshot, a vendor advisory that contradicts its own severity, an exploited flag retracted a day after it was set—the market fills the gap with transcriptions and reconstructions, and those disagree with each other. Here the gap-filling has already produced “Log4Shell 2.0” framing in at least one write-up, which is wrong on scale by a wide margin. Log4Shell was default-on, triggered by logging a string. This needs an application to deliberately stand up a serialized-LogEvent receiver, expose it to untrusted input, and carry a vulnerable gadget library. That is a narrow, opt-in configuration. Narrow is not zero, and the honest description is neither “Log4Shell 2.0” nor “nothing here.”
The deleted account is the part that should bother people who care about how disclosure works. Whatever prompted it, the practical result is that a researcher who reported a working technique through the front door left, and the technique stayed. Reports do not become less true when their authors withdraw. They become harder to check.
What to do
Do not wait for a CVE, because on the project’s stated position there will not be one.
Search your own code and your dependencies for FilteredObjectInputStream, for ObjectInputStreamLogEventBridge, and for any service that accepts serialized LogEvent objects over a socket. If you find none—which is the likely outcome for most estates—you are done, and you can say so to whoever forwarded you the “new Log4Shell” headline.
If you find one, treat it as an unauthenticated remote code execution exposure today. Take it off any untrusted network path, put authentication and network restriction in front of it, and check the classpath for commons-collections 3.2.1 and other well-known gadget libraries; upgrading commons-collections to 3.2.2 or later closes the specific chain the public lab uses, without closing the class of attack. The durable fix is to stop deserializing untrusted Java objects in a log path at all—move to a text or structured wire format—or, if the receiver must stay, to apply a JEP 290 ObjectInputFilter configured for your own allowlist rather than relying on Log4j’s. Apache’s security page is unambiguous that this responsibility is yours.
If you sell software, publish a position now. Customers are already asking in public forums, and “there is no CVE” is not an answer to “does your product expose a FOIS receiver.”
Sourcing note
Primary sources: the Apache Logging Services security page at logging.apache.org/security.html, quoted verbatim above for the project’s deserialization position; and the live state of github.com/apache/logging-log4j2/issues/4255, which we fetched directly and which currently shows the title “Something wrong Happen,” state Closed, author “ghost,” label waiting-for-maintainer, and no description. The README of the public reproduction lab dinosn/log4j-4255 is quoted for the exploitation prerequisites and the gadget dependency.
Could not reach: the original text of issue #4255, which has been deleted; and the GitHub API, which returned 403 to unauthenticated retrieval, so we could not enumerate the thread’s comments or their timestamps. The maintainer statements—“known security non-finding,” the trust-boundary line, and “no CVE, no embargo”—are reported by Cyber Kendra and SecurityWeek (both August 28, 2026) and are attributed to them here, not confirmed by us. The July 1 date for discussion #4168 comes from the same reporting and is unverified. We did not confirm from an Apache changelog which release removed the socket server from log4j-core, so no version claim is made about it.
Unresolved: who deleted the issue body and why; whether the account deletion was voluntary; whether any Apache Logging release will change the allowlist; and how many real deployments expose a FOIS-based receiver, a number nobody has published and which we do not estimate.