Loading story…
Apache Log4j remained at the center of a major software supply chain security crisis after Log4Shell (CVE-2021-44228) exposed Java applications to remote code execution through crafted requests that could force vulnerable systems to retrieve and run attacker-controlled payloads. The flaw affected Log4j 2.0-beta9 through 2.14.1, was reported as easy to exploit, and was observed in widespread attacks across enterprise networks, prompting urgent calls to identify exposed assets and apply vendor fixes or mitigations.
Remediation proved more complex as Apache issued updates and additional Log4j vulnerabilities emerged, including CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832, raising concerns that patching alone would not address prior compromise or attacker persistence. Organizations were pushed to combine software updates with threat hunting and incident response, while defenders also relied on community tracking of affected products through resources such as CISA's log4j-affected-db, which has since been archived as read-only.
See which actors are running it and whether you're in range.
6 events from the most recent confirmed update back to the earliest known activity.
The cisagov/log4j-affected-db GitHub repository was archived and made read-only, ending active updates to the community-sourced list of Log4j-affected software.
After the Log4j 2.15.0 release, subsequent vulnerabilities CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832 were introduced or revealed, showing the initial remediation was incomplete.
By December 13, reporting described CVE-2021-44228 as a critical zero-day affecting Log4j 2.0-beta9 through 2.14.1 and said it was being actively exploited against vulnerable systems at scale. The same reporting cited Check Point Software's observation of exploit attempts on more than 31.5% of corporate networks globally.
Apache released Log4j version 2.15.0 on December 10 to fix the remote code execution vulnerability CVE-2021-44228 (Log4Shell).
Apache received a private report of the Log4Shell remote code execution vulnerability, CVE-2021-44228, before public disclosure and patch release. This marks the earliest explicitly dated event in the reference's account of the vulnerability timeline.
Elastic Security documented detection and hunting logic for Log4Shell exploitation, including suspicious Java connections to LDAP, RMI, and DNS services; Java-spawned shells or download tools; malicious executable creation; reverse-shell behavior; and cryptomining indicators. It also provided mitigation guidance such as upgrading Log4j, disabling message lookups where supported, and restricting outbound connectivity from vulnerable hosts.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
Correlate live exploitation activity against the software you actually run, and see where you're exposed.
12 references tracked. Mallory keeps watching after this page renders.
semgrep.dev
Open sourcelogging.apache.org
Open sourcecve.mitre.org
Open sourceelastic.co
Open sourcemitiga.io
Open sourcegithub.com
Open sourceblackhat.com
Open sourcecve.mitre.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 remote code execution flaw in Apache Log4j, tracked as **`CVE-2021-44228`** and widely known as **Log4Shell**, exposed a vast range of Java applications and services to unauthenticated compromise through the library’s JNDI lookup feature. Security reporting said the bug affected Log4j versions **`2.0-beta9` through `2.14.1`**, with early warnings surfacing through attacks against Minecraft servers before researchers and vendors confirmed broader exposure across enterprise software, cloud services, and Apache frameworks including Struts2, Solr, Druid, Flink, and Kafka. Researchers also warned that exploitation could lead not only to remote code execution but also to leakage of sensitive environment data such as cloud credentials and developer secrets. Exploit code was released publicly and was quickly followed by heavy Internet-wide scanning and attack activity, including targeting of **VMware vCenter Server**, where VMware confirmed exploitation attempts in the wild and urged immediate mitigation. **CISA** described the flaw as one of the most serious vulnerabilities in recent memory and warned that **hundreds of millions of devices** could be affected, with likely follow-on abuse by cryptominers, ransomware operators, and other threat actors. Apache responded with a series of Log4j updates, including releases such as **`2.12.2`**, **`2.12.3`**, **`2.12.4`**, and **`2.3.1`**, while defenders published detection content and scanning tools as organizations raced to identify vulnerable systems and reduce exposure.
Aug 28, 2026
Apache Log4j 2’s JNDI lookup feature enabled the critical **Log4Shell** remote-code-execution vulnerability, tracked as `CVE-2021-44228`. An attacker could cause a vulnerable application to log a crafted string that triggers a lookup to an attacker-controlled LDAP or other JNDI service, potentially leading to arbitrary code execution under the application’s privileges. The issue affected Log4j 2 versions from `2.0-beta9` through `2.14.1` and created broad exposure because Log4j is widely embedded in Java software and services. Organizations should identify direct and transitive Log4j dependencies, upgrade to a supported remediated release appropriate to their Java runtime, and verify that deployed artifacts—not only build manifests—no longer contain vulnerable `log4j-core` versions. **SLF4J itself is not vulnerable**: it is a logging facade and does not perform Log4j’s JNDI message lookups, though applications using SLF4J can remain exposed when their selected logging backend is vulnerable Log4j 2. Internet-facing Java services and vendor-supplied products should be prioritized for patching, monitoring, and vendor confirmation.
Aug 28, 2026
The Dutch National Cyber Security Centre (NCSC) issued a **HIGH/HIGH** warning for the Apache Log4j/Log4Shell flaws, led by remote-code-execution vulnerabilities including `CVE-2021-44228` and `CVE-2021-45046`. Applications that log attacker-controlled input can allow remote execution with web-server privileges, creating a material risk of major disruption and ransomware. Public exploit techniques, Log4j’s deep presence in third-party products, and incomplete asset visibility made vulnerable deployments difficult to identify; the NCSC reported limited active abuse but expected continued scanning and targeted attacks. Organizations were urged to inventory direct and supply-chain use of Log4j 2, promptly apply vendor patches, and isolate, mitigate, or disable unpatchable internet-facing systems that process untrusted input. The NCSC advised prioritizing versions affected by the earlier RCE flaws—`2.0-beta9` through `2.12.1` and `2.13.0` through `2.15.0`—and updating from `2.15` to `2.16` and subsequently to current Apache releases, including `2.17.0` where applicable for later issues such as `CVE-2021-45105`. It also called for log review and threat hunting from at least 1 December, forensic preservation, tested offline backups, segmentation, restricted outbound access, and use of its GitHub repository for affected-product tracking, indicators, detection rules, scanning, and mitigation guidance.
Sep 3, 2026