Log4Shell: Three years later & Log4j is still burning down the house

Three years ago this month, the security world found out about a massive vulnerability in the Log4j library. Log4Shell attacks began within hours. They haven't stopped, because, remarkably, many organizations haven't fixed it.

Why won‘t this thing die? 

Log4Shell was the biggest cyberattack of its day. Today, it still shows up in lists of Top 10 attacks. Besides its massive impact — the scope of which hasn’t yet been determined —  it’s probably the most widespread vulnerability ever, experts say. Officially identified as CVE-2021-44228, it carries a severity score of 10 out of 10 (CVSS v3.1) from the Common Vulnerability Scoring System (CVSS).

Happy unhappy birthday, Log4Shell. Below, you’ll see a history of the vulnerability and  numbers that show how prevalent Log4Shell still is, along with experts’ take on why this undead vulnerability is so hard to scrub out. 

A brief history of Log4Shell

Security researcher Chen Zhaojun of Chinese e-commerce company Alibaba first spotted the Log4Shell vulnerability and reported it to the Apache Foundation (an open-source project) on November 24, 2021. Apache promptly issued a patch for  Log4j, version 2.15, on December 6, 2021. However, this patch left part of the vulnerability unfixed. Apache researchers then found a Log4Shell attack on Minecraft servers on December 9, 2021, and soon realized that cybercriminals had discovered and exploited the gap from at least December 1, 2021.

Over the next few weeks, Apache released subsequent patches for Log4j that still had vulnerabilities. While any version from 2.17.1 onward is free of Log4Shell and its associated vulnerabilities, the Cybersecurity and Infrastructure Security Agency (CISA) reported in November 2024 that in 2023, Log4Shell was still among the top 15 most commonly exploited vulnerabilities.

Log4Shell by the numbers

Contrast’s research shows that today, three years after Log4Shell was discovered, 12% of Java applications are still running vulnerable versions of the library. This percentage is lower than the roughly 50% that were running vulnerable versions one year after Log4Shell’s discovery, but 12% still opens the door to millions of attacks.. 

One of the reasons the vulnerability still exists is because developers are still downloading vulnerable versions of Log4j. According to Sonatype’s published monthly download data, as recently as July 2024, 13% of all developers using Log4j were still downloading a vulnerable library version, all of them vulnerable to Log4Shell attacks. 

Still a target

Contrast Security sees and stops criminals trying to exploit the vulnerability every month. Our technology sees both probes and attacks. The vast majority of detected anomalies are probes: i.e., attackers rattling doorknobs as they search for weakness, misconfigurations and vulnerabilities they can exploit. Those probes are the first proof that attackers know this is still a major vulnerability and they can get past a WAF to search for it. 

Just looking at November 2024, attackers launched over 4,000 probes per application, according to Contrast Security’s measurements. 

Typically, after a criminal uses a probe to determine if there is a vulnerability, they will launch an attack. Because Contrast Security instruments applications and application programming interfaces (APIs), our numbers don’t reflect signatures or theoretical attacks, just the evidence-based attacks that actually occur.   

For November, our technology shows an average of 2.29 attacks per application using the Log4j vulnerability. Had Contrast not blocked those attacks, the criminal would have been able to then launch an exploit. 

To see all of the attacks Contrast Security detected in November 2024,
read our monthly attacks report.  

Contrast customers haven’t had to worry about Log4Shell being exploited, ever. We were stopping this attack years before anybody even knew it existed. To see how, check out our anatomy of an attack report, which focuses on how ADR detects and protects against Log4Shell.

Are Log4j vulnerabilities still an issue?

Contrast Security’s CISO David Lindner and Director of Product Security Naomi Buckwalter recently explained why Log4Shell remains a lurking danger. 

“Enterprise application code bases are huge. They're using hundreds, if not thousands, of third-party dependencies, which are using even more transitive dependencies,” said Lindner. “Developers simply don't have visibility into every piece of code, so Log4j is probably hiding in many applications without their awareness.”

“It’s been three years, so the focus isn't on Log4j anymore. The industry has moved on to other exploits,” agreed Buckwalter. “This damaging vulnerability continues to be targeted today. However, since it is no longer a primary focus, security teams and developers tend to overlook it.”

Why it’s so hard to kill: 

