Apache logLj 2 vulnerability (CVE-2021-44228) – Updated

Published On: April 7, 2022|By |

15/12/2021 – Update

As our threat researchers continue to monitor the Log4jJ vulnerabilities new information and guidance will be surfaced, including the new CVE, CVE-2021-45046. This CVE deals with the remaining security vulnerabilities that were not patched in Log4J 2.15.0  to address CVE-2021-44228. CVE-2021-45046 has a CVSS base score of 3.7, which is less serious than the CVSS score of 10 in the original vulnerability CVE-2021-44228, however, there is still a risk of denial of service from this latest vulnerability.

The affected Apache Log4J software is used by many software vendors in their products, and by extension many applications may require updating in order patch the Log4J vulnerability. The security community is still working to identify all affected products. The Cybersecurity & Infrastructure Security Agency (CISA) are collating a list of known affected vendors and software which can be found here GitHub – cisagov/log4j-affected-db. This list is being constantly updated.

The latest advice for mitigation steps from the Transparity SOC is provided from the most up-to-date information from Apache, which can be found here Log4j – Apache Log4j Security Vulnerabilities.

Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0

Mitigation for CVE-2021-45046 and CVE-2021-44228

Transparity’s advice is to lead with patching:

  1. Upgrade Java to version 8.
  2. Upgrade Log4J to release 2.16.0 or higher (2.16.0 is the latest version at time of writing)

If you are currently running Java 7, an impending patch, 2.12.2 is being worked on and should be available soon. However, the Transparity SOC would recommend upgrading to Java 8 where possible.
(Log4j – Apache Log4j Security Vulnerabilities)

Apache do advise as a last resort, where patching is not possible, that the JndiLookup class is removed from classpaths where possible:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Additional mitigations:

  • To prevent attacks on a network level and the vulnerable Java service from downloading a malicious class file via LDAP, outbound connections from affected servers can be limited to trusted hosts and protocols to prevent the weak Java service from downloading a malicious class file via LDAP.
  • Block User-Agent string using WAF “${jndi:ldap”
  • Microsoft have posted an article with a workaround https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/







| Transparity Managed Security Service customers are being proactively reviewed and remediated as information on this vulnerability is released and additional mitigations are identified. All other customers should contact the Transparity Service Desk or their Account Manager if they require assistance or advice on remedial steps in order that we can work with you to define your requirements and a suitable action plan.


On the 9th of December 2021, a remote code execution (RCE) vulnerability in Apache logLj 2 was identified as being exploited in the wild. The vulnerability tracked as CVE-2021-44228 and referred to as “Log4Shell,” affects Java-based applications that use Log4j 2 versions 2.0 through 2.14.1. Log4j 2 is a Java-based logging library that is widely used in business system development, included in various open-source libraries, and directly embedded in major software applications.

Because the discovery of this exploit is so recent, many servers – both on-premises and within Cloud environments – have not been patched yet. We highly recommend that organisations upgrade to the latest version (2.150-rc2) of Apache logL4j 2 for all systems. CVE-2021-44228 is considered a critical flaw, and it has a base CVSS score of 10 – the highest possible severity rating.

Some of the software currently known to be affected:

  • Apache Struts
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • ElasticSearch
  • Flume
  • ApacheDubbo
  • Logstash
  • Apache Kafta
  • Spring-Boot-starter-log4j2
  • Apache Maven
  • Cloud Manager
  • Apache Tomcat

Current Mitigations:

  • Disable message lookups for logging mechanism API functions.
  • Restrict access and protocols that Log4j2 permits via Lightweight Directory Access Protocol (LDAP) and the Java Naming and Directory Interface (JNDI)
  • Update to the latest version – Log4j2 2.15.0-rc2
  • To prevent attacks on a network level and the vulnerable Java service from downloading a malicious class file via LDAP, outbound connections from affected servers can be limited to trusted hosts and protocols to prevent the weak Java service from downloading a malicious class file via LDAP.
  • Block User-Agent string using WAF “${jndi:ldap”
  • From 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookupclass from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  • For *any* version you can delete the JndiLookup.class

Microsoft have posted an article with a workaround:


Basic Update Steps:

The below steps are simplified and intended as a generic guide, each application may vary, please ensure backups are taken prior to updating where testing has not been carried out.

  1. Browser to https://logging.apache.org/log4j/2.x/download.html
  2. Download the 2.15.0 version applicable to your circumstance to your environment
  3. Make sure that to check the integrity of the file using the PGP signatures
  4. Standard process to update both the API and CORE paths to use the newer jars







View Our Latest Events

View More
Microsoft Partner 1 | Transparity Cyber
Microsoft Partner | Transparity Cyber
Microsoft Partner 3 | Transparity Cyber