Security Intelligence
Loading table of contents...
At a glance:
-
Researchers published proof-of-concept (POC) code demonstrating code execution against applications that deserialize serialized Apache Log4j 2 LogEvent objects received from remote systems.
-
The research applies to a specific application architecture rather than all Log4j 2 deployments. Exposure is limited to applications that receive serialized LogEvent data from other systems and deserialize that data into Java objects.
-
Apache Log4j maintainers reviewed the report, closed the associated project issue, and characterized the reported behavior as a consequence of accepting untrusted serialized Java objects rather than a vulnerability affecting all Log4j 2 deployments.
Threat summary
On August 24, 2026, a security researcher disclosed findings related to how Apache Log4j 2 handles serialized LogEvent objects, reporting the issue to the Apache Log4j project as issue #4255.
The researcher identified log4j-api versions 2.11.0 through 2.26.1 and log4j-core versions 2.8.0 through 2.26.1 as affected. They characterized the finding as a pre-authentication code execution issue and drew comparisons to previous high-profile Log4j vulnerabilities, attracting significant attention across the security community. Other researchers subsequently published independent POC implementations demonstrating the same behavior.
Apache reviewed the report and closed the issue. Maintainer comments challenged its classification as a Log4j vulnerability, indicating that the behavior stems from accepting untrusted serialized Java objects rather than a flaw affecting all Log4j 2 deployments.
Scope of the issue
The research focuses on a specific deployment model, not typical Log4j 2 usage. Most organizations use Log4j 2 to generate and forward log messages. Common logging workflows (writing logs to files, sending Syslog messages, forwarding data to SIEM platforms, or storing logs in databases) generally process log data as text and do not deserialize Log4j LogEvent objects. As a result, those deployments are outside the scope of the research.
The reported issue involves applications that receive serialized Log4j LogEvent data from other systems and reconstruct that data into Java objects. Because processing untrusted Java objects has long been associated with security risks, Log4j 2 introduced FilteredObjectInputStream (FOIS) in version 2.8.2 in 2017 as a security control intended to restrict which classes can be deserialized when processing serialized LogEvent objects.
How the bypass works
According to the researchers, the POC demonstrates a way to bypass those restrictions under specific conditions.
A Java Remote Method Invocation (RMI) MarshalledObject can be used to hide a payload inside a permitted object. FOIS validates the outer object and allows it to pass because it's on the allowed list. When the application later processes the contents of that object, the hidden payload is deserialized and code execution can occur.
If the affected application has access to sensitive data, credentials, or connected business systems, successful exploitation could allow an adversary to access those resources using the permissions available to the application.
Analysis
The research has received mixed responses from the security community because it sits between a new exploitation technique and a long-established security concern: the risks of deserializing untrusted Java objects have been recognized for many years. The contribution of the research is a technique that researchers claim bypasses protections provided by FOIS.
The issue is best understood as an architectural exposure rather than a vulnerability affecting all Log4j 2 deployments. The research is most relevant to organizations running internet-accessible Java applications that accept and deserialize serialized Log4j LogEvent objects from remote systems, particularly where those applications have access to sensitive data, credentials, or connected business systems. Most organizations using Log4j 2 for routine application logging are outside the scope of the research.
The POC demonstrates that code execution can occur when this workflow is present. For that reason, the research warrants review of the applications in the environment that receive and deserialize serialized Log4j LogEvent objects from remote systems. Organizations that identify this functionality should review network exposure and access controls for those applications.
Mitigations
The disclosure does not introduce significant new defensive requirements. Restricting access to services from trusted networks, limiting internet exposure of administrative and backend systems, monitoring applications for suspicious activity, reviewing unnecessary functionality, and following vendor security advisories are established security practices that apply across a broad range of enterprise technologies.
The primary action associated with this research is identifying applications that receive and deserialize serialized Log4j LogEvent data from remote systems and determining whether that functionality is accessible from untrusted networks.
Priority review is advised for internet-facing Java services, centralized logging platforms, and custom applications that exchange serialized Java objects. Where serialized LogEvent functionality is present, organizations are advised to confirm network exposure, limit access to trusted systems, and monitor Apache Log4j communications for any additional guidance related to the research.
Stay on top of emerging threats like this.
Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities.
