Loading story…
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.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
Tenable published Nessus plugin 341265 to identify missing Unity Linux updates for wildfly-security-manager associated with Log4Shell. The local check relies on self-reported installed package versions rather than actively testing exploitability.
Unity Linux published advisory UTSA-2026-031619, providing a security update for wildfly-security-manager that addresses CVE-2021-44228 on affected Unity Linux releases.
CVE-2021-44228, known as Log4Shell, was published as a critical Apache Log4j2 log4j-core JNDI injection vulnerability that can allow remote code execution when attackers control logged data and message lookup substitution is enabled.
Apache Log4j 2.15.0 disabled the affected behavior by default, while versions 2.16.0, 2.12.2, 2.12.3, and 2.3.1 completely removed the affected functionality.
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.
3 references tracked. Mallory keeps watching after this page renders.
Map 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 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.
Aug 26, 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