Do Son 
Update 3:
Piotr Karwasz, a member of the Apache Software Foundation, stated that this alert re-covers an old, known Java issue. Specifically, feeding unsafe data to Java streams can let hackers run bad code.
Too many Apache alerts in your inbox? Switch to one weekly digest, sorted by severity.
Try Team free for 14 daysThe team noted that their tool helps shield code but does not set a hard trust line. Furthermore, the Apache group already knew of this flaw and welcomes user code fixes. Consequently, the team will not file a CVE or keep the report secret. Ultimately, the news grew only because staff nearly deleted the post before review.
Update 2:
Currently, this issue is closed for discussion on Apache’s tracker and is limited to collaborators only.
Update 1: Working Exploit Now Public
The risk from this Log4j vulnerability has grown sharply. Since the original disclosure, a complete, working exploit has been published openly. It shows unauthenticated remote code execution against services that receive serialized log events. As a result, the barrier to attack is now much lower.
The published material confirms the flaw is practical, not just theoretical. Therefore admins should treat this as urgent. We are not linking to or detailing the exploit code. Instead, apply the workaround below and restrict exposure immediately.
The Apache Log4j maintainers still have not commented. No patched release exists yet, and no CVE has been assigned. We will update this article as the project responds.
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 vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
Small correction: nobody from the Log4j project deleted the issue. The reporter did, along with their own GitHub account. For context, we received over 120 security reports in Q1 alone and they resulted in only 8 low-medium vulnerabilities (https://logging.apache.org/security.html). We don’t panic: we brew a good cup of coffee and deal with them. 😉
Your article have taught us the importance of keeping the public informed of every new security report, valid or not. Going forward you’ll find them all on our users mailing list:
https://lists.apache.org/list.html?log4j-user@logging.apache.org