Unpacking the Log4j2 Log4Shell Vulnerability: How JNDI Injection Works

This article explains the Log4j2 vulnerability that made headlines, describing its mechanism, the role of JNDI and LDAP lookups, how malicious payloads are executed, the impact scope, and the remediation steps.

log4j2

Logging is familiar to developers of any language, whether front‑end, back‑end, or client‑side. In the Java ecosystem the most common logging frameworks are log4j2 and logback . The discussion focuses on log4j2.

Typical log statements output variables, for example:

<code>logger.info("client ip: {}", clientIp)</code>

Log4j2 provides a powerful feature called Lookup , which can retrieve additional content when rendering log messages.

A Lookup is an interface; concrete implementations decide where and how to fetch the data, similar to polymorphism in OOP. Log4j2 already ships with many common lookup implementations:

JNDI

JNDI stands for

Java Naming and Directory Interface

. It provides a directory service that maps names to objects, allowing developers to look up resources by name.

Think of it as a dictionary‑like data source: you supply a name and receive the associated object.

LDAP

LDAP stands for

Lightweight Directory Access Protocol

. It is a specialized distributed database optimized for queries, organized in a tree‑like structure similar to a file system. LDAP is often used for centralized authentication.

In simple terms, you send a name to an LDAP server and get back the corresponding data.

Vulnerability Principle

Consider a Java program that logs the User‑Agent header:

<code>String userAgent = request.getHeader("User-Agent");
logger.info(userAgent);</code>

Security best practice: never trust user‑supplied input. The User‑Agent string can contain malicious content.

If an attacker sends a User‑Agent like

${jndi:ldap://127.0.0.1/exploit}

, Log4j2 parses the

${}

expression, treats it as a JNDI lookup, follows the LDAP protocol, contacts the LDAP server at 127.0.0.1, and requests the key

exploit

.

The LDAP module retrieves the data. If the data is a reference to a Java class, JNDI can download the class file from a remote location and instantiate it, leading to remote code execution (RCE).

JNDI can remotely download class files to construct objects!

When the remote URL points to an attacker‑controlled server hosting a malicious class, the attacker gains code execution on the vulnerable host.

This is the classic JNDI injection attack, first disclosed at Black Hat 2016.

Impact Scope

Log4j2 is widely used across Java‑based web applications, backend services, big‑data platforms, and many middleware components such as Kafka, Elasticsearch, and Flink. Any application that logs untrusted input with a vulnerable Log4j2 version can be remotely compromised.

Remediation

The issue has been fixed in newer Log4j2 releases. Upgrade to the latest version immediately.

The official Log4j2 documentation now restricts JNDI lookups:

Disables secondary lookups (naming references) by default. Only classes listed in log4j2.allowedLdapClasses can be loaded. Only LDAP hosts listed in log4j2.allowedLdapHosts or local addresses are permitted.

These measures block the remote class‑loading path.

Check your projects for any use of Log4j2 and ensure that no external data can reach log statements.