Log4Shell 2.0? A New Log4j RCE Appeared, Disappeared - and AI Had Already Found It

Apache says it isn’t a vulnerability. A researcher demonstrated RCE. Then the GitHub report vanished. We reproduced it anyway - and Raven blocked it without a CVE.

On August 24, 2026, a new issue appeared in the Apache Log4j repository. It was numbered #4255, and the original report made the kind of claim that immediately gets the security community’s attention: a deserialization bypass affecting Log4j 2 that could, under the right application conditions, be turned into remote code execution.

Any combination of the words Log4j and RCE is enough to bring back memories of Log4Shell. But this story quickly became much stranger than a normal vulnerability disclosure.

Within two days, the original description of the issue had disappeared. The title had been changed to the oddly cryptic “Something wrong Happen.” The issue was closed. The reporter’s account was gone, replaced by GitHub’s ghost placeholder. What remains today is essentially the shell of the original report: a closed issue, no description, and almost no explanation of what happened.

Was the report wrong? Was the severity overstated? Did the researcher withdraw it after discussing the threat model with Apache? We don’t know, and it would be irresponsible to invent an explanation. But the underlying technical behavior did not disappear with the GitHub post. In fact, the deeper we looked, the more interesting the story became.

The bypass is real. The argument is about what it means.

At the center of #4255 is a Java deserialization behavior involving Log4j’s FilteredObjectInputStream and java.rmi.MarshalledObject.

Log4j contains filtering mechanisms designed to restrict which classes can be reconstructed when serialized objects are read. One of the classes permitted by that allowlist is MarshalledObject. The problem is that a MarshalledObject can itself contain another serialized object, and when .get() is called, that embedded object is deserialized using another object stream.

That second deserialization does not necessarily inherit Log4j’s original per-stream filter. Put more simply: the outer container passes the security check, but the object hidden inside it can later be deserialized outside that check.

This is not speculation. Apache’s own maintainers documented the behavior publicly and describe Log4jLogEvent.LogEventProxy → MarshalledObject.get() as an allowlist escape. Their analysis explains that, without a JVM-wide serialization filter, the nested bytes can be deserialized outside Log4j’s per-stream protection.

Independent researchers have also built a reproducible lab against Log4j 2.26.1 demonstrating that the path can be combined with an available deserialization gadget and driven through to code execution.

So why isn’t everyone calling this another Log4Shell? Because Apache makes an important distinction.

Log4j does not deserialize attacker-controlled network data during normal logging. The old receivers that historically exposed serialized log-event streams are no longer part of current Log4j 2. In order to make #4255 exploitable, an application must already contain a path where serialized Log4j objects influenced by an attacker are being deserialized.

Apache therefore does not consider FilteredObjectInputStream a security boundary. Its threat model treats this filtering as a defense-in-depth mechanism and classifies bypasses as hardening opportunities rather than Log4j vulnerabilities.

As of this writing, there is no CVE assigned to #4255 and no Apache advisory declaring a new Log4j RCE. The bypass is reproducible, but its exploitability is application-dependent and Apache does not classify it as a Log4j vulnerability.

That debate is legitimate. But it is not actually the most important part of this story.

AI found it first

The most remarkable detail happened almost two months before issue #4255 was opened.

On July 1, Apache Log4j maintainer Piotr Karwasz published a discussion titled “Log4j 2.x deserialization hardening.” The post contained a list of findings discovered by an LLM while auditing the Log4j codebase.

The tool was Claude Code. The model was Claude Opus 4.8 with a one-million-token context window.

The prompt, according to the maintainer, was roughly to audit every serializable class in the repository for deserialization gadget surfaces reachable through Log4j’s filtering mechanisms. And the number-one finding, ranked High for hardening priority, was: Log4jLogEvent.LogEventProxy — MarshalledObject.get() deserializes with no filter (allow-list escape).

That should sound familiar. It is essentially the same primitive that would become the center of #4255 seven weeks later.

