What is Log4J Vulnerability | Why it is Highly Dangerous?

What is Log4J Vulnerability
What is Log4J Vulnerability

It is in the news, it’s on news headlines and even time magazine has an article on this issue. This classic java library hitting mainstream feels so odd? Well, do you know what is log4j Vulnerability? I’m talking about the same.

Anyway in this article I will explain to you what exactly this log4j vulnerability is and why it happened? but also share something a little more important.

You see these vulnerabilities come and go right, this will likely get patched, people will move on, life will likely go on but this has actually got me thinking a little bit about open source in general and I’m beginning to look at open source libraries a little bit differently so let me explain.

What is Log4j?

You probably already know what log4j is? it’s a very popular java logging library that you can use for logging stuff from your code so you can log things to a file like when something goes wrong error messages debug messages and then you can look up log files later and troubleshoot right, typical stuff.

Although to be honest logging libraries in java have always been a little bit of a mess. so even though it’s a bit of a mess overall log4j which is one of these logging library options has been doing its job pretty well for many many years now but there was a dark secret that was hidden under the surface.

What is Log4j Vulnerability?

Log4j Vulnerability is a vulnerability found in the Log4j Open Source Library managed by a famous software company “Apache”. A hacker can exploit this vulnerability to gain Remote access to any system.

A major security vulnerability that’s now come into the open and we have a big issue on our hands. Any java application that uses log4j can be hacked that is anything lower than the recently patched version of log4j which is 2.16 right? So this actually results in enterprises racing to patch their log4j versions and deploy the newest version and it also results in hackers

racing to exploit targets before it’s set into prices do a patch.

So much fun now you might look at your app and go well hey I don’t use log4j so I’ve no problem, not so fast log4j is such a popular library that even if you aren’t using it directly you might be depending on another library which actually uses log4j for logging or that might depend on another library which uses lot4j at this point.

Considering how popular log4j is there is a good chance that any decently sized java application running out there probably has log4g installed on it. There’s a developer security company called a Snyk however we pronounce it but found that about 60 plus percent of java applications that they scanned actually use log4j indirectly and not depending on it directly.

So this is a widespread problem and now not only is this problem widespread but the severity is pretty high too.


There is something called the CVSS score which stands for Common Vulnerability Scoring System and this CVSS score has actually rated 10 for this vulnerability it’s 10 out of 10. The highest it could possibly be now.


It stands for Remote Code Execution. What this means is? This

actually allows hackers to be able to run any code on your machine by hacking into your application which uses a log4j. They can run any code they want.

I’ll be explaining the actual vulnerability in a little bit but I hope you understand why this is so serious. This is a reason this vulnerability is actually nicknamed log4shell.


It’s almost like anyone can open a shell on any server and issue commands. It’s that bad. So this is big but what exactly is the problem itself? There are actually multiple things that have happened and all together resulted in this vulnerability.

Features of Log4j that cause this Vulnerability

Log4j Log Expressions

Log4j allows you to log expressions. This should be obvious because you can take log Expression by using a line of code.


Now I’m going to introduce the second item in this article that just caused this problem which is a JNDI.

JNDI stands for Java Naming and Directory Interface. JNDI allows you to store java objects in a remote location and then serialize them kind of like streaming them to your JVM as scary as this might seem. This is a technology that’s been around for a while this was pre-rest API and this was a redistributed java system that would work with each other. This is how they would communicate. This has fallen out of popularity now but it is still there in java.

Similar to SQL Injection and Log Injection

All right this is what’s referred to as Remote Code Execution, does this remind you of anything?

Which has a similar vulnerability it’s called SQL injection we’ve seen something similar pattern.

This is kind of similar to what you can call log injection and be honest log injection has been happening for a while. You can technically do log injection if you have badly written code and it’s not even related to this vulnerability.

This is a really old technique and people handle it differently they don’t directly add the stuff they handle slash ends and all that but in the general log, injection is relatively harmless there’s not a lot of damage you can do.

What is the Solution of Log4J Vulnerability?

It’s very easy to find out that this is a log injection but Remote Code Execution is a much bigger problem. All right now how do you mitigate this?

JVM Flag

The first thing you can do or the easiest way to solve this problem is to set a couple of flags to false. There are two flags here which end with a trust URL code base.

Upgrade to a newer version of Log4j

You can upgrade to the newest version of log4j and it should be a simple solution but it can be problematic if you have dependencies that depend on something else which depends on log4j.

Patch Class Directly

To resolve the dependency issue some companies have started to patch the class directly. They get the newest version of the class for the log release and they put it directly in the classpath so they know wherever there is this occurrence on this class

just patch this directly.

 If you’re depending on some luxury and that uses log4j, well

do you wait for that library to fix the issue first before you publish your version? Well, that can take a while or they may not even do it. So a simpler solution is to just patch it directly.

Use Dependency Constraints

If you’re using Gradle, there’s something called dependency constraints in Gradle. You must strictly use the latest version of the library to solve this problem before a potential hacker can leverage it to hack into your application.

Conclusion (What is Log4J Vulnerability)

Now if you know what the Log4j Vulnerability issue is, the basic reason behind the scene is the open source has traditionally been thought to be secure by default because the code is out there for everyone to see.

People use this reason often it’s like the code is out in the open so if there is a security vulnerability people will catch it and they will fix it.

This is usually been an argument for open source. This approach needs to be changed.

And also the companies who use Open Source systems should contribute to maintaining the security of these systems.