CVE-2021-44228 (Log4Shell) — Field Notes from a Focused Web-App Review
Introduction
In late 2021 I revisited one of our Java web applications to validate exposure to Log4Shell. My goal was pragmatic: verify if any user-controlled input was reaching Log4j without strict formatting or filters, and confirm whether JNDI lookups were still enabled at runtime. I approached the review as a short, repeatable exercise the dev team could replicate quickly across services.
Summary of the Finding
The application’s request metadata—specifically HTTP headers and certain form fields—was logged verbatim by Log4j 2.14.1. Because JNDI lookups were enabled in that version, a crafted string using the ${jndi:…} pattern was evaluated during logging. Under default/legacy settings this opened a path to remote lookups and, in unsafe environments, code execution. The risk hinged on two factors: (1) untrusted data reaching the logger, and (2) a reachable naming endpoint (e.g., LDAP/HTTP) that the host could contact.
Reproduction steps (tested on local instance)
Performed only on a local test instance for verification and learning. For information and setup, let’s navigate to my github repository Spring Boot Log4j - CVE-2021-44228