Experts: Why the Log4Shell Grinch is still hanging around

Three years ago, Log4Shell was the worst holiday gift ever for security teams, particularly given that it was wrapped in a CISA order to patch by Christmas Eve. 

We’ve already shared November’s attack numbers, which show that this Grinchy vulnerability never went away. In this article, we share  independent input from experts in the field regarding why this dreadful remote-code execution (RCE) bug is still so widespread, and what cybersecurity leaders and practitioners can do to protect their organizations from the persistent threat. Their insights delve into issues with software supply chains and open-source coding libraries, the unrecognized value in Software Bills of Materials (SBOMs) for third-party software visibility, and the benefit of relying on managed security service providers.

Log4j: Dug down deep in third-party software 

Three years after its discovery, “Log4Shell remains a critical reminder of the systemic challenges organizations face in managing vulnerabilities within their software supply chains,” said Katie Norton, Research Manager, DevSecOps & Software Supply Chain Security for IDC. 

“Despite being disclosed nearly three years ago and considered remediated by the end of 2021, its continued inclusion in the Cybersecurity and Infrastructure Security Agency’s [CISA’s] 2023 list of top routinely exploited vulnerabilities [PDF] highlights the persistent risk posed by legacy dependencies,” she continued. 

Contrast customers didn’t scramble when Log4Shell hit;
they kept drinking their eggnog. Here’s why

“Log4j's ubiquity in applications and services — often buried several layers deep within software stacks — makes complete eradication a complex and resource-intensive task,” Norton explained. “For many organizations, the difficulty of identifying and patching vulnerable instances is compounded by compatibility concerns and the risk of introducing breaking changes, particularly in legacy systems where dependencies are significantly outdated. These challenges contribute to delays in remediation, leaving gaps that sophisticated threat actors continue to exploit.”

Headlines disappeared, but Log4Shell stuck around

Others agree with the researcher’s assessment, explaining that vulnerable versions of Log4j are so widespread largely because of the library’s ubiquitous presence in third-party software.  

“Three years after its discovery, Log4Shell remains a stark reminder that cybersecurity threats don’t disappear when the headlines do. Despite patches and mitigations, this vulnerability continues to expose organizations that rely on legacy systems or fail to audit their software supply chains,” said Cliff Steinhauer, Director, Information Security & Engagement for the National Cybersecurity Alliance.

Industry experts praise this approach
to digging out vulnerabilities like Log4Shell 

“Too often, companies assume their third-party vendors or open-source dependencies are secure without ongoing verification. The lesson from Log4Shell is clear: cybersecurity is not a 'set it and forget it' endeavor. Businesses must embrace continuous vigilance through regular patching, monitoring and testing,” he concluded.

Waiting on VMs to catch up

Andrew Wilder — Chief Security Officer for veterinary care network Vetcor — agrees. “When Log4Shell first hit, everyone went to their virtual machine solutions. But they weren’t immediately able to recognize the problem. So, we all had to wait for them to update the scanners, then scan every system, and finally, we could know the scope of the problem. Then, we had to work on fixing everything,” he stated. 

“But to be clear, these are just those that we could find,” he continued. “The real problem exists in third-party software. In this case, we were waiting for our vendors to provide us with an updated version and to work through the possible compatibility challenges of upgrading.”

Putting guardrails around open-source software

The unrestrained use of open-source software only contributes to the Log4j problem, according to some.

“Log4j was a wakeup call for the community,” said Chris Hughes, CEO of Aquia, a firm that advises and engineers cloud and cybersecurity services for digital transformation. “Years of ungoverned open-source consumption with little to no visibility, inventory, or concern came to a screeching halt as organizations around the world frantically tried to address the Log4j vulnerability. Despite the frenzy at the time, we still see nearly 15% of Log4j downloads today involving vulnerable versions of the component. 

The number of Log4Shell attacks we’re (still) seeing

“The open-source ecosystem is still incredibly fragile, as malicious actors have realized how to take advantage of this opaque, insecure and vulnerable attack vector that was overlooked for so long,” he continued. 

Wilder emphasized that we aren’t out of the woods yet:  “The truth is, Log4Shell is nowhere close to being solved. It is still rampant today,” he said. “And more vulnerabilities keep coming and keep getting exploited.”  

The importance of SBOMs

Norton suggests that companies must increase reliance on Software Bills of Materials (SBOMs) as a way to curtail the use of vulnerabilities like Log4Shell: an idea echoed by Wilder.

“Compounding the issue is the limited adoption of foundational practices like SBOMs, which are critical for gaining visibility into the software supply chain. Recent IDC research in 2024 found that around 60% of organizations are not generating an SBOM for their production applications, and astoundingly, only 10% of organizations report that their customers have asked them to start providing an SBOM for the applications they produce. This lack of demand and visibility perpetuates the use of vulnerable versions of Log4j,” Norton explained.

OWASP’s Steve Springett lays out the five dimensions of SBOM quality 

“Log4Shell alerted the cybersecurity community about the importance of good SBOMs,” Wilder said. “Solutions that give you full SBOMs of all your internally developed and third-party applications are rare today. This has, at the very least, helped people realize the need for SBOMs.” 

Where’s the silver lining?

The Log4j story is not all doom and gloom. Being aware of the ongoing nature of the problem is important, as is the need for organizations to proactively address Log4j and other vulnerabilities.

“For small, non-technical businesses, partnering with a trusted managed IT services provider is crucial,” suggested Steinhauer. “Such providers help ensure systems stay up to date, identify potential vulnerabilities and offer ongoing monitoring. Regularly asking questions about security updates and audits can make a significant difference in staying ahead of threats like Log4Shell,” Steinhauer said.

Contrast Security’s managed Application Security service, Contrast One, can be useful in helping companies find and remediate vulnerabilities, as can its Application Detection Response (ADR) solution.

Log4Shell Christmas would have been way merrier
if this former SOC analyst had ADR 

Aquia’s Hughes, who also owns and contributes to ResilientCyber.io, offers this insight: “Our digital infrastructure is still built on a house of cards that can crumble at any time. Organizations must mature beyond looking at lagging indicators of risk, such as known vulnerabilities, and look at leading indicators of risk, such as the number and origin of maintainers, how frequently and quickly vulnerabilities are resolved, and the security hygiene of projects and repositories. 

“They must also account for fundamental security such as visibility, inventory and governance of consumption, while understanding what is known to be exploited, likely to be exploited and reachable,” Hughes explained. 

Wilder believes it comes down to visibility. “Having a comprehensive understanding of exactly what we have running in our environment will allow us to react and prioritize quickly when the next one comes.” 

Want to learn more about how Contrast Security can help you address Log4Shell? Book a demo today.

Read more:

• ADR white paper: The Case for Application Detection and Response (ADR)
• Contrast blog: November: The top attacks ADR caught on the brink of exploit
• Contrast blog: Log4Shell: Three years later & Log4j is still burning down the house