A retrospective on CVE-2021-44228 — who it hit, what actually happened, and why it is still generating attack traffic in 2026.

On 9 December 2021, a proof-of-concept exploit for a bug in a Java logging library appeared on GitHub. Within hours, security teams across the world were pulling engineers out of holiday plans. Within 72 hours, defenders had recorded close to a million exploitation attempts. Cloudflare measured roughly 20,000 exploit requests per minute at the peak of the first evening.

Four years later, the fire is smaller, but it never went out. In 2025, developers pulled Log4j from Maven Central roughly 300 million times — and about 40 million of those downloads still contained the vulnerability, according to Sonatype's research. That is not a legacy problem. That is a live one.

This post covers what Log4Shell was, which organizations were genuinely affected versus merely exposed, how threat actors adopted it, and what the persistent-exposure data means for anyone running Java in production today.

What Log4Shell actually was

Apache Log4j 2 is the default logging framework for a large share of the Java ecosystem. Its job is mundane: take a string, write it to a log.

The problem was that Log4j did not simply write the string. In affected versions, it interpreted it. A message containing a JNDI lookup — a directive telling Java to resolve a resource from a directory service — would cause the logging call to reach out via LDAP or RMI to the address specified by the string, retrieve a Java class, and execute it.

The exploitation chain has three links:

1. Ingestion — attacker-controlled text enters the application. A username, a search field, an HTTP User-Agent header, a chat message, a device name.
2. Logging — the application logs that text, as applications routinely do.
3. Resolution — Log4j parses the lookup and fetches remote code.

The second link is what made this so brutal. Teams that assumed they were safe because their service "does not accept user input" discovered they were logging request metadata, error strings, and headers all along. Exposure surfaced in places nobody had modeled.

Technical summary:

Note the "fully remediated" row. The first fix, 2.15.0, was incomplete under non-default configurations. A cluster of follow-on issues arrived over the next three weeks — CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 — plus CVE-2021-4104 affecting the separate, end-of-life Log4j 1.x line. Organizations that patched once in mid-December and declared victory often shipped a partial fix. The Cyber Safety Review Board later identified this churn as a direct contributor to patching fatigue and confusion about authoritative guidance.

Timeline

Who was impacted

This is where most coverage goes wrong, so it is worth drawing a hard line. "Ran a vulnerable version" and "was breached" are different claims. The first list below is a list of products and services that were confirmed to contain the vulnerable Log4j. The second is confirmed intrusions.

Affected products and services

Within days of disclosure, researchers and vendors confirmed vulnerable Log4j in services and products from:

• Cloud and consumer platforms — Apple iCloud, Amazon, Cloudflare, Twitter, Steam (Valve), Minecraft: Java Edition (Microsoft), Baidu, Tencent, NetEase, LinkedIn, Webex
• Enterprise infrastructure — VMware (Horizon, vCenter, and others), Cisco, IBM, Red Hat, Elastic/ElasticSearch, NetApp, SonicWall, Intel, Siemens
• Apache's own ecosystem — Struts 2, Solr, Druid, Flink, Karaf, Swift
• Government tooling — GHIDRA, the NSA's own open-source reverse-engineering suite, which the agency's cybersecurity director publicly confirmed as affected

Microsoft stated that beyond the initial Minecraft disclosure, it was not aware of the impact on the security of its enterprise services. Cloudflare said it had patched and found no evidence of exploitation. Most large platforms landed in the same place: exposed, then remediated, without a confirmed compromise. That outcome is worth naming, because it was earned by fast, expensive incident response — not by luck.

The reason the list runs this long is not that these organizations were careless. Log4j appears overwhelmingly as a transitive dependency — pulled in by something else, three or four layers down, invisible to teams scanning only their own manifests. Most affected organizations did not deploy Log4j. They inherited it.

Confirmed intrusions

The confirmed breach list is shorter than the December 2021 panic implied. That is a real finding, not an omission — but read it with a caveat. Breach disclosure is voluntary in most sectors, the initial access vector is rarely published, and Log4Shell's characteristic pattern was persistent rather than having an immediate impact. The ONUS case is instructive: a sandbox server, a vendor's product, and a misconfiguration in an adjacent system did the actual damage.

How attackers adopted it

Adoption was fast and stratified across the entire threat ecosystem:

• Commodity botnets — Mirai and Kinsing variants integrated Log4Shell scanning within days, using it to propagate and drop cryptominers.
• Ransomware — Conti built a full attack chain around it on 20 December 2021, the first professional crimeware operation to do so. Khonsari, Night Sky, AvosLocker, and TellYouThePass followed.
• Nation-state operations — Microsoft and Mandiant reported activity from groups linked to China, Iran, North Korea, and Turkey within the first two weeks. The FCEB compromise remains the best-documented state-sponsored case.
• Opportunistic long tail — Datadog Security Labs documented a recent campaign targeting Confluence honeypots as recently as mid-2024, using obfuscated LDAP requests to evade signature-based detection and deploying XMRig.

Note the recurring cryptominer. For an initial-access vector this powerful, XMRig is an oddly low-value payload — and it points to how much of the exploitation was untargeted volume rather than deliberate operations against specific victims.

The official verdict, and the dissent

In July 2022, the newly formed Cyber Safety Review Board published its inaugural report on Log4j after engaging with roughly 80 organizations. Its central conclusion: this is an endemic vulnerability, and vulnerable instances will persist in systems for many years — the Board's own framing was a decade or longer. It issued 19 recommendations, weighted heavily toward asset inventory, SBOM adoption, and sustained investment in open-source maintenance.

The Board also recorded something less quoted: exploitation ran below what most experts had forecast, and it found no significant Log4j-driven attacks on critical infrastructure.

