What it is#
exploited a feature of Log4j 2.x where the logger evaluated ${jndi:...} expressions inside any string it logged. An attacker supplying a crafted User-Agent, referer, or form field could trigger an LDAP or RMI lookup against an attacker-controlled server, which returned a classpath entry the vulnerable JVM then loaded and executed. Every layer of the request pipeline that ran Log4j — application servers, WAFs, load balancers — was potentially exploitable.
Why it matters#
became the reference example of a ubiquitous transitive dependency turning into an internet-scale emergency. Patching took weeks because the vulnerable library was buried inside commercial appliances, proprietary JARs, and infrastructure components that teams did not even know shipped with Java on them.
Mitigation direction#
Upgrade to a patched Log4j release and keep your software bill of materials current so the next is a one-query answer, not a two-week inventory. Egress-filter application workloads so even a successful JNDI fetch has nowhere to go. Redact control characters from untrusted data before it reaches any logger.