New 0 Day – RCE in Java Log4Shell package

A new Remote Code Execution (RCE) has been disclosed in the wild affecting the log4j library for java.

Affected Apache log4j Versions

Affected versions: below 2.14, latest version 2.17

2.0 <= Apache log4j <= 2.14.1 -> Now 2.17

Non-Affected Versions

The JDK Version greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected according to this blog post

Blast Radious

Services in cloud-like: Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.


Now the challenge a lot of organizations have is to understand which application is using (actively of not the vulnerable library).

The challenge of the risk is the popularity of the library. A CVE has been recently registered linked to this vulnerability: CVE-2021-44228 

A Tweet with the PoC was added recently before the CVE-2021-44228  was published

Marcus as well has expressed the opinion on why the vulnerability is bad


Several services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

Officially any system that runs apache with this library is vulnerable to this 0 day here is the official report from apache

The impact could be equivalent to the 2017 Equifax data breach. which spilled sensitive details for more than 143 million US consumers.

Attack so far

Sites like greynose monitoring the attacks are detecting an uptake. For the latest update see here

another site popular with attacking and defenders is detecting an uptake (103 at time of writing) of easily exploitable services

Attack – date 11/12/21 – 5PM GMT+1

Attack Escalated Quickly: Current Shodan view

No alternative text description for this image

Attack – date 10/12/21 – 5PM GMT+1

List of malicious payloads


Attacking IP (Updated)

and ongoing list of malicious IP’s attempting CVE-2021-44228 Apache Log4j RCE

why is it a big deal:

The researchers like Marcus said the Java deserialization bug stems from Log4j making network requests through the JNDI to an LDAP server and executing any code that’s returned. The bug is triggered inside of log messages with the use of the ${} syntax.


Exploiting Steps


  • Server with Apache and log4j library
  • Endpoint with sniffing capablity (wireshark) and an endpoint with any protocol that allows to send an exploit string
  • log statement that enables the logging of the attacker string


  1. Data get sent to the server (via any protocol like HTTP or HTTPS),
  2. The server logs the data with malicious payload: ${jndi:ldap://} (where is an attacker controlled server),
  3. The vulnerability in log4j is triggered by the payload and the server makes a request to via “Java Naming and Directory Interface” (JNDI),
  4. This response contains a path to the remote javafile (ex. wich is injected in the process,
  5. This injected payload trigger a second phase that enable the attacker to execute the RCE (hence the arbitrary code)

Security researchers have exploited those vulnerabilities over time. marshalsec project is one of many tools that demonstrates generating an exploit payload could be leveraged to deploy the vulnerability. You can refer to this malicious LDAP server for an example of exploitation.

For the full details on the exploit, LunaSec has a full detailed article

Example Vulnerable Code

import org.apache.log4j.Logger;

import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = Logger.getLogger(log4jExample.class.getName());

   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://}"Request User Agent:" + userAgent);

    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();


As of 2021 December 10th, 2021, Version 2.15.0 was released. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].


The following discussion on Hacker News details some of the workaround available

The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].

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

– Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at


– 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.

[1] [2] [3]

Other Mitigation

The modder and community came together to address streaming games like Minecraft.

The Spigot gaming forum said that Minecraft versions 1.8.8 through the most current 1.18 release are all vulnerable, as did other popular game servers such as Wynncraft. Gaming server and news site Hypixel, meanwhile, urged Minecraft players to take extra care.

As per Spigot Gaming Forum

Adding the JVM flag -Dlog4j2.formatMsgNoLookups=true neutralizes the threat for most Java versions. Spigot and many other services have already inserted the flag into the games they make available to users.

For more details refer to the full Ars Technica Article

How can we help

We are following the story very proactively and working with clients to help identify and automatically report and get alerted in the future on those vulnerabilities

to get more info reach out to us

Notification about Log4J/Log4Shell on the AppSec Phoenix Platform

List of application affected

node4j appsec phoenix detection remediation

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

risk based vulnerability management how to leverage Cyber threat intelligence, contextual based information to prioritize vulnerabilities across application security and cloud security
Francesco Cipollone

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

x Logo: ShieldPRO
This Site Is Protected By