JFrog Log4j resources at your fingertips

Log4J & Log4Shell Resources

Log4j Log4Shell 0-Day Vulnerability - All You Need To Know

All You Need To Know

The Log4j & Log4shell vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers. Understand Log4j Log4Shell exploitation vectors, learn exactly what’s vulnerable, and discover remediations about this zero-day vulnerability.

Log4shell Remediation Cookbook Using the JFrog Platform

Remediation Cookbook

In this technical blog post, we will address the detection, blocking, and remediation options you can take to protect your organization using the JFrog platform and you will learn how to detect, block, and remediate to protect your organization from the log4j vulnerability using JFrog Artifactory and Xray.

Log4j Detection with JFrog OSS Log4shell Scanning Tools

Free OSS Scanning Tools

While it’s hard to draw general lessons from this Log4j extreme scenario, it provides an opportunity to gauge our existing software development, testing, and release methodologies, and consider what can be done differently in the future to prevent this scenario. JFrog Log4j free OSS scanning tools allow you to detect Log4Shell vulnerabilities by scanning code on a deeper level, finding vulnerable packages that other scanning tools miss.

software supply chain security and vulnerabilities

Log4j - What Happened?

Join JFrog’s Senior Director Security Research, Shachar Menashe as he discusses the following Log4j and Log4shell topics:
– What is the Log4Shell vulnerability in Log4j and why is it so critical?
– Under what conditions can the vulnerability be exploited?
– Mitigation options, including available solutions when a software upgrade is not feasible
– How to efficiently detect the Log4Shell vulnerability in your software artifacts using JFrog Xray

Log4j Log4shell survival guide - Download


Looking for a simplified explanation for all of the Log4j vulnerabilities discovered and what you need to do?. This handy survival guide gives you all the essentials you need to know about the latest findings on Log4j vulnerability risks, all of the mitigations and any known bypasses.

Use this survival guide for the most accurate and concise remediation information on the vulnerability in all its forms.

Log4j Log4shell vulnerability Questions and Answers

Log4j Log4Shell Q&A

In our recent webinar, Log4j Log4Shell Vulnerability Explained: All You Need To Know, our  Senior Director Security Research expert Shachar Menashe shared information on the security issue and how to detect and remediate it.

We are happy to share additional information in the following Q&A, based on the questions raised during the webinar.

Log4j vulnerabilities detected in Maven Central packages

Exposed Maven Packages

In our recent blog post: “Log4j Detection with JFrog OSS Scanning Tools” we outlined the approach we implemented to improve Log4j vulnerability detection by scanning beyond package dependencies. The following are new findings gathered while using our new OSS tools to scan Java packages in the Maven Central repository.

JNDI - Unauthenticated RCE in H2 Database Console

JNDI Strikes Back

Very recently, the JFrog security research team 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). Read more about this new disclosure…

Preventing the next Log4j

Prevent the Next Log4j

Software testing is notoriously hard. Search Google for CVEs caused by basic CRLF (newline character) issues and you’ll see thousands of entries. Humanity has been able to put a man on the moon, but it hasn’t yet found a proper way to handle line endings in text files…

Log4j Vulnerability FAQ

In late 2021, security researchers announced a major vulnerability in Log4j, a widely used open source logging utility. The vulnerability, which has come to be known as Log4Shell, enables arbitrary code execution on systems that use Log4j. Experts have described the Log4j compromise as the worst software security vulnerability in decades.

What is the Log4j vulnerability?

The Log4j vulnerability is a flaw in a software utility called Log4j. When exploited, the vulnerability enables remote attackers to execute code on systems that use vulnerable versions of Log4j.

This means that attackers can effectively take control of applications – and, by extension, the servers that host them – from a remote location.

What is Log4j used for?

Log4j itself is a logging utility, which means it’s a tool that helps applications generate and organize log data. Log4j is designed in particular for Java applications. It is open source and free for anyone to use.

Java is among the world’s most popular programming languages, and Log4j was first released in 2001. Combined with Log4j’s open source nature, these facts mean that Log4j has been widely deployed in production applications. While there are no official statistics regarding total Log4j installations in the world, most researchers estimate that they number in the millions.

There is nothing inherently dangerous about Log4j itself; as long as you’re using a secure version of the tool, you can continue to do so without worry.

Am I affected by Log4j?

Only certain versions of Log4j are affected by the vulnerability. They are Log4j releases 2.0-alpha7 to 2.17.0, with the exception of versions 2.3.2 and 2.12.4.

While all of these versions are vulnerable, the severity of the vulnerability varies within this range of versions. See our Log4j “cheat sheet” for more information.

1.x versions Log4j are not impacted.

As long as the version of Log4j that runs in your software environment is not among the versions impacted, you are safe from the Log4j vulnerability.

You are also safe if you upgrade your Log4j installation to a new version. The specific version to use depends on which version of Java is running on your system. To upgrade to a secure version of Log4j, you’ll need to upgrade to versions:

- 2.3.2 (for systems running Java 6)
- 2.12.4 (for Java 7)
- 2.17.1 (for Java 8 and later)

Once you’ve upgraded Log4j to a secure version, attackers can no longer exploit the vulnerability on your system.

What version of Log4j is vulnerable?

As noted above, Log4j versions 2.0-alpha7 to 2.17.0 are vulnerable to Log4Shell. The exception within that range is versions 2.3.2 and 2.12.4, which are not vulnerable.

All other Log4j releases – meaning any versions released prior to 2.0-alpha7 or later than 2.17.0 – are not vulnerable.

How is the Log4j vulnerability exploited?

To exploit the Log4j vulnerability, attackers insert malicious strings into HTTP request URLs, then send those requests to applications that run vulnerable versions of Log4j. Log4j will then execute code in those strings.

Effectively, this means that attackers can run commands of their choosing on vulnerable systems by inserting them into HTTP requests.

What are possible Log4j mitigations and remediations?

The simplest and most effective way to remediate the Log4j vulnerability is to upgrade to a secure version of Log4j. As noted above, those versions are:

- 2.3.2 (for systems running Java 6)
- 2.12.4 (for Java 7)
- 2.17.1 (for Java 8 and later)

You can also mitigate the vulnerability by blocking requests to Log4j that include strings associated with exploitation of the vulnerability. A common string in this regard is ${jndi. Upgrading your Java Runtime Environment (JRE) may also mitigate the vulnerability because the latest JREs disable the loading of remote code.

Again, however, the best way to remediate the vulnerability permanently is to upgrade to a newer version of Log4j. Other mitigations are best used as temporary fixes until you can upgrade.

Is Artifactory affected by Log4j?

No. Shortly after Log4Shell was announced, JFrog confirmed that neither Artifactory, nor any other JFrog products, were affected by the Log4j vulnerability.

Systems running Artifactory may be affected if they also host other applications that use vulnerable versions of Log4j, but Artifactory itself will not make your system vulnerable.