The Log4Shell vulnerability took the Java community by surprise at the end of 2021, and many organizations are still mitigating its impact. To help development teams stay informed as the situation unfolds, Snyk has created and continues to update its Log4j vulnerability resource center.
If you've already heard about the Apache Log4j CVE-2021-44228 (also known as Log4Shell and formally LogJam) vulnerability then you will know that this is a significant issue as many organisations are scrambling to secure their infrastructure from this critical remote code execution (RCE) vulnerability. With these considerations in mind, we wanted to bring you a guide that outlines the steps that can be followed to ensure the security of your systems from CVE-2021-44228.
Following the discovery of Log4Shell, a vulnerability in Log4J2, Elastic released a blog post describing how users of our platform can leverage Elastic Security to help defend their networks. We also released an advisory detailing how Elastic products and users are impacted.
Very recently, the JFrog security research team has disclosed an issue in the H2 database console which was issued a critical CVE – CVE-2021-42392. This issue has the same root cause as the infamous Log4Shell vulnerability in Apache Log4j (JNDI remote class loading). H2 is a very popular open-source Java SQL database offering a lightweight in-memory solution that doesn’t require data to be stored on disk.
No matter your role in tech, you’ve probably already heard about, or dealt with, the ubiquitous Log4Shell vulnerability impacting a large number of Java applications. To help spread the latest info on this critical, zero-day vulnerability, we recently hosted a webinar to get everyone up to speed.
Since December 10, in a span of just 20 days, there have been four different vulnerabilities published against Log4j. Engineers who worked long hours to update their Log4j versions to 2.15.0 on December 11th, were told three days later that they needed to do it all over again and upgrade to version 2.16.0. This is not sustainable. And yet the risks are high. Looking backward, we see that Log4j has been vulnerable since 2013 to the kinds of attacks described in CVE-2021-44228.
As CVE-2021-44228, a.k.a "Log4Shell" or Apache Log4j Remote Code Execution vulnerability continues to send shockwaves across the world of software, many security vendors and practitioners are rushing to provide recommendations on dealing with the crisis. If you need immediate help mitigating the impact of Log4shell, we're here for that. But the goal of this post is to look forward. This isn't the first and won't be the last high-impact vulnerability to be uncovered. So it's worth preparing your organization for the next one, so that you can respond faster, mitigate and remediate sooner - and have fewer weekends like the last one.
The high risk associated with newly discovered vulnerabilities in the highly popular Apache Log4j library – CVE-2021-44228 (also known as Log4Shell) and CVE-2021-45046 – has led to a security frenzy of unusual scale and urgency. Developers and security teams are pressed to investigate the impact of Log4j vulnerabilities on their software, revealing multiple technical challenges in the process.
Following the Dec. 9, 2021, announcement of the Log4j vulnerability, CVE 2021-44228, CrowdStrike Falcon OverWatch™ has provided customers with unrivaled protection and 24/7/365 vigilance in the face of heightened uncertainty. To OverWatch, Log4Shell is simply the latest vulnerability to exploit — a new access vector among a sea of many others.
