An unauthenticated remote code execution exists in the popular Java library ‘Apache Log4j 2’. This library is used by many Java-based applications for logging purposes. The vulnerability allows an attacker to execute arbitrary code within the Java process.

In short: applications that are remotely accessible, can handle user-input and use Log4j (version lower than 2.16.0) to log this input are potentially vulnerable.

If an attacker is successful in exploiting the vulnerability, they are able to execute arbitrary code and subsequently take over the server running the vulnerable application. The entire attack can be carried out remotely and without requiring authentication. From the vulnerable server, the attacker can obtain access to the rest of the network. Because of these reasons, we classify the impact of this vulnerability as high.

What can you do

What steps to take next

Northwave published a guide on the steps to take next. This guide can be found on


A new version of Log4j, version 2.16.0, is available at this moment

If any of the applications you have built yourself contain the Log4j package, we urgently advise to upgrade to the newest version and deploy the new package.

For third-party applications you are using, we advise to contact the vendor for any updates.

If, at this very moment, upgrading is not possible, there are the following mitigation alternatives:

  1. All versions:
    1. Removal of the class “JndiLookup” from the Java Classpath (e.g.: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class )
  2. All versions < 2.16
    1. Consider taking the applications offline


The only method to determine with reasonable certainty whether you have vulnerable versions of Log4j is to recursively scan the filesystem, including unpacking JAR files and other archives. A local scanner written by Lunasec can be found on Github DTACT has released a  local scanner that has the capability to detect Log4j in docker images. This scanner can be found on the following Github–log4j-scanner.

For urgent support, you can involve the Northwave CERT through 0800-1744 / +31 850 437 909

Important links:


DATE: 17-12-2021

Update: What steps to take next

Northwave has published a guide on how to prepare for any Log4j related impact.


DATE: 17-12-2021

Update: CVE-2021-45046 upgraded to CVSS 9.0

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This results in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.


DATE: 16-12-2021


Our Threat Responses previously mentioned that the VMware workaround instructions for vCenter 6.7 were insufficient. Further investigation together with VMware shows that our conclusions about the Update Manager mitigation steps were incorrect. Sine the workaround instructions by VMware have been subject to change in the past few days based on new insights, we recommend VMware customers to double-check whether they performed all of the current instructions as referenced in VMSA-2021-0028.3.

Northwave Threat Response:


DATE: 15-12-2021

Update: Earlier mitigations and updating to Log4J 2.15 could be insufficient

According to Lunasec, due to the newly found vulnerability tracked under CVE-2021-45046 versions below 2.15 with the noMsgFormatLookups=true mitigation are vulnerable in certain cases.
Lunasec also mentions that while this CVE only mentions a denial of service attack. It could be possible that a potential remote code execution is found for version 2.15.

Therefore it is important to upgrade to Log4j version 2.16.0.


DATE: 14-12-2021

Update: Log4j 2.16.0 released

log4j 2.16.0 is out which now completely disables JNDI by default and removes support for Message Lookups. If possible, upgrade log4j to version 2.16.0.


DATE: 13-12-2021

Update: Cisco Talos observes email based exploitation attempts

The following email based exploitation attempt was observed by Cisco Talos.


DATE: 13-12-2021

Update: Java version update is not sufficient.

Update Log4j to the latest version as updating the java version alone will not mitigate this exploit.


DATE: 13-12-2021

Update: Botnets adopt Log4j vulnerability

The MIRAI and Mushtik botnets are actively abusing the Log4j vulnerability.


DATE: 13-12-2021 | TIME: 07:02

Update: First known ransomware using Log4j

DATE: 12-12-2021 | TIME: 07:02

Update: First signs of exploitation seen on December first.

According to the CEO of Cloudflare,the first signs of exploitation can be traced back to December first.

DATE: 12-12-2021 | TIME: 16:00

Update: NCSC releases maintained list of vulnerable applications

DATE: 12-12-2021 | TIME: 16:00

Update: Cloudflare deploys mitigation for all cloudflare services

Cloudflare will now actively block any detected exploit attempt.


DATE: 10-12-2021

Update: Northwave releases online Log4j vulnerability checker.

DATE: 09-12-2021

Update: Lunasec releases vulnerability