Log4j Exploit: A Technical Deep Dive

Log4Shell affects any application that logs attacker-controlled input through a vulnerable version of the Apache Log4j logging library. The vulnerability is not tied to a single input field — it can be triggered through any field that ends up being written to a log message, such as an HTTP User-Agent header, a URI, a login field, or any custom application field that happens to pass through Log4j.

A critical detail is that this is a two-stage exploit: the initial malicious string being logged does not immediately execute anything. The application first has to make that external callout for the attack to complete. This delay between injection and execution is itself an important defensive control point, discussed later in the prevention section.

It is also important to understand that having Log4j present in an application does not automatically mean that application is exploitable — exploitability depends entirely on how the library is implemented and configured within that specific application. Every real-world attack still has to be customized against each specific vulnerable target.