Everyone remembers patching Log4Shell. Few built the thing that would make the next one easy.

In the second week of December 2021, a lot of teams patched Log4Shell, exhaled, and moved on. Then they had to do it again. The original Log4Shell fix, Log4j 2.15.0, turned out to be incomplete, and CVE-2021-45046 is the bug that proved it. Its severity was initially pegged at 3.7, a limited denial of service, then revised up to 9.0 when researchers showed it could also yield remote code execution in certain non-default configurations. Version 2.16.0 followed. Then CVE-2021-45105 found a denial-of-service hole in 2.16.0, so 2.17.0 followed. Then 2.17.1. In roughly two weeks, “patch Log4j” meant patching it three or four times.

That cascade is the part of the Log4Shell story worth re-examining, because most organizations took away the wrong lesson from it.

What the bug is

CVE-2021-45046 is a deserialization/lookup flaw (CWE-917) stemming from the incomplete fix of the original Log4Shell, CVE-2021-44228. The 2.15.0 patch reduced but didn’t eliminate the danger: where the logging configuration used a non-default Pattern Layout with a Context Lookup or Thread Context Map pattern, an attacker who controlled Thread Context Map (MDC) input could still craft a JNDI lookup and achieve remote code execution. It affects Log4j 2.0.1 through 2.15.x. The real fix arrived in 2.16.0, which removed message-lookup support and disabled JNDI by default, the kind of decisive default change that should arguably have been there all along. CISA added CVE-2021-45046 to the Known Exploited Vulnerabilities catalog on May 1, 2023, with the ransomware flag.

The lesson most people skipped

The popular memory of Log4Shell is about speed: the frantic all-hands weekend, the heroics of patching fast. Speed mattered. But the cascade exposed two harder truths that got less attention, and both are still unaddressed in a lot of organizations.

The first: an emergency patch shipped under extreme pressure is frequently incomplete. The 2.15.0 fix was made in days, by maintainers under enormous scrutiny, and it still missed attack paths. That’s not a knock on the Log4j team; it’s the nature of rushed fixes. The operational consequence is that “we applied the first patch” is not a safe stopping point during a fast-moving vulnerability event. You have to keep watching for the follow-up CVE and the patch-the-patch, because the first version released is the one most likely to be revised. Teams that closed the ticket at 2.15.0 were exposed by 45046 and didn’t know it.

The second, and the one that actually determines how much the next Log4Shell hurts: the hard part was never applying the patch. It was finding everywhere Log4j was. Log4j is a transitive dependency, buried inside Java applications, vendor appliances, and products whose developers may not even have listed it directly. Organizations spent weeks not patching but hunting, grepping JARs, querying vendors, scanning for the library nested three dependencies deep inside something they bought. And every time the fixed version changed, from 2.15 to 2.16 to 2.17, they had to re-find and re-patch the same sprawling, poorly-mapped footprint. The pain of the cascade was multiplied by the fact that nobody had an inventory of where the dependency lived.

That’s the lesson worth keeping: the teams that suffered least in the next dependency crisis were the ones who, after Log4Shell, built the capability to answer “where is this library in our environment” in hours instead of weeks. Most organizations celebrated surviving Log4Shell and never built it.

What to do

• For Log4j specifically, get to a current fixed version. 2.17.1 or later resolves the full cascade (44228, 45046, 45105, and the later 44832). If anything in your environment is still on 2.15 or 2.16, it’s only partway through the fix. Check vendor products too; embedded Log4j is where stale versions hide.
• Build a software dependency inventory now, before the next one. A software bill of materials (SBOM) practice, and tooling that can search your estate for a given library and version, is the single highest-value thing to come out of Log4Shell. The next ubiquitous-dependency bug is coming; the question is whether you’ll spend weeks finding it or hours.
• During fast-moving events, don’t close the ticket on the first patch. Track the advisory for follow-up CVEs and revised fixed versions. Build the expectation of a cascade into your incident process for emergency patches.
• Prefer decisive default changes over configuration band-aids. The thing that actually fixed Log4j was 2.16.0 disabling JNDI by default. When you have the choice, the safe default beats relying on every team to set the right flag.

The reframe is uncomfortable for anyone who filed Log4Shell under “handled.” The event wasn’t really a test of how fast you could patch; it was a test of whether you knew what you were running, and most organizations failed that test and then forgot they’d taken it. CVE-2021-45046 is the proof that the patching itself was the easy, repeatable part, and that the cascade was painful only because the footprint was a mystery each time. Build the inventory. The next library that turns out to be everywhere will give you days, not weeks, and you’ll want to already know where it is. We track the dependency and patch-bypass entries closely, because those are the events where knowing your own environment matters more than how fast you can deploy a fix.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2021-45046 — 2021-12-14
• Apache Log4j Security Advisories
• LunaSec: Severity of CVE-2021-45046 increased from 3.7 to 9.0 — 2021-12
• GitHub Advisory: Incomplete fix for Apache Log4j vulnerability (GHSA-7rjr-3q55-vv33) — 2021-12
• Rapid7: Widespread exploitation of critical RCE in Apache Log4j — 2021-12