What is the Log4Shell vulnerability?

Log4Shell, the critical vulnerability disclosed in the Apache Log4j logging library in December 2021, remains one of the most impactful and persistent security flaws in modern software history, even now.

Assigned the identifier CVE‑2021‑44228 and a maximum CVSS score of 10, the flaw enabled remote code execution by exploiting how Log4j handled Java Naming and Directory Interface (JNDI) lookups, letting attackers inject arbitrary code into affected systems with minimal effort.

Following the initial disclosure, threat actors globally began scanning and exploiting the flaw at scale, with some estimates suggesting more than 100 attempted attacks per minute at its peak.

Apache responded quickly with a series of patches, but the vulnerability's presence in countless Java applications – including those embedded deep within software supply chains – has made complete eradication elusive.

Several years on, Log4Shell continues to pose a serious risk. Nearly 4,000 organizations remain vulnerable due to outdated components, unpatched systems, and inadequate dependency management, highlighting systemic issues in software maintenance and long-term remediation.

How big is the problem?

In 2025, Log4Shell remains a significant security concern. A December 2023 report by Veracode found that nearly 3,900 organizations were still using vulnerable Log4j versions across more than 38,000 applications.

Of those, 2.8% were running versions directly affected by the original Log4Shell flaw, and 3.8% were using 2.17.0, which contains a separate critical vulnerability (CVE‑2021‑44832). Notably, 32% of applications relied on Log4j 1.x, which has been deprecated since 2015 and is affected by several unresolved vulnerabilities.

Runtime telemetry from Contrast Security in late 2024 adds further context: 12% of Java applications still use vulnerable Log4j builds, with some seeing over 4,000 exploit probes each month, and unprotected apps faced, on average, more than two successful exploit attempts per month.

In December 2025, Sonatype found 14% of Log4j downloads in the UK were still vulnerable, with 13% worldwide found to contain the vulnerability despite the commonality of the safe variant.

Why are organizations still vulnerable?

Despite the availability of patches and intense scrutiny following the initial disclosure, many organizations remain exposed to Log4Shell due to a mix of technical, operational, and structural challenges.

One of the most persistent issues is dependency sprawl. Log4j is often embedded deep within software supply chains, making it difficult for IT teams to detect and remediate vulnerable instances.

Even when organizations are aware of the issue, patching can be complicated by compatibility concerns, legacy codebases, or the risk of disrupting production systems.

Developer behavior is also a contributing factor. A Veracode study found that 79% of developers never update a third-party component after its initial inclusion. This inertia, combined with inconsistent dependency management practices, allows vulnerable versions of Log4j to persist across environments for years.

Ongoing exploitation and real-world risk

While exposure alone is concerning, the continued exploitation of Log4Shell highlights the urgency of the issue. In short, threat actors have not moved on.

The continued presence of vulnerable Log4j instances across enterprise systems has kept Log4Shell a viable attack vector. Its widespread use in Java applications, particularly those with complex dependency trees, means attackers can still rely on it to breach environments with minimal effort.

Rather than large-scale campaigns, exploitation has become more targeted and opportunistic. Threat actors increasingly use Log4Shell to gain initial access before pivoting to broader objectives, such as lateral movement, credential harvesting, or data exfiltration.

In some cases, the vulnerability has been used to deploy crypto‑mining tools or maintain long-term persistence through web shells and backdoors.

Security researchers have observed that some attackers are specifically scanning for older Log4j 1.x deployments, knowing these are often overlooked in patching efforts and more likely to reside in legacy systems.

National security agencies, including CISA, continue to classify Log4Shell as a top-tier threat due to its ease of use and long tail of exploitation. Its persistence in attacker playbooks underscores the broader risks of unpatched software and the limitations of reactive security models.

A case study in failed remediation

Log4Shell has become a defining example of how even widely publicised vulnerabilities can persist for years when underlying remediation processes break down.

Despite near-universal awareness and the availability of patches within days of disclosure, long-term exposure has remained common across industries, geographies, and system types.

Part of the challenge lies in the structure of modern software development. Applications frequently rely on dozens or even hundreds of third-party components, many of which are nested deep within dependency trees.

Logging utility Log4j was often pulled in automatically by other libraries. As a result, many organizations were unaware they were using it at all. This lack of visibility has been a recurring theme in vulnerability management failures.

More fundamentally, Log4Shell has exposed the fragility of existing patching practices. Many organizations lack effective mechanisms to track, test, and update dependencies at scale.

Security teams are often overburdened, and patch cycles prioritise immediate operational concerns over longer-term risk reduction. As a result, even critical flaws with simple fixes can remain unresolved for months or even years.

Log4Shell’s persistence serves as a warning: disclosure and awareness alone are not enough. Without structural improvements in dependency management, vulnerability monitoring, and patch governance, similar risks will continue to resurface.

What organizations should do?

While many security teams addressed Log4Shell shortly after its disclosure, the continued presence of vulnerable systems shows that one-off responses are not enough. Organizations must treat it not just as a vulnerability, but as a broader lesson in sustainable security hygiene.

Visibility is the priority. Teams should use software composition analysis (SCA) tools and maintain a software bill of materials (SBOM) to identify where Log4j – or any other vulnerable component – exists in their environments, including indirect dependencies and container images.

Where Log4j is still in use, remediation should follow quickly. For Log4j 2.x, this means upgrading to version 2.17.1 or later. For Log4j 1.x, migrating to a supported logging framework is essential, even if it requires significant code changes. Mitigations alone are not sufficient.

Defensive layers also matter. Runtime protections – such as egress filtering, EDR, and intrusion prevention – can detect or block exploitation attempts. These should be backed by effective logging and alerting.

Finally, organizations must improve long-term dependency management. Automated update pipelines, regular auditing, and security checks in CI/CD workflows reduce the risk of repeat incidents.

While Log4Shell emerged in 2021, its legacy demands systemic change, not just patching.