Core Java

Log4j RCE 0-day vulnerability (CVE-2021-44228) mitigation actions

I had an update from my very good friend and excellent consultant Stella Varvarigou in which she explained me that setting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false does not fully mitigate the threat as it is possible to send the exploit code with the request.[2]


Apache Log4j, the most popular logging system, has announced a zero-day exploit CVE-2021-44228 on December 9, 2021 that results in remote code execution. Let’s analyze whys this happened and what can be done in order to mitigate the risk.

Why this happened?

In version 2.0-beta9, Log4j added the “JNDILookup plugin” in order to allow variables to be retrieved via JNDI. With JNDI you can retrieve java, ldap, and ldaps protocols or no protocol at all. The problem is that it used a syntax ${prefix:name} where prefix is one of a number of different Lookups where name should be evaluated. For example, ${java:version} is the current running version of Java [1]. This syntax can be exploited with the use of a  `:` present in the key so all the attacker has to do is to find some input that gets logged and add for example ${jndi:ldap://}. This could be any commonly gets logged HTTP header like User-Agent.

How this can be mitigated?

Easily… The mitigations actions are the following


Update to version 2.15.0 that you can download from here Log4j v2.15.0

For Maven users


If you want to check for a transient dependency run mvn dependency:tree -Dverbose | grep log4j (if u are on linux or Mac) and search for something like log4j-api:jar:<version>:compile in order to see the version. If you are on windows use mvn dependency:tree -Dverbose > depentencies.txt and open the depentencies.txt file and search for the test there.  It would also be best to apply an enforcer plugin rule in order to avoid having a vulnerable version through a transient dependency. A gist can be found here


For Gradle users check this tweet from Cédric Champeau

Remove the class from the jar

Yes, this is dirty and the last resort action but it is pretty easy and it works if you can not upgrade or change the properties of an application. Look for the log4j-core-*.jar and execute zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Tune your firewall

Most of the commercial firewall services like Cloudflare have already created firewall rules to prevent extended requests that might exploit this. If you don’t have a commercial solution be sure to create rules that block the JNDI Lookup in common locations in an HTTP request like URL, header, and body and also block outgoing LDAP and RMI connections.

  • [1]
  • [2]
Published on Java Code Geeks with permission by Alexius Diakogiannis, partner at our JCG program. See the original article here: Log4j RCE 0-day vulnerability (CVE-2021-44228) mitigation actions


Opinions expressed by Java Code Geeks contributors are their own.

Alexius Diakogiannis

Author of, JEE Architect, Scrum Master, Enthusiastic Entrepreneur, Passionate Archer, Linux Lover and JAVA Geek!
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
2 years ago

Mitigation that ALWAYS works: define and implement non functional requirements that deal with ingress as well as egress network traffic and apply a closed-unless networking policy to all projects that even expose the smallest of API to the internet. Another mitigation that ALWAYS works: crank up the volume of Sonar and always fix all the warnings. I venture the thought that anyone being affected by this bug did not do their due diligence on those aspects of software engineering. If you do not need LDAP traffic etcetera in your application then do not allow it in the first place. If… Read more »

Back to top button