Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
Following the re-evaluation of CVE-2021-45046, security guidance changed to recommend upgrading to Log4j 2.16.0, which disables JNDI lookups by default, or removing the JndiLookup class from affected earlier releases. This marked the effective replacement of 2.15.0 as the recommended remediation.
By December 17, 2021, new information showed that the issue tracked as CVE-2021-45046 had been underestimated as a low-severity denial-of-service flaw and could still permit arbitrary code execution in Log4j 2.15.0 under certain conditions. Reports noted the localhost-only JNDI restriction in 2.15.0 could be bypassed with a crafted LDAP URI.
Praetorian published research showing that Log4j 2.15.0 remained vulnerable to sensitive data exfiltration in some scenarios despite prior mitigations. This indicated that the initial fix for Log4Shell was incomplete.
Apache tracked a security hardening change in JIRA to disable JNDI by default after the fallout from CVE-2021-44228. The change was planned for Log4j 2.16.0, with JNDI requiring explicit opt-in via a JVM flag or environment variable.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
5 references tracked. Mallory keeps watching after this page renders.
snyk.io
Open sourcepraetorian.com
Open sourceblog.cloudflare.com
Open sourcesecurity.snyk.io
Open sourceissues.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 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 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 16, 2026
The Apache Software Foundation released security updates for **Apache CXF** to fix three newly disclosed vulnerabilities affecting enterprise deployments of the services framework. The flaws include **`CVE-2026-44930`**, an LDAP injection issue in the XKMS LDAP certificate repository that can let attackers manipulate backend search filters and retrieve arbitrary digital certificates, potentially enabling impersonation, interception of encrypted communications, and lateral movement. Apache also addressed an **XXE** flaw in WS-Transfer caused by insecure XML parser configuration, which could expose sensitive files and support internal network mapping, as well as a possible **remote code execution** condition tied to an incomplete fix for an older JMS-related bug. Affected releases include **4.2.0**, **4.0.0 through 4.1.5**, and older branches before **3.6.11**. Apache published patched versions **4.2.1**, **4.1.6**, and **3.6.11**, and guidance urges organizations to upgrade immediately, review LDAP access controls, monitor certificate access activity, and reduce exposure of XKMS components where possible. The disclosures indicate that while the LDAP flaw does not itself provide code execution, the combined set of weaknesses could materially affect trust infrastructure and server security in vulnerable environments.
Jun 29, 2026