CVE-2021-44228

This is Log4Shell, and it earns every bit of its 10.0. Log4j2's message-lookup substitution will resolve attacker-controlled JNDI references, so any string an attacker can get logged — a User-Agent, a form field, a chat message — can point the logger at a hostile LDAP endpoint and load remote code. The attacker doesn't need to reach a special endpoint; they just need to get text into a log line, which is almost the entire attack surface of a modern application. Unauthenticated, remote, trivially triggered.

The real-world tempo here was historic: within days of disclosure this went from proof-of-concept to indiscriminate mass exploitation by botnets, ransomware crews, and nation-state actors alike, because the vulnerable component is buried inside a staggering fraction of Java software and the trigger is so easy to smuggle in. The defining difficulty was never understanding the bug — it was that log4j-core hides deep in transitive dependencies, inside appliances and vendor products where operators didn't even know it lived. Note the scoping: this is log4j-core specifically, not log4net, log4cxx, or other Logging Services projects.

This is the canonical case for deep dependency inventory over surface scanning, and it's exactly where we earn our keep. The winning move is answering, across everything we run and everything our vendors ship us, where log4j-core is embedded and at what version — including the transitive and appliance-buried copies that no simple asset scan surfaces. Until an install is confirmed at a fixed release (2.16.0 or the 2.12.2/2.12.3/2.3.1 backports, with 2.15.0 only a partial step), we treat internet-reachable Java services as targets and pair patching with egress filtering to hostile LDAP as virtual patching.