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

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

Critical Remote Code Execution Vulnerability in SPNEGO Extended Negotiation Security Mechanism

In September 2022, Microsoft patched an information disclosure vulnerability in SPNEGO NEGOEX (CVE-2022-37958). On December 13, Microsoft reclassified the vulnerability as “Critical” severity after IBM Security X-Force Red Security Researcher Valentina Palmiotti discovered the vulnerability could allow attackers to remotely execute code. The vulnerability is in the SPNEGO Extended Negotiation (NEGOEX) Security Mechanism, which allows a client and server to negotiate the choice of security mechanism to use. This vulnerability is a pre-authentication remote code execution vulnerability impacting a wide…

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…