See for yourself – run a scan on your code right now

On 9 December 2021, Apache disclosed that the Log4j 2 utility contains a critical vulnerability that allows unauthenticated remote code execution (RCE), a serious issue that impacts a large number of applications.

This post is coauthored by Chetan Conikee, Fabian Yamaguchi, and Katie Horne.

What is affected?

Log4j is a popular open source logging package included as a dependency in a lot of major frameworks, such as Apache Struts2.

The Log4Shell RCE vulnerability will allow attackers to run arbitrary code by sending requests to servers running vulnerable versions of Apache Log4j. The attack has been dubbed “Log4Shell” and given the CVE number CVE-2021-44228. Apache Log4j versions <=2.14.1 are vulnerable to attack.

How does the attack work?

When parsing logs, Log4j inspects the input it receives and tries to resolve variables contained within the input. In particular, Log4j supports JNDI lookups, which allows variables to be retrieved over a network.

If an application is using a vulnerable Log4j version, an attacker can first send a string to the application that contains the malicious payload ${jndi:ldap://} where is an attacker controlled server.

The vulnerable application will interpret input contained within ${} as a JDNI resource and make a request to to retrieve the resource. The attacker can send back a remote Java class file, which will then be loaded by the vulnerable application.

How do I remediate this issue?

To secure your code against this vulnerability, upgrade your log4j library to the newest version. From log4j 2.15.0, the vulnerable lookup behavior has been disabled by default.

If you are unable to upgrade your library, you can temporarily mitigate this vulnerability by:

  • Setting the log4j2.formatMsgNoLookups parameter to true when starting Java Virtual Machine.
  • Removing the class JndiLookup from the Java Classpath:
      zip -q -d log4j-core-*.jar

You can use ShiftLeft CORE ( to help you:

  • Verify the version of the Log4j library that you’re using
  • Identify the parts of your code where you’re using older, affected versions of Log4j and attacker-supplied input is passed to logging calls
  • See whether the library is reachable from an untrusted source using Intelligent SCA.

Keep an eye on your application logs and review them for any unusual activity. We will update this post with more details as they become available.

To get a free ShiftLeft CORE account, visit
To try Intelligent SCA, sign up for a premium trial within ShiftLeft CORE.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now