• Tangled interdependencies: Dependencies can be direct or transitive, where Log4j is included as part of another library.
  “Consider the layers upon layers of transitive dependencies that exist in enterprise software — a development team writes custom code, which is built using borrowed (third-party) code, and that code is using borrowed code, and so on and so on,” Buckwalter explained. “Even though your custom code isn’t explicitly using the Log4j library, the code that supports your code might. The Log4shell vulnerability may exist in software that your code is using without your awareness.” 
• Hidden components: Many organizations responded to Log4Shell by scanning their code repositories for references to the vulnerable version.  Unfortunately, many libraries aren’t in the code repository.  They are built into the application or API server, loaded dynamically at runtime, are part of a runtime module or plugin, etc. These libraries can only be discovered by analyzing the fully assembled, running application.  

Contrast Security founder Jeff Williams explains
how to fix AppSec in production

• Bad patches:  Early patches for Log4Shell were insufficient, leading to subsequent vulnerabilities that required further updates. Unfortunately, some systems remain unpatched or incorrectly patched over time. Log4j is one of the most widely used open-source logging libraries, making it difficult to ensure that all instances are updated promptly. Its widespread use means that even a small percentage of unpatched systems can represent a significant number of vulnerable installations. Without comprehensive visibility into their software components, it’s easy for companies to overlook outdated versions of Log4j. “When upgrading different instances of Log4j, you’ll always get to a version where there’s a ‘breaking fix’ — meaning it breaks the application,” Lindner added. “In many cases, upgrading to the new version isn’t a two-hour task. It can take months,” he said, leading to teams keeping vulnerabilities in place until a problem arises.

Who’s at highest risk of a Log4Shell exploit?

Log4j appears globally in millions of computer applications, and roughly 64% of Java applications rely on it. 

“Everyone has issues with Log4j. It’s still a ubiquitous threat,” said Linder. “Heavily regulated industries should be more protected, but they’re not. This is not about ignorance; people are just trying to do their jobs as efficiently as possible. So, things get overlooked. When everything is critical, nothing is critical,” he explained.

To fully understand the mechanics of an attack using
Log4Shell, see Anatomy of an Attack.

It’s a problem. But this problem can be addressed with Contrast Security’s (ADR). See below for details. 

How do I detect and remediate Log4j vulnerabilities?

Log4j remediation requires three steps, as outlined below. (For more details on these steps, see [Upgrade to 2.17] Updated Guidance on Addressing Log4J CVEs.) 

1. Conduct threat hunting to find indicators of compromise (IoCs).
   Buckwalter suggests looking for JNDI network traffic in past network and SIEM logs. “Go back and look at your Security Information and Event Management (SIEM) logs from two and three years ago when Log4j first surfaced. If at any time you see a high volume of JNDI connections to external systems — i.e.,  application input that contains ${  type syntax  that suddenly stopped, attackers have likely compromised your system,” she explained. “Attacks don’t just suddenly stop because the attackers have given up; they stop because they got in.”
2. Verify that the IOCs are malicious and patch where needed.
3. Block malicious activity while patching and upgrading with application-layer protection.
   “This is where Contrast’s ADR plays an important role,” said Buckwalter. “If there’s a vulnerable route and an attack is coming in, you must update that software or block the attack. Upgrading can take six months or more, so until that happens, Contrast’s ADR will block it and protect you.”

How does Contrast ADR offer protection?

ADR provides deep, real-time visibility and protection directly within the application layer. Until now, no other detection and response solution directly monitored and analyzed application behavior to detect real-time anomalies, attacks and vulnerabilities.

The technology enables organizations to trace attackers through all significant parts of an organization’s IT infrastructure. Attackers choose to target applications and APIs that are connected to the organization’s most valuable data. With ADR, analysts can track lateral movement from its point of origin — in applications and application programming interfaces (APIs) — and stop the incursion before it becomes persistent.

“ADR fills a much-needed gap at the application layer,” said Lindner. “Shift left was a failure. Companies have backlogs of security debt and insecure code running. ADR is perfect for protecting applications in production, which we haven’t had before.”

To learn more about how ADR technology can protect your organization, request a demo of Contrast Security ADR to see its capabilities in action.

Read more: 

• Contrast blog: Wake up, CISOs: You need an ADR flashlight to see into critical application blindspots
• Contrast blog: Bringing the application layer into cybersecurity monitoring and response
• Contrast blog: If only I’d known ADR was possible when I was a SOC analyst!