Skip Navigation

Log4j log4shell Vulnerability: What is it and how to fix

By now, you might have already heard about a severe security vulnerability commonly know as “Log4shell Vulnerability”.
I will try to explain what is happening here and how you can find out if this vulnerability affects your website or application, and also we will have a look at how we can fix this issue.

To begin with, let me go through some basic stuff:

  • Log4shell is a vulnerability found in the logging library Log4j
  • Log4Shell was given a 10/10 critical rating and is tracked as CVE-2021-44228.

As of writing this document, this vulnerability was found in log4j version upto 2.15.0

Log4j is not a standalone application, but it is a widely used library used by applications to log information which can be used to investigate issues and do debugging. What this means is that unless you added log4j in your application’s dependency list, you are very unlikely to get affected by anything related to log4j. Most applications wtitten in Java, particularly several Apache frameworks are confirmed to be affected.

What exactly is the security vulnerability?

The basic concept is somewhat similar to SQL injection, where an attacker will pass executable code in place of string of characters, and the program will execute the code instead of just storing or displaying the characters.

In the case of log4j, this vulnerability takes advantage of the JNDI (Java Naming and Directory Interface) , which is the interface used by log4j to communicate with an LDAP server, mostly for the purpose of authentication.

Since JNDI does not enforce security controls on LDAP request, and in some cases log4j will log the data originated from user inputs, hackers can include a link to an executable package on an LDAP server as input to log4j, which leads to remote code execution on the victim server.

Essentially, it allows attackers to send a string to your application, and if it logs it somewhere, you server will execute malicious code. The format of the text looks like the following:


How to check if my System is Vulnerable?

Since log4j is an embedded dependency, it may be complicated to check for the specific version of it on your system. And, since Java is so popular, many third-party tools and components may also use it.

JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the primary attack vector (using LDAP) that’s being exploited the most right now. You will still need to patch it regardless, since it can easily be used with other attack vectors as well

Many people have already made scripts to automatically scan systems for vulnerable installations, such as this popular one written in Python, and this one from security firm LunaSec. One of the easiest to use is this simple bash script, which can scan your packages and identify log4j versions, and can also tell you if your system is even using Java in the first place. People are also sharing several utilities on social media (like the tweet below) to detect this vulnerability. It is recommended to be cautious before running any of the solutions provided by an unknown entity though.

How to mitigate Log4j Log4Shell

Log4j version 2.0-beta9 to 2.15 are confirmed to be affected. The recommended course of action is to patch affected instances up to the latest available version. As of writing this document, the latest version is log4j 2 2.17.1 .

The best course of action is to upgrade Log4j to the latest available version

According to the National Cyber Security Centre’s (NCSC) advisory, the flaw can also be mitigated in previous releases (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.

Since it is not that straightforward to fix this vulnerability, you should also keep track of the developments happening with log4j related to new versions and bugfixes, if you are hosting any applications which use log4j.

There is currently a few GitHub repositories like this one listing Log4Shell indicators of compromise (IOCs) with links to individuals and groups actively tracking Log4Shell’s exploitation.

Here is another useful GitHub Repo

There is also a Reddit “mega thread” users can follow which is regularly updated by the community with links to third-party advice, evidence of exploitation, analyses, honeypots, and more.

Hope this post brought some clarity to you on this matter. For further reading, please go through log4j security vulnerabilities

Add a comment