Sample article: this is a historical, source-based reading example, not a report of a local reproduction. The sample edition mixes publication dates to demonstrate the interface.
A log line should just be a log line
Applications use logging libraries to record events: a failed sign-in, an unexpected request, or a service error. Many of those messages contain text supplied by somebody outside the application. The security boundary is simple: recording that text should not execute instructions embedded in it.
Log4j 2 supported lookups, a mechanism for substituting values into log messages. In affected versions, a lookup could reach Java's naming service, JNDI. That changed what looked like passive text processing into a potentially active network operation.
The concepts first
JNDI is Java's interface for looking up named resources. Applications can use it with directory services such as LDAP. A directory lookup is not inherently an exploit; the problem is allowing untrusted message content to influence a lookup with dangerous behavior.
Remote code execution means an attacker can cause a target to run code. The consequences depend on the process's permissions, runtime, network access, and configuration. Not every lookup or outbound connection establishes that code execution occurred.
Where the boundary broke
Read the diagram as text
A left-to-right flow through Untrusted text, then Logging call, then Message lookup, then JNDI boundary.
An application receives attacker-controlled text and passes it to an affected Log4j logging path. Message lookup processing interprets the text as an instruction, and a JNDI lookup can reach beyond the application boundary.
The advisory documents affected Log4j 2 releases and version-specific fixes. Runtime and configuration differences matter, so a responsible reproduction must record the exact library version, Java runtime, and logging configuration rather than claim that every Java application is vulnerable.
What this article does not establish
No local exploit was run for this example. There are no execution screenshots or independently verified results. A lab would need an isolated vulnerable application, a controlled directory service, and an observable result that distinguishes an attempted lookup from actual code execution.
Mitigation
Follow the current Apache advisory for your exact release line and upgrade to a supported, fixed release. Early fixes were followed by additional advisories; do not treat an old minimum version mentioned in a historical article as current upgrade guidance.
Inventory transitive dependencies as well as explicitly installed libraries. Restricting outbound traffic is useful defense in depth, but it is not a replacement for applying the appropriate fix.