Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
16 events from the most recent confirmed update back to the earliest known activity.
By 2022-02-12, Neo23x0 had published log4shell-detector on GitHub, a tool for detecting Log4Shell exploitation attempts. The release added another public defensive utility aimed at helping responders identify signs of compromise related to Log4j attacks.
By late December 2021, Apache released additional Log4j updates including versions 2.12.4 and 2.3.1 for supported branches. These releases represented continued hardening and cleanup after the initial Log4Shell emergency and related vulnerabilities.
Apache published Log4j 2.12.3 as an additional update after the initial emergency fixes, reflecting continued remediation for newly identified issues related to the Log4Shell response. This showed that patching guidance was evolving rapidly as researchers analyzed the flaw further.
On 2021-12-24, Fox-IT published a GitHub repository containing Log4Shell packet captures and network detection coverage material. The release provided defenders with technical artifacts to study exploit traffic and improve detection of Log4Shell-related activity.
Amazon Corretto released an open-source Java agent on GitHub to hotpatch CVE-2021-44228 in vulnerable Log4j 2 applications. The tool provided an additional mitigation option for organizations that could not immediately deploy full Apache Log4j updates.
SolarWinds published a Trust Center security advisory for CVE-2021-44228, documenting the company's assessment of Log4Shell impact on its products and providing remediation guidance. This marked an official vendor response from another major enterprise software supplier during the broader industry-wide mitigation effort.
On 2021-12-14, Northwave Security published log4jcheck on GitHub, a script designed to identify potentially vulnerable Log4j systems by injecting Log4Shell payloads into common HTTP headers. The release added a public technical tool for defenders to test exposure during the early response period.
VMware said it had confirmed exploitation attempts in the wild affecting VMware vCenter Server and urged customers to patch, apply workarounds, or remove Internet exposure. The advisory underscored the immediate enterprise impact of Log4Shell on widely deployed infrastructure software.
On 2021-12-13, CISA Director Jen Easterly called Log4Shell one of the most serious vulnerabilities of her career and warned that hundreds of millions of devices could be affected. CISA said broad exploitation was likely, including by ransomware and cryptomining actors, and began coordinating public guidance with international partners.
On 2021-12-11, Germany's Federal Office for Information Security (BSI) raised its cyber warning level to red over Log4Shell, calling it an extremely critical threat. BSI reported mass scanning, attempted and early successful compromises, including cryptominer, botnet, and initial ransomware activity, and urged rapid patching and mitigations.
On 2021-12-10, Elastic issued security advisory ESA-2021-31 addressing CVE-2021-44228 and detailing the impact on Elastic Stack products. The company provided product-specific mitigation and remediation guidance, marking an official vendor response for a widely deployed enterprise platform.
In the days following exploit publication, defenders reported widespread attack traffic, including scanning and exploitation attempts at high volume against exposed systems. Reporting described more than 100 attacks per minute, with activity coming from both researchers and malicious actors.
Apache published updated Log4j releases to address CVE-2021-44228, including the 2.12.2 branch release. These releases were part of the first wave of remediation guidance for vulnerable Log4j 2 deployments.
On 2021-12-09, warnings to Minecraft users highlighted that malicious chat messages could trigger code execution on vulnerable Java-based Minecraft servers and clients. This helped reveal that the issue affected far more than Minecraft because Log4j was embedded in many enterprise applications and frameworks.
By 2021-12-09, proof-of-concept exploit code for CVE-2021-44228 had been published, enabling remote code execution via Log4j's JNDI lookup behavior. Security reporting also noted early Internet-wide scanning and exploitation attempts soon after disclosure.
On 2021-11-30, Apache opened pull request #608 for Log4j 2 to restrict LDAP access via JNDI. The change reflects an early code-level mitigation effort tied to the vulnerability before the broader public disclosure and emergency release cycle.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
36 references tracked. Mallory keeps watching after this page renders.
solarwinds.com
Open sourcebsi.bund.de
Open sourcegithub.com
Open sourcecisa.gov
Open sourcesplunk.com
Open sourcegithub.com
Open sourcesupport.broadcom.com
Open sourcecisa.gov
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 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
Threat actors, including suspected state-sponsored groups, continued exploiting **Log4Shell** (`CVE-2021-44228`) in unpatched public-facing **VMware Horizon** and **Unified Access Gateway** systems, according to a joint CISA and U.S. Coast Guard Cyber Command advisory. In confirmed incidents, attackers used the flaw for initial access, deployed malware disguised as SysInternals tools, established command-and-control, moved laterally over RDP, and in at least one case reached a disaster recovery network and exfiltrated sensitive data. The advisory highlighted artifacts including `hmsvc.exe`, `SvcEdge.exe`, `odbccads.exe`, `praiser.exe`, `fontdrvhosts.exe`, `winds.exe`, `error_401.jsp`, and `newdev.dll`, and urged organizations that delayed patching to assume compromise, isolate affected hosts, hunt for indicators, and upgrade to fixed VMware builds. The vulnerability’s broad reach and difficult-to-observe execution paths also drove a wave of defensive tooling and monitoring guidance across the security community. Researchers released a Burp Suite **Log4Shell Scanner** that uses out-of-band DNS and LDAP-based callbacks to uncover hidden or asynchronous vulnerable services, while others published **Suricata** detection coverage, regex-based IOC matching for log review, and updated enterprise advisories from vendors including Red Hat, Sophos, Mandiant, and SANS. Reports also indicated exploitation activity had begun early, with botnets attempting to weaponize the flaw soon after disclosure, reinforcing that Log4Shell remained both a mass-scanning target and a high-impact intrusion vector long after patches became available.
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