Loading story…
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.
See affected versions and whether adversaries are exploiting it.
12 events from the most recent confirmed update back to the earliest known activity.
On 20 February 2022, NCSC-NL warned that the high-risk Log4j vulnerabilities remained difficult to identify because the library was embedded in many products and systems. Although rapid remediation appeared to have limited active exploitation, it expected continued scanning and targeted attacks and urged continued identification and patching or mitigation of vulnerable systems.
Researchers described exploiting VMware vCenter's Log4j exposure through a JNDI/LDAP payload placed in the X-Forwarded-For header, targeting the /websso/SAML2/SLO/vsphere.local request path to obtain a reverse shell. They also demonstrated capturing Base64-encoded CastleAuthorization credentials from Envoy authentication traces and adapting tooling to use stolen vmware_soap_session tokens with pyVmomi for remote VM command execution.
Apache released Log4j 2.17.1 to address CVE-2021-44832, a configuration-file-dependent remote-code-execution vulnerability affecting versions 2.0-alpha7 through 2.17.0, with exceptions for 2.3.2 and 2.12.4. The flaw was rated 6.6 because exploitation required an attacker to modify the Log4j configuration file.
NCSC-NL updated its advisory as vulnerabilities and remediations evolved, created a mitigation-and-effects overview, and developed a response plan for organizations. It also maintained its GitHub collection of vulnerable software, detection rules, indicators, scanning resources, and mitigations, and conducted webinars and meetings with Dutch government, vital-sector, CERT, and OKTT participants.
NCSC-NL updated its advisory for CVE-2021-45105, assessing it as less severe than the earlier remote-code-execution flaws. It advised prioritizing remediation of RCE-affected versions and then upgrading applications from Log4j 2.16.0 to 2.17.0.
NCSC-NL issued an updated NCSC-2021-1052 advisory concerning an additional Log4j vulnerability affecting the 2.15 line. It directed organizations to Apache's updated releases and reiterated the need to prepare for potential abuse.
NCSC-NL urged organizations using Log4j 2.14 or earlier to upgrade as soon as possible to version 2.16, and recommended that users of 2.15 also upgrade where possible. It updated advisory NCSC-2021-1052 and said it continued receiving reports of limited active abuse.
NCSC-NL advised organizations to inventory Log4j v2 use, urgently apply supplier patches, mitigate or disable unpatchable exposed systems, and investigate for exploitation dating back at least to 1 December. Its guidance also covered incident-response readiness, forensic preservation, detection, backups, segmentation, restricted outbound traffic, and supplier dependencies.
NCSC-NL reported observing limited active exploitation in the Netherlands, while cautioning that the vulnerability's nature made exploitation difficult to track. It assessed that abuse could cause major consequential damage and updated its response guidance.
NCSC-NL said it could not issue a separate advisory update for every Log4j-using application and that inclusion on its list constituted an update to the HIGH/HIGH advisory. It published an overview page with recommended response steps for organizations.
Wiz reported that exploitation of CVE-2021-44228 was active and estimated that more than 89% of environments contained vulnerable Log4j libraries. It also stated that the NSA reverse-engineering tool was vulnerable, and described JNDI/LDAP payloads that could cause a vulnerable server to retrieve and execute attacker-supplied Java code.
NCSC-NL issued a HIGH/HIGH advisory for the severe Apache Log4j flaw, warning that publicly known exploitation methods could enable remote abuse of vulnerable web-server privileges. It also published an initially incomplete GitHub list of affected applications and sought community contributions, detection resources, and indicators of compromise.
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.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
14 references tracked. Mallory keeps watching after this page renders.
cymulate.com
Open sourcegithub.com
Open sourcencsc.nl
Open sourcencsc.nl
Open sourcencsc.nl
Open sourcencsc.nl
Open sourcewiz.io
Open sourcevulnerability.circl.lu
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 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
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