The AI was not looking up a CVE. There was no CVE to look up. It was not matching a known vulnerability signature or reading an advisory. It was reading source code, following control flow across classes, reasoning about how Java serialization behaves, recognizing where an assumed security control stopped applying, and identifying the resulting gadget surface.

Apache explicitly wrote that these findings were not considered security issues under its threat model. That distinction should be preserved. But it does not change what happened: an AI coding model inspected a major open-source project and independently surfaced a security-relevant primitive before a human researcher later attracted attention by presenting the same underlying behavior as an RCE.

That is the part of #4255 that we think matters far beyond Log4j.

Then the report appeared. And disappeared.

Seven weeks after the AI-assisted Apache analysis, issue #4255 appeared publicly and presented the behavior in much stronger terms. Then the report effectively vanished.

Today, GitHub shows the issue as closed, its author as ghost, and the description as empty. The title is now simply “Something wrong Happen”

We do not know why. Perhaps the researcher reconsidered the severity. Perhaps Apache’s previously published threat model changed the framing. Perhaps something completely unrelated happened. The responsible position is simply to say that the public report disappeared while the technical behavior remained reproducible.

There is something almost symbolic about that sequence. First, an AI finds an unusual code path during a source-code audit. The maintainers document it publicly but classify it as hardening rather than a vulnerability. Weeks later, a security researcher independently reaches the same area of the code and frames it as RCE. Then that report disappears.

Meanwhile, the code itself never cared what anyone called it. And neither did the exploit.

So Raven’s research team reproduced it

When our team saw the report, we did not create a signature for #4255. We did not add a temporary CVE mapping. There was no CVE to add. Instead, we started from the behavior itself.

We first validated the filtering bypass against a current Log4j version in a controlled environment. Our control test confirmed that the Log4j filter rejected a disallowed object at the outer level. We then placed the same behavior inside the relevant serialized LogEvent path and confirmed that the nested deserialization occurred beyond that filter.

The next question was more important: could we reproduce an actual code-execution path and see what Raven would do?

We built an isolated test application with the conditions required to exercise the technique and drove the deserialization path through an available gadget chain.

‍The execution eventually attempted to create a new process!
Raven blocked it.

The sensor recorded the prevention event at runtime. No #4255 rule existed. No CVE was associated with the behavior. Raven was not waiting for an NVD update or an Apache advisory. It stopped what the exploit attempted to do.

That distinction is the entire point.

This wasn’t “Raven knows about Log4j”

Security products are very good at telling compelling stories after a vulnerability becomes famous. A CVE is published, threat intelligence is updated, a signature is created, and suddenly every vendor can show a dashboard saying it detects the vulnerability.

That is useful, but it is fundamentally different from what happened here.

At the time of our test, there was no recognized #4255 CVE. Internally, our team explicitly decided not to create a CVE mapping for it because Apache had not classified the behavior as a vulnerability.

Raven’s prevention therefore did not depend on recognizing the name of the exploit. It depended on understanding what code was doing at runtime and enforcing what that code should be allowed to do.

That is a much more important security property than another green checkmark next to Log4j.

The world’s source code is becoming searchable by machines

For decades, open-source software has had an unusual form of economic protection. The code was public, but deeply understanding it was expensive.

A security researcher could download millions of lines of source code, but finding a subtle vulnerability still required specialized knowledge, time, patience and often a lot of manual exploration. Multiply that effort across thousands of libraries and frameworks, and the economics quickly became prohibitive.

AI changes those economics.

A sufficiently capable model can consume enormous repositories, identify every implementation of a particular interface, trace callers and callees across hundreds of files, compare security assumptions between components, inspect previous patches and commits, generate hypotheses and keep following them. And it can do this continuously.

The Apache discussion around #4255 is a small but unusually clean demonstration of that change. An LLM was pointed at a large, mature and heavily scrutinized open-source project and asked to reason about a particular security surface. It found something worth investigating.

