skip to Main Content
This website use cookies which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy. To learn more or withdraw consent please click on Learn More. By continued use of this website you are consenting to our use of cookies.

Log4Shell, The Worst Java Vulnerability in Years

Log4Shell, The Worst Java Vulnerability In Years

Key Facts

Affected: Systems and services using Apache Log4j versions 2.0-beta9 to 2.14.1
Severity: 10.0 Critical
CVE Entry: CVE-2021-44228
NIST NVD Publish Date: 12/10/2021
Source: Apache Software Foundation

On Dec. 9, 2021, a zero-day exploit (since dubbed “Log4Shell”) was observed in the wild targeting a critical RCE vulnerability in Log4j, the ubiquitous open source logging tool. (Per NIST, in affected versions, JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI-related endpoints.) Numerous platforms appear to have been affected–including Apple, Cloudflare, and Twitter–in addition to the raft of popular Java ecosystem products with Log4j embedded in their software supply chains, such as Logstash, Apache Kafka, Elasticsearch, and even Minecraft. 

Observers consider the Log4j vulnerability the worst one in years, perhaps even more critical than the Apache Struts RCE vulnerability (CVE-2017-5638) of 2017 that contributed to a massive breach at Equifax. Per Bugcrowd Founder and CTO Casey Ellis, this new vuln is a toxic cocktail combining immense attack surface, easy exploitation, hard-to-avoid dependencies, and extreme virality. Among other things, it’s a reminder that software supply chains have become deeply complex, with layered inter-dependencies that are usually beyond the reach of automated tools like scanners.

When the dust inevitably settles, it will be a clarifying moment for organizations that have yet to take a continuous, platform-powered security testing approach that combines data, technology, and human intelligence, including the force multiplier of the Crowd, to find and remediate vulnerabilities before they cause damage. In a future blog post, we’ll describe how that approach helped Bugcrowd verify, validate, contextualize, and communicate Log4Shell exposures to customers within hours.

In the meantime, we’re eager to help by offering:

  1. A 30-day “Log4j On Fire” bug bounty solution for continuous, crowd-powered discovery of Log4Shell exposures on your perimeter. See details and get started here.
  2. Deeper insights about this vuln’s risk profile and future impact in this Security Flash video featuring Casey Ellis and Application Security Engineer Adam Foster.
  3. A live Q&A session with Casey next week (Monday Dec. 20 at 10am PST) to answer your questions about finding, safeguarding, and using best practices to address the Log4j vuln and Log4Shell exploit. Save your seat here.
  4. A single view into all our Log4j/Log4Shell resources here.

We are super proud of our customers, researchers, and team-members who are working together tirelessly to make our digitally connected world safer during this crisis. As always, we’ll get through it together!

Tags:
Topics:
Back To Top