JFrog: Questions and answers on the Log4j vulnerability Log4Shell



In our recent webinar, Explanation of the Log4j Log4Shell vulnerability: everything you need to know, our Senior Director Security Research Expert Shachar Menashe shared information about the security issue and how to find and resolve it.

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


Log4j’s security problem


How is the log4j exploit performed?

JFrog posted a blog post which explains the vulnerability in detail. Please see the section: “What Causes the Log4j Log4Shell Vulnerability?” “


I heard that the log4j API call was also vulnerable. Why are you focusing only on the core?

The log4j-api is not vulnerable, only the log4j-core is vulnerable.


How does the log4j log4shell vulnerability compare to Shellshock in terms of overall impact?

Both Log4shell and Shellshock are remote code execution vulnerabilities affecting a wide variety of systems. Shellshock is a vulnerability of bash (a very common Linux shell), which is an application, while log4shell is a vulnerability of the log4j library. For several reasons, the log4j security issue poses a greater threat mitigation challenge.

To detect Shellshock, it was enough to check the local system if a vulnerable version of bash was installed; bash itself does not usually come with third-party dependencies.

The log4shell security issue is much harder to detect, because log4j is a library, so detection requires checking all direct and indirect (transitive / recursive) dependencies. Additionally, the attack vector for log4shell is more common (logging unchecked entries) than that for Shellshock (passing unchecked entries to the bash environment).

Log4shell is also harder to fix – since it is a library, several APIs have been changed in more recent versions, meaning that a software vendor might need to modify proprietary code that interacts directly with log4j, and not just upgrade log4j itself.

Finally, newer versions of log4j require a newer version of Java (Java 8 vs. older Java 6/7), which means that the software vendor might need to upgrade the Java component as well, which may in turn cause incompatibilities with other Java-based versions. software on the system.


What about log4j version 1, which is not vulnerable? Will it be affected by the attention wave on log4j version 2?

The current exploit does not endanger version 1. However, attackers could invest more effort now to search for the log4j component to try and find additional vulnerabilities.


Solutions to find and repair Log4j


Do you have any specific tools that can help me identify if I have any log4j packages in my repositories?

Yes! For starters, our customers using the JFrog DevOps Platformas a central part of their critical software development lifecycle (SDLC) process, they already have everything they need to quickly address the log4j vulnerability.

With your packages, binaries, images and metadata accumulated under Artifactory’s binary repository management, you can search for artifacts and buildsto learn about every use of the log4j package, including as transitive dependencies, across your software supply chain. And you can create Xray policies and watchesto block any new generation using vulnerable versions of the log4j package from production.

For the developer community as a whole, JFrog has also released a useful set of open source tools for identify the use of log4jin source code and binaries in local directories.


Suppose we are using a third-party component that has a log4j build time dependency. Is there a way to get rid of log4j while using this component?

This is only a problem if the package uses a vulnerable version of log4j. If so, you will need to get a fixed version of the third-party component. If you have the source code, you can compile it yourself with the patched version of log4j.


Is a dependency that references log4j vulnerable to this attack, even when it uses an API library such as Spring Framework that references the log4j library as a dependency?

It depends on the specific case and the portions of the log4j library used. While log4j-core is vulnerable, log4j-api is NOT vulnerable.

For the most complete results, we recommend that you use a software composition analysis (SCA)scan tool like JFrog Xray to identify vulnerabilities in all your software dependencies – including those related to log4j, but also many, many more.

If this is not available to you, you can use the OSS JFrog tools created for the community to specifically identify the use of log4j in source code and binaries (see above).


Once Xray detects that an artifact is vulnerable to log4shell, is there a way to determine the consumers of that artifact – i.e. to use Artifactory to track which services / users have accessed / downloaded the vulnerable artifact, so that these specific services can be analyzed?

Absoutely! This is what the JFrog platform was designed for. You can use Xray and Artifactory to identify consumers of vulnerable artifacts and monitor their use using the following methods:

  • Search your repositories for the use of log4j packages
  • Search for CVE-2021-44228
  • Running a request for build information in Artifactory to list all builds that use the log4j-core library as a dependency
  • Define an Xray policy to alert a violation or block the download of the vulnerable package

For more details, see our blog post, Your Log4shell Remediation Cookbook Using the JFrog Platform, which discusses several methods of discovering, blocking, and remedying the log4shell vulnerability.


Can I see a demo of Xray for identifying static and transitive dependencies?

We will be delighted! Please contact us for a demo of Xrayand we’ll hold a call to show you how you can see through all the layers of an artifact’s dependencies.


Previous state webinar aims to strengthen business support for vaccine needs | Local news
Next Southeast announces vacation hours