Log4Shell (Dec 2021): The Vulnerability in Everything

Retrospective: this article looks back at events from December 2021, written in 2026 with the benefit of hindsight.

On December 9, 2021, a critical vulnerability in Apache Log4j 2 — a Java logging library used in countless applications — became public. Tracked as CVE-2021-44228 and nicknamed Log4Shell, it allowed remote code execution simply by getting an application to log a specially crafted string.

Why it was so severe

• Ubiquity: Log4j was embedded in enterprise software, cloud services, appliances, games and internal applications, often several layers deep in dependencies.
• Ease of exploitation: attackers could trigger it through any input that got logged — a web form, a user agent header, a chat message.
• Speed: mass scanning began within hours of disclosure.

CISA's director called it one of the most serious vulnerabilities she had seen. Follow-up vulnerabilities required additional patches over the following weeks.

The response

Organizations faced a basic question many couldn't answer: where do we use Log4j? Vendors published advisories for their products; cloud providers patched their managed services and published guidance. Security teams worked through the holidays.

Why it mattered for cloud teams

Cloud workloads ran Java applications, containers and third-party software containing Log4j. Web application firewalls (Azure WAF, AWS WAF) quickly added rules to block common exploit patterns, buying time — but patching was the only fix.

Lessons in hindsight

• Software bills of materials (SBOMs) help answer "where are we affected?" quickly.
• Dependency scanning in CI/CD and container registries is essential.
• Egress filtering blocked many Log4Shell exploits, which required outbound connections to attacker servers.
• WAF virtual patching buys time but isn't a fix.

The US Cyber Safety Review Board's first report examined Log4j and concluded it would remain an "endemic vulnerability" for years.