That does not mean every AI finding is a vulnerability. Far from it. Models will produce false positives, misunderstand threat models and overstate impact. Human validation remains essential.

But the direction is obvious: the cost of looking for vulnerabilities in public source code is collapsing. Attackers get that benefit too.

Your dependency tree is now an AI research target

Modern enterprise applications contain extraordinary amounts of code their developers did not write: logging frameworks, parsers, database drivers, serialization libraries, web frameworks, authentication packages, compression libraries, image processors and thousands of transitive dependencies.

Much of that code is public. That was already true during Log4Shell. What has changed is who - or what - can analyze it.

A model does not need to sleep. It does not need to understand an entire project before beginning. It can be given a narrowly scoped objective such as “find paths where attacker-controlled data escapes this filter” and inspect thousands of candidate functions.

Today’s models are already capable of meaningful security reasoning. Tomorrow’s will be better. And the models that arrive six or twelve months from now will be analyzing exactly the same source code that is running inside enterprise production environments today.

That creates an uncomfortable asymmetry. Most defensive infrastructure is still designed around vulnerabilities becoming known before organizations need to defend against them.

The CVE pipeline is becoming the slow path

Traditional vulnerability management follows a familiar lifecycle. Someone discovers a vulnerability. It gets reported. The vendor investigates. A CVE is assigned. An advisory is released. Security vendors ingest it. Scanners identify affected systems. Organizations prioritize remediation and eventually deploy a patch.

There is nothing wrong with that system. We still need it. But an exploit is not required to wait for any of those steps.

It does not need a CVE number. It does not care whether NVD has scored it. It does not care whether the library maintainer and the researcher agree on whether the vulnerable security boundary belongs to the library or the application.

If the code path exists in a real production environment and an attacker can reach it, the CPU will execute it.

AI compresses the time between “this code contains an exploitable behavior” and “someone has figured out how to use it.” That means defenders need a control that exists outside the CVE lifecycle.

This is why runtime becomes the last line of truth

The premise behind Raven is straightforward: when prior knowledge becomes less reliable, the runtime itself becomes the source of truth.

Instead of only asking whether a server contains a library associated with a known vulnerability, we can ask what that library is actually doing. Which code path led to a sensitive operation? Which library initiated it? Is that behavior normal for that code? Should that code be allowed to execute a process, access a file, open a network connection or invoke another sensitive capability?

Those questions remain valid whether the exploit was disclosed five years ago, five minutes ago, or has never received a CVE at all.

That is why #4255 is such an interesting case study. It is messy. Apache says the behavior is outside the vulnerability boundary it promises to protect. A researcher framed it as RCE. The public issue was subsequently scrubbed and closed. An AI model had already found the primitive weeks earlier. There was no CVE for Raven to consume.

And when we reproduced the execution path in our lab, Raven stopped it anyway.

The exploit doesn’t care what we call it

We do not think #4255 is “the next Log4Shell.” Based on the conditions currently understood, making that claim would be misleading.

But in some ways, the lesson is more important than another critical CVE. The story shows what vulnerability research is starting to look like in the AI era. The world’s most important software libraries are publicly available. Models are becoming capable of reading and reasoning about those codebases at enormous scale. Security-relevant behaviors can be discovered before a CVE exists — and sometimes before anyone even agrees that they deserve one.

The security industry should assume that this gap will continue to shrink. The next exploit may arrive before the advisory. It may arrive before the patch. It may arrive before the CVE.

Raven was built for that gap.

Stop the exploit before it has a name. See Raven in action.

‍

Sources

• Apache Log4j issue #4255 — https://github.com/apache/logging-log4j2/issues/4255
• Apache Log4j 2.x deserialization hardening discussion #4168 — https://github.com/apache/logging-log4j2/discussions/4168
• Apache Log4j Security FAQ — https://logging.apache.org/log4j/2.x/security.html
• Public reproduction repository — https://github.com/dinosn/log4j-4255