www.belgium.be Logo of the federal government

Warning : Active exploitation of a 0-day RCE in Log4j

Advisory #2021-21
Logiciels concernés : 
Log4J versions >= 2.0-beta9 & Log4J versions <= 2.14.1
Mainstream software using Log4j as an utility
Remote Code Execution (RCE)

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Severity of the Risk: High
Information trustworthiness: High

Attack vector: Network
Attack complexity: Low
Privileges required: None
User Interaction: None
Impact: Confidentiality: High, Integrity: High, Availability: High



The objective of this alert is to raise awareness about a vulnerability in Log4j that is actively scanned and exploited by threat actors to compromise systems that are publicly connected to the internet.

Log4j is developed by the Apache Foundation and is widely used by both enterprise apps and cloud services. Successful exploitation could lead to a fully compromised environment.

The Centre for Cyber security Belgium recommends system administrators to patch vulnerable systems as soon as possible and to analyse system and network logs for any suspicious activity.

If you have already identified an intrusion or incident, please report it via: https://cert.be/en/report-incident


The vulnerability, catalogued as CVE-2021-44228, is an unauthenticated Remote Code Execution (RCE) vulnerability in the widely used Log4j framework. This vulnerability also has an impact on default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc.

Furthermore, other mainstream organisations confirmed that their software is vulnerable to the Log4j vulnerability: Apple, Amazon, Twitter, Steam, Baidu, NetEase, Tencent, Elastic, etc.

Update 15-12-2021

The fix to address CVE-2021-44228 in Apache log4j 2.15.0 is incomplete in specific non-default configurations, allowing attackers to craft malicious input data using a JNDI Lookup pattern that could result in a DoS attack.
The description of the new vulnerability in Apache Log4j (CVE-2021-4506) can be found under NVD summary.

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-45046

Update 20-12-2021

The CCB urges organisations to update Log4j version to version 2.17.0 or later.

The CCB wants to emphasize on:

  1. The current massive exploitation of these vulnerabilities by threat actors in external network environments on a global scale.
  2. The prevalence of the affected software in the private & public sector possibly impacts all industry verticals.
  3. The risk of a potential compromise is high, the potential impact of a successful compromise is critical.   

Actions recommandées


Vulnerable software: All Log4j versions from 2.0 up to and including 2.14.1

Create an inventory that includes all the software from your organisation and check per entry if Log4j
is implemented.

Please note that this vulnerability may also occur in custom developed software within your organisation, and software suites from mainstream vendors such as Apache, Atlassian, Amazon, Cisco, Elastic, Fortinet, Oracle, Splunk, VMware.

Please consult the following GitHub page maintained by NCSC-NL for a more comprehensive list of possible impacted software vendors.

Update 15-12-2021

NCSC-UK disclosed a technique to discover unknown instances of Log4j within your organisation.
A file system search for log4j can be undertaken. This should include searching inside EAR, JAR and WAR files. For example:

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

If a dependency or package manager is used:

dpkg -l | grep log4j

Remark: There could be multiple copies of Log4j present, each copy will need to be updated or mitigated.

- NCSC-UK: https://www.ncsc.gov.uk/news/apache-log4j-vulnerability


Update 20-12-2021

The mitigation method formatMsgNoLookups=True flag is ineffective at stopping certain attacks.

Organisations must update to 2.17.0 or use the JNDI patches for temporary mitigation.

If you are using a version older than 2.10.0 and cannot upgrade, your temporary mitigation choice is:

Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior.


Update 20-12-2021

To prevent the library from being exploited, it's urgently recommended that Log4j versions are upgraded to Log4j 2.12.2 for Java 7 and 2.17.0 for Java 8 and up.

- Java 8 V2.17.0: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.17.0
- Java 7 V2.12.2: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.12.2

Please consult the following GitHub page maintained by NCSC-NL for a more comprehensive list of possible impacted software vendors and specific information regarding which version contains the security fixes, and which software still requires mitigation.


The CCB advises organisations to upscale monitoring and detection capabilities, to detect any related suspicious activity, ensuring a fast response in case of an intrusion.
Organisations can identify if they're targeted by examining the log files for any services using affected Log4j versions.
The recommended date to start your investigation is from December, 1st 2021. There are detection rules available that could detect a possible intrusion attempt:

General detection regex


Network-based detection

Snort and Suricata rules

These are ET Open free community detections to alert on current exploit activity.

Host based detection

Plus d’information

For more information: https://logging.apache.org/log4j/2.x/download.html





CCB Webinar, 16/12/2021:

Log4J! What exactly is going on?

  • What is it? How to Identify, Patch or Mitigate?
  • How to Monitor for active exploitation attempts?