Public Disclosure: Unpatched Log4j RCE Flaw in FilteredObjectInputStream, No CVE Assigned
Do Son 
TL;DR
Researchers publicly disclosed an unpatched Log4j vulnerability on August 24, 2026. The flaw allows remote code execution through unfiltered Java deserialization. No CVE is assigned yet, and no fix exists. A configuration workaround is available now.
Why This Log4j Vulnerability Matters
Log4j sits inside countless Java applications and services. Any new remote code execution path here draws immediate attention. Memories of Log4Shell in 2021 make this Log4j vulnerability especially sensitive.
The report appeared openly on Apache’s public issue tracker. As a result, the technical details are already in the wild. Maintainers have not yet responded, and the issue remains labeled for triage.
Disclosure and PoC Status
The write-up is public, but the full exploit code is not. The reporter states the complete proof-of-concept sources are available to maintainers on request and will be published after a fix is released.
So working exploit code has not been released. No exploitation in the wild has been confirmed either.
How the Attack Works
The flaw sits in Log4j’s FilteredObjectInputStream, or FOIS. Its allowlist permits java.rmi.MarshalledObject. That object hides its payload as a raw byte array, which the filter never inspects.
Log4j then unwraps the payload itself. A serialized LogEventProxy calls the marshalled object’s get method during deserialization. Consequently, the inner data is deserialized with no filtering. The reporter notes the payload does not need to pass the allowlist.
A single crafted message sent to a FOIS-based log receiver can trigger code execution.
Affected Versions
The report lists log4j-api 2.11.0 through 2.26.1 and log4j-core 2.8.0 through 2.26.1. The findings were verified against official 2.26.1 artifacts. The issue is platform-independent and affects all tested JDK versions.
Mitigation Steps
No patched release exists yet. Until one ships, apply the reporter’s workaround by setting a serial filter that blocks the risky class. You can track the vendor response in the public Log4j issue on Apache’s tracker. Also restrict network access to any service that accepts serialized log events.
We will update this article when more information about the vulnerability becomes available.
Support Our Threat Intelligence
Find our zero-day alerts and CVE reports helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
PayPal
