Java and Log4Shell: why CVE-2021-44228 remains the reference flaw

Why this still matters in 2026

When people ask which CVE best represents dangerous Java security history, CVE-2021-44228 is still the obvious answer. That is not because Java as a language is inherently unsafe. It is because the Java enterprise ecosystem depends heavily on deeply reused components that are often invisible inside the software supply chain.

Log4Shell affected Apache Log4j, a logging library embedded in a huge number of applications and products. Apache still lists it on the official security page as a critical vulnerability with a CVSS 10.0 score.

What made CVE-2021-44228 so severe

The core issue was simple. If an attacker could control data that got logged, vulnerable configurations could trigger JNDI lookups to attacker-controlled infrastructure. In the affected cases, that could lead to arbitrary code execution.

Apache officially documents the vulnerable ranges in log4j-core and the fixed versions for different Java branches.

This flaw was especially dangerous for four reasons:

Why this was an architecture problem, not just a patching problem

Log4Shell exposed a governance weakness. Many teams knew their own codebase, but not their full dependency inventory. In Java, frameworks, starters, app servers, and third-party products often bring deep libraries into production without much visibility.

So the real risk was not the Java keyword. The real risk was a central component that existed almost everywhere.

What Java teams should take away

In 2026, the useful lesson is not only keep Log4j updated. The broader lesson is this.

First, maintain a defensible dependency inventory, including transitive dependencies.

Second, separate the Java code you build from the Java products you expose. Forgotten third-party products are often the slowest to patch.

Third, do not assume that a support library is harmless because it is not handling payment or authentication. A logging library can still become a major entry point.

Our view

If you need one symbolic Java flaw, CVE-2021-44228 is still the strongest reference. Not because it summarizes all of Java, but because it captures the ecosystem risk extremely well: heavy dependence on common components, often deep in the stack, often poorly inventoried.

For an organization, the right question is not is Java dangerous. The right question is which Java components are we really running, which of them are exposed, and how quickly can we prove they are fixed.