CVE-2021-44228 – Log4j zero day vulnerability, detection and Log4shell fix

log4j vulnerability cve 2021 44228

Log4j zero-day vulnerability is flooding the security updates/news everywhere. This issue has been named Log4shell and assigned CVE-2021-44228 (still awaiting analysis at writing).

log4shell logo 1024x460 1

CVE-2021-45105 (infinite recursion in lookup evaluation) – third and latest flaw

Severity: High / 7.5
Affected versions: All versions from 2.0-beta9 to 2.16.0

CVE-2021-45046 (Log4j2 Thread Context Lookup Pattern RCE) – second flaw

Severity: CRITICAL
Affected versions: All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

CVE-2021-44228 (original log4shell vulnerability)

Severity: CRITICAL
Affected versions: All versions from 2.0-beta9 to 2.14.1

This is a developing story; you must refer to direct sources for any updates (Apache advisory page). From Minecraft to Internet’s big corporations serving applications we all use daily, a lot of them are vulnerable.

Why is this a big deal?

This Java logging library (Apache log4j) is found everywhere – from big corporations to SMBs. Log4j is heavily used within products/organisations, and therefore, the attack surface available is massive as of now. If you want to read about the related topics, then head to our popular posts: impacts of data breaches, types of malware, attack vectors to help you understand and assess your attack surface.

Updates since the original bug

There has been two more flaws since the original log4j vulnerability was discovered. Apache foundation has issued patches to fix this high severity log4j vulnerability.

  1. CVE-2021-45105 (Third flaw) – The latest version 2.17.0 is rolled out to address a security vulnerability in the logging library that could be used to launch denial-of-service (DoS) attack. This bug affects all versions from 2.0-beta9 to 2.16.0. You can read more about DoS and DDoS attacks here.
  2. CVE-2021-45046 (Second flaw) – This is a second bug that was discovered from flaws in ‘fix’ of original log4shell vulnerability. This flaw could result in remote code execution due to the incomplete fix in CVE-2021-44228 (log4shell). The severity for this issue (originally a DoS bug) has been revised from 3.7 to 9.0 as the attack impact includes information leak and remote code execution in some environments and local code execution.

What’s wrong with log4j?

This 0-day in java logging library log4j2 allows anyone to launch a RCE (remote code execution) by logging a particular string.

How do I find if I am vulnerable?

The best way to figure out this vulnerability in your environment is to get started immediately. You may need assistance from your technical teams to help you identify the vulnerable instances. There are also web pages created by vendors to identify the affected instances, however, the best way is for you to run the tests on your own.

Log4j vulnerability test

Log4j vulnerability test can be conducted in a number of ways based on the underlying operating system and the asset category.

A file system search inside JAR, WAR files using this command

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

You can search dependencies in use using this:

dpkg -l | grep log4j

The above search may return multiple results, which means all the copies require updating/fixing.

If you found these hashes in your inventory, then YES, your systems are vulnerable

Search for the presence of jar files around this pattern “log4j-core-*.jar”.
On windows, this file could be located here:

c:Program Files\log4j-core-version.jar

On Linux, you can find the apps using this jar file

lsof //log4j-core-version.jar

You should look for the output of this command in /var/log

sudo egrep -i -r '${jndi:(ldap[s]?|rmi|dns):/[^n]+' /var/log

Grep/zgrep commands and YARA rules to identify exploitation attempts are detailed here:

Use DNS logger ( or or canary tokens) and use it in your test payloads. DNS queries shall help to identify which hosts have triggered the vulnerability.

Log4rce, log4shell, log4j2, log4j are the popular hashtags to search further on this topic.

How to check which products are impacted?

you can check the attack surface list combined here:

Cisco security advisory log4j

To address log4j vulnerability in Cisco products and services, Cisco released snort rules available here:

None of the Cisco products is affected by vulnerabilities CVE-2021-45105 and CVE-2021-44832.

Later cisco released an advisory available here:

Ubiquiti log4j vulnerability

If you are using Ubiquiti products, see this official advisory:

Log4j vulnerability is fixed in UniFi Network Version 6.5.54 and later.


It is sensible to adopt an assume breach mentality and review logs as a first step to finding impacted applications for suspicious activities in your environment.

Minecraft has come up with a timely response to this issue already.

Log4j vulnerability exploiting demonstrating sensitive data leakage.

Mitigation – latest fix in log4j 2.17

Log4j v2.17.0 has fixed these identified issues. There have been about three patches released in a week to mitigate against the three discovered flaws. Workarounds are also available online.
Apache advisory

At network level:

  • Block unexpected outbound connections (LDAP, LDAPS, RMI), however, exploits can use random ports also.
  • Blocking URL strings containing “jndi:ldap” at WAF/application layer.

An excellent update by NCSC has been added here.

Anti-virus detections developed by Microsoft for Defender users on windows, linux include cryptocurrency miners, cobalt strike beacons, Tsunami backdoors, PowerShell and exploitation on the attacker machine. These details along with mitigation of log4j vulnerability by Microsoft Security Response Centre is detailed here:

Useful links:
An excellent write up by Lunasec

CISA emergency directive

Ycombinator – Log4j RCE found

Logging levels in log4j

A short lesson around logging levels in log4j. Log4j has three main components:

  1. Loggers – Capturing logging information
  2. Appenders – Publishing logging info to preferred destinations
  3. Layouts – Formatting logging info in different styles

All the logging levels in log4j are defined in the org.apache.log4j.level class.

The following log4j logging levels are listed along with their description:

  • ALL – All levels including custom level logging
  • DEBUG – granular informational events to help debug an application
  • INFO – Informational messages
  • WARN – As it says on the tin, warning messages or potentially harmful situations
  • ERROR – Error events that still allow the app to continue running
  • FATAL – Severe events that may not allow the application to function normally. An example would include running out of disk space, loss of network connectivity or missing configuration info if defaults cannot be used
  • OFF – Turn off logging
  • TRACE – Fine-grained informational event logging, more detailed than debug

These methods can be called as:

import org.apache.log4j.Logger;

public class LogClass {
private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class);

public static void main(String[] args) {


Security recommendations

These are general security recommendations to help you with ongoing improvements:


  • A vulnerability has been credited to Chen Zhaojun of Alibaba.
  • The official log4shell logo displayed above is from @GossiTheDog .

Log4j meme

This ‘log4j meme’ topic in itself deserves a separate section :). Obligatory memes found in online for log4shell are:

log4shell meme 236x300 1

In respect to Log4j from ProgrammerHumor

When our vendor says they’re safe because they’re using Log4J 1.X from ProgrammerHumor

log4j infosec meme

Get in touch to discuss any security concerns for your business.

Article Contents

Sharing is caring! Use these widgets to share this post
Scroll to Top