Skip to content
article

Log4Shell, four years later: the lesson everyone said they learned and nobody did

it was never about one logging library. it was about not knowing what is inside your software

Nadia Benali@nullbyte_nadia

September 10, 2026 · 2 min read

#1 in Hack The Planet

Contents(3)

Log4Shell (CVE-2021-44228, December 2021) is old news, but I keep seeing the same mistakes it should have cured, so here is the short version and what it was actually about.

what happened

Log4j is a Java logging library that is inside an enormous amount of the world's software. it had a feature where a logged string could trigger a lookup, and an attacker who could get a crafted string logged (a username, a user agent, a chat message) could make the server reach out and run attacker controlled code. the ingredients were: a hugely popular dependency, a dangerous feature on by default, and the fact that logging is the one thing every app does with untrusted input.

this Java Brains video walks through the mechanism for developers without the hysteria, if you want the technical shape of it:

the real lesson

the panic that December was not "patch log4j". it was that most organisations could not answer the question "do we even use log4j, and where". it was buried three dependencies deep in things they bought, things they forgot they ran, vendor appliances they could not patch. the bug was bad. not knowing your own software was worse.

what should have changed

  • an SBOM, a software bill of materials. you cannot patch what you cannot find. know your dependencies, transitive ones included.
  • dangerous features off by default. the lookup feature had no business being on for everyone. secure defaults are worth more than any amount of "best practice" docs.
  • assume your logs see hostile input. anything a user can influence, you are logging, and your logging stack is now attack surface.

four years on, the XZ backdoor (2024) was a different attack but the same root fear: you do not actually know what is running inside the software you depend on. Log4Shell was the industry's chance to fix that and mostly we bought a scanner, ran it once, and moved on. actually, go check if you can answer "where is log4j in our stack" right now. I will wait.

#security#java#open-source#supply-chain

Written by

Nadia Benali

security researcher. bug bounty since 2014, hall of fame on more programs than I can count. web, auth flows, OAuth misconfigs. ex-pentester. Lyon 🇫🇷 DMs open, but not for hacking your ex's instagram.

View profile

Get the best of #hack_the_planet weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.

Comments

6

Sign in to join the conversation.

Sign in to comment
Tomasz Kowalski@tomasz_k1 rep in Hack The Planet
I was oncall that December. We spent two weeks not patching log4j, we spent two weeks finding log4j. A vendor appliance we could not touch, a twelve year old internal tool nobody owned, a build plugin. The SBOM point is the whole post. We still do not have a real one, by the way.
5 net votes
Karl Lindqvist@kernel_karl#2 in Hack The Planet
The feature was on by default because the maintainers, unpaid, added something useful years earlier and the world standardised on their code without ever funding a security review of it. Same structural problem as XZ. The industry runs on volunteers and then acts surprised.
7 net votes
Nadia Benali@nullbyte_nadia#1 in Hack The Planet
this is the thread that connects all of it @kernel_karl. Log4Shell, XZ, the npm stuff, it is all "critical infrastructure maintained by three tired people and funded by nobody". the bug is the symptom.
3 net votes
Omkar Joshi@omkar_java1 rep in Hack The Planet
our bank still had a change freeze fight over patching because "it is stable". stable and vulnerable are not opposites apparently. the audit after was brutal and honestly deserved
5 net votes
Hodan Abdi@hodan_soc#8 in Hack The Planet
the detection side was wild too, every single outbound ldap connection suddenly interesting. we wrote like nine sigma rules that week. good times (they were not good times)
4 net votes
Wolfgang Engel@dsgvo_wolf#6 in Hack The Planet
The SBOM is now increasingly a legal expectation, not only a best practice. The EU Cyber Resilience Act will require manufacturers to know and document what is in their software. Which, as @kernel_karl will tell you at length, lands the cost on the unpaid maintainer again.
2 net votes