If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers. For example, they may use it to troubleshoot a security incident, like if someone were to log into an application with the wrong password. Log4j might be used to record when the person logged in, to which application and the password they used.

Log4j is used by a very large percentage of the Java programs developed in the last decade for both server and client applications. Java is also one of the top programming languages used by businesses. That’s why, on December 9, 2021, when Chen Zhaojun of the Alibaba Cloud Security Team discovered CVE-2021-44228, a.k.a. Log4Shell, a high-severity vulnerability that affects the core function of Log4j, and a publicly available exploit, cybersecurity researchers sounded the alarm.

CVE 2021-44228 enables attackers to perform remote code execution, which means they can run any code and access all data on the affected machine. It also allows them to delete or encrypt files and hold them for ransom. Any function the impacted asset can do, attackers can do as well with the exploit. This means anything that uses a vulnerable version of Log4j to log user-controlled data can be attacked.

Webinar: Log4j Zero-Day Vulnerability — What You Need to Know Now

A Technical Dive into CVE-2021-44228

Log4j allows logged messages to contain format strings that reference outside information through the Java Naming and Directory Interface (JNDI). This allows information to be remotely retrieved across a variety of protocols, including the Lightweight Directory Access Protocol (LDAP). For example, when Log4j finds the following string in a log message, it instructs the JNDI to ask the LDAP server at for the “information” object.


By design, JNDI will execute Java classes that an LDAP server references. Continuing the example, if the LDAP server’s response references the URL, JNDI will automatically request the file information.class from the web server and execute the response.

Since the contents of log messages often contain user-controlled data, attackers can insert JNDI references pointing to LDAP servers they control, ready to serve malicious Java classes that perform any action they choose.

What’s to Come for CVE-2021-44228 and other recently disclosed vulnerabilities?

We have seen reports of attackers exploiting CVE-2021-44228, which doesn’t surprise us. Criminals will find this to be a very appealing attack technique because Log4j is popular, programs often include user-supplied data in logs, and the patch was only recently released. We expect more attacks — ransomware and others — to take place in the future.

Patching a single application isn’t too complicated, but each application needs to be tested to verify that the patch didn’t break anything. Large organizations could easily have hundreds of vulnerable applications across thousands of devices.

Apache Releases Another New Patch


Patching is the number one recommended mitigation step. Apache recently released 2.17.1 after a remote code execution vulnerability was found in 2.17. You must upgrade to 2.17.1 to mitigate this vulnerability. The CVSS score on CVE-2021-44832 is 6.6 and rated as moderate. An attacker must have privileged access to execute an attack. Apache’s mitigation recommendations include:

  • Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
  • In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Users are advised not to enable JNDI in any versions of Log4j.

Previously suggested mitigations other than patching Log4j or removing the JNDI Lookup feature entirely DO NOT mitigate this vulnerability.

On the preventative front, designing an environment with strong network security controls can help. In well-designed environments, for example, servers can only create network connections to explicitly approved destinations. Creating a default-deny firewall rule will prevent servers from creating unapproved connections and can help reduce your risk of a compromise. This is particularly important for servers that are exposed to the internet.

X-Force, IBM Security’s team of hackers, responders, researchers, intelligence analysts and investigators, is following the finding closely and will provide more information as our research unfolds. This disclosure is being tracked in this IBM X-Force Exchange Collection and will be updated should additional information become available.

Our researchers presented a webinar with more information. You can access the on demand recording by registering here.

X-Force has also created a scan tool to detect Log4Shell. You can access it, at no cost, here:

Additional assistance is available to assist 24/7 via IBM Security X-Force’s US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

To learn more about our team, or to schedule a one-on-one conversation with our researchers about this vulnerability, visit

More from Software Vulnerabilities

Containers, Security, and Risks within Containerized Environments

Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan. In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would…

Analysis of a Remote Code Execution (RCE) Vulnerability in Cobalt Strike 4.7.1

Command & Control (C2) frameworks are a very sensitive component of Red Team operations. Often, a Red Team will be in a highly privileged position on a target’s network, and a compromise of the C2 framework could lead to a compromise of both the red team operator’s system and control over beacons established on a target’s systems. As such, vulnerabilities in C2 frameworks are high priority targets for threat actors and Counterintelligence (CI) operations. On September 20, 2022, HelpSystems published…

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory. SCM systems are used in the majority of organizations to manage source code and integrate with other systems within the…

X-Force Research Update: Top 10 Cybersecurity Vulnerabilities of 2021

From 2020 to 2021, there was a 33% increase in the number of reported incidents caused by vulnerability exploitation, according to the 2022 X-Force Threat Intelligence Index. A large percentage of these exploited vulnerabilities were newly discovered; in fact, four out of the top five vulnerabilities in 2021 were newer vulnerabilities. Vulnerability exploitation was the second most common initial infection vector observed by IBM Security X-Force in 2021, falling closely behind phishing. Cybercriminals are finding new ways of bypassing security…