VulnCheck went further in a 2023 retrospective, arguing the response was disproportionate — of roughly 125,000 internet-facing hosts running potentially exploitable software, about 95% were already on patched versions two years in, and genuine initial-access targets had become scarce.

Both positions can hold. Log4Shell was less catastrophic than the December 2021 headlines predicted, and it remains the clearest demonstration to date of how a single transitive dependency can put an entire ecosystem into simultaneous incident response. The interesting question was never how bad the first month was. It is why the tail is this long.

Where things stand in 2026

The measured picture, from four independent sources:

• Sonatype (December 2025): Nearly 300 million Log4j downloads from Maven Central in 2025; roughly 13% — about 40 million — still carried Log4Shell. Across ten major economies, the vulnerable-download rate ranged from 8% to 29%, with India at 29%, China at 28%, and Japan at 22%. Sonatype's broader ecosystem finding is even more damning: around 95% of vulnerable component downloads already had a fixed version available.
• Contrast Security: Three years after disclosure, 12% of Java applications were still running vulnerable Log4j — down from roughly 50% at the one-year mark, but far from zero. Contrast measured over 4,000 exploitation probes per application in November 2024 alone.
• CISA (November 2024): Log4Shell remained among the top 15 most routinely exploited vulnerabilities in 2023.
• SonicWall, reported June 2026: Of approximately 264,000 attack events against UK healthcare in the first five months of 2026, 41% were Log4Shell exploitation attempts — against a total of roughly 27,000 events across all of 2025.

That last figure should be read as one vendor's telemetry from one sector in one country, not a global baseline. But the direction is consistent across all four: attackers are still probing, because the probes still land.

The underlying cause is structural, not technical. A fixed version has existed since December 2021. What has not existed, at most organizations, is a reliable answer to a deceptively simple question: where is this library, in everything we run, including the things our vendors ship us?

What to do about it now

If you have not revisited Log4j since 2022, five actions are worth the time:

1. Verify the version, not the ticket. Confirm you are on 2.17.1 or later (or 2.12.4 / 2.3.2 on legacy Java). Many organizations closed their Log4Shell remediation at 2.15.0 or 2.16.0 and never returned. A closed Jira ticket is not evidence.

2. Scan binaries, not manifests. Log4j hides in shaded JARs, fat JARs, container-based images, vendor appliances, and OT systems. Dependency-manifest scanning entirely misses repackaged and partially modified instances.

3. Treat egress as your detection layer. Most application tiers have no legitimate reason to open outbound LDAP or RMI connections to the internet. Restricting that traffic breaks the exploitation chain at the resolution step, and alerting on it is often the fastest indicator that something is wrong. Pair it with WAF, API gateway, and reverse-proxy log review, and match loosely, because attackers moved past plain jndi:ldap strings within days in 2021.

4. Fix the pipeline, not just the artifact. Forty million vulnerable downloads in a single year means build systems are still pinned to vulnerable versions, and nothing is failing the build. Version pinning without a review cadence guarantees this recurs with the next Log4Shell-class disclosure.

5. Hunt, do not assume. CISA's guidance for organizations that did not patch promptly was blunt: assume compromise and look for it. That advice has not expired. Map activity to MITRE ATT&CK T1190 (Exploit Public-Facing Application) as the entry point, then expand into credential access, lateral movement, and persistence.

The real lesson

Log4Shell was never really a Log4j story. It was a story about not knowing what you run.

The organizations that recovered fastest in December 2021 were not the ones with the best patching tools. They were the ones who could answer, in hours rather than weeks, which of their systems contained a given library, including the systems they had bought rather than built. Every regulatory response since, from the SBOM mandates in Executive Order 14028 to NIS2 and the EU Cyber Resilience Act, has been an attempt to force that capability into existence.

The next Log4Shell will arrive in a dependency nobody in your organization has heard of. The work that makes it survivable is the inventory work, and it has to be done before the disclosure, not after.

Why Organizations Choose Zaxtron

Organizations face increasingly sophisticated ransomware campaigns that exploit unpatched systems, stolen credentials, exposed remote access, and third-party weaknesses. To stay protected, they need actionable intelligence, not just alerts, to identify and reduce cyber risks before disruption occurs. Zaxtron provides Cybersecurity Risk Management, AI Risk Management, and Cyber Threat Intelligence services that deliver continuous visibility and risk-based insights. By combining attack surface intelligence, vulnerability data, threat and breach intelligence, and third-party risk analysis, Zaxtron offers a complete view of cyber exposure. This helps security leaders respond to threats, improve vendor security, and make informed decisions. Contact Zaxtron to strengthen cyber resilience today.

Sources

• CISA, Apache Log4j Vulnerability Guidance, and Emergency Directive 22-02
• CISA / FBI joint advisory AA22-320A, Iranian Government-Sponsored APT Actors Compromise Federal Network, November 2022
• Cyber Safety Review Board, Review of the December 2021 Log4j Event, 11 July 2022
• Apache Logging Services security advisories (CVE-2021-44228, -45046, -45105, -44832)
• Sonatype, Unnecessary Risk: The Persistence of Open Source Vulnerabilities, December 2025
• Contrast Security, Log4Shell exploitation telemetry
• CrowdStrike Falcon OverWatch, Aquatic Panda reporting, December 2021
• Datadog Security Labs, Log4Shell campaign analysis, 2024
• VulnCheck, A Log4Shell Retrospective, December 2023
• Microsoft Security Response Center, Microsoft's Response to CVE-2021-44228
• BleepingComputer, CyberScoop, The Register, TechCrunch, Tenable, and SecurityWeek contemporaneous reporting
• SonicWall threat data on UK healthcare, as reported in June 2026

Zaxtron Technology conducts open-source threat research. This post is based entirely on public, attributable sources; no first-party telemetry is claimed.