CISA Orders Federal Agencies to Patch Log4Shell — And Apache Ships a Third Fix
CISA issued an emergency directive on Log4Shell as Apache released its third Log4j patch in under two weeks.
If you work in IT and thought this week might be a quiet one before the holidays, Apache had other plans. Today they shipped Log4j 2.17.0, patching CVE-2021-45105 — the third fix to this library in a little under two weeks. First there was 2.15.0, addressing the original Log4Shell flaw. Then it turned out that patch was incomplete, so we got 2.16.0 for CVE-2021-45046. Now 2.17.0 closes a denial-of-service issue that could let an attacker craft malicious input to trigger uncontrolled recursion and crash an application. It’s not remote code execution this time, but after the month we’ve had, nobody’s taking chances.
On top of that, CISA (the U.S. Cybersecurity and Infrastructure Security Agency) issued Emergency Directive 22-02 this week, ordering federal civilian agencies to patch or otherwise mitigate Log4Shell across their systems. That’s about as serious as it gets in government IT — emergency directives are reserved for vulnerabilities CISA considers an active, significant threat, and they come with mandatory deadlines rather than gentle suggestions.
Why this keeps happening
Log4j isn’t some obscure library. It’s baked into an enormous number of Java applications, frameworks, and cloud platforms, often several layers deep in a dependency tree that most application owners have never fully mapped. That’s the real story here, more than any single CVE: organizations are discovering, in real time, that they don’t actually know everywhere this library lives inside their stack. You can’t patch what you can’t find, and a lot of security teams have spent the past week just doing inventory — grepping through JAR files, querying vendors, and hoping their asset management tooling is more complete than they feared.
Three patches in under two weeks is also a reminder that emergency fixes under public pressure don’t always get it right the first time. Nobody should be surprised that 2.15.0 needed a follow-up — when you’re rushing a fix for a vulnerability that’s already being mass-exploited, you’re optimizing for speed over completeness. The pattern of finding edge cases after the fact is normal for any complex piece of software; it’s just unusually visible here because of how much scrutiny Log4j is under.
If your organization runs Java services and hasn’t gotten to 2.17.0 yet, this is the version to target — not 2.16.0, not 2.15.0. And if you’re not sure whether Log4j is even in your stack, that uncertainty is itself the finding you need to report up the chain. Expect this saga to keep echoing into next year, too: there’s already talk in security circles about whether incidents like this should push the industry toward requiring software bills of materials, so nobody has to play detective the next time a foundational library turns out to be a liability.