Log4Shell: The December 2021 Bug Hidden in a Logging Library

In December 2021, a vulnerability in a Java logging library called Log4j set off one of the largest emergency responses in the history of the internet. Known as Log4Shell, it allowed an attacker to run their own code on a vulnerable server simply by getting a specially crafted piece of text written to a log. It was rated 10 out of 10 on the standard severity scale, and the library was inside a huge range of products.

What Log4j is

Log4j is an open-source logging library maintained by the Apache Software Foundation. Applications use it to write messages about what they are doing, for example error messages and records of requests. It is used in business software, cloud services, games and countless appliances. Many organisations had it somewhere in their systems without knowing, because it came bundled inside other products.

How the vulnerability worked

The flaw, identified as CVE-2021-44228, existed in versions from 2.0-beta9 to 2.14.1. Log4j supported a feature that let log messages include lookups, special expressions that are replaced with values when the message is written. One lookup type used JNDI, a Java mechanism for fetching resources, which could be pointed at a remote server controlled by the attacker. If an application logged a string containing such an expression, Log4j would reach out to that server, download code and run it.

That made exploitation extremely easy. An attacker only needed to put the string in anything that an application might log: a user name, a search box, a web request header or, in the first widely seen cases, a chat message in the game Minecraft. There was no need to log in or to find a particular bug in the application itself.

Disclosure and timeline

• 24 November 2021. Chen Zhaojun of the Alibaba Cloud security team reported the problem privately to Apache.
• 6 December 2021. Version 2.15.0, containing a first fix, was released.
• 9 December 2021. Details and exploit code became public. Mass scanning and attacks began within hours.
• Following weeks. Versions 2.16.0, which disabled the risky feature by default, then 2.17.0 and 2.17.1 addressed related problems.

Attackers used the flaw to install cryptocurrency miners, build botnets and gain access to networks. Governments and security agencies issued urgent warnings. Many organisations spent the holiday period checking every system.

The hard part: finding it

Patching is simple when you know what to patch. The difficulty with Log4Shell was that nobody had a full list of where Log4j was. It could be a direct dependency of an in-house application, a hidden component of a vendor's product or part of a third-party service. Organisations without an inventory of their software found themselves searching through file systems, and waiting on suppliers to publish fixes. This is the reason the idea of a software bill of materials, a list of what a product is built from, gained momentum.

An open-source sustainability question

The Log4j project is maintained by a small group of volunteers. Many commentators noted that a critical piece of global infrastructure depended on unpaid people who then had to deal with an emergency over a weekend. A US review board later described the vulnerability as an endemic one, expected to remain in systems for years. It added to the argument, begun with Heartbleed, for funding and supporting the projects that everyone relies on.

Does this affect your website?

Log4j is a Java library, so a typical PHP site, such as WordPress, does not use it directly. But some tools around websites do, including search engines like Elasticsearch, some analytics or business applications and various appliances. If you run only a standard CMS on managed hosting, your risk is mostly with your hosting provider's systems. If you run any Java software yourself, you should check it.

The long tail

Years after the disclosure, scanners were still finding unpatched Log4j in the wild. Some of it sat in old appliances that no longer received updates, some in internal tools that nobody owned. This long tail is common to big vulnerabilities: the first wave of patching is fast, and then a stubborn remainder lingers for years. Attackers know this and keep trying old exploits, because some targets are always left.

The practical response is to retire software that cannot be updated. If a product no longer receives security fixes, plan its replacement instead of hoping nobody notices.

The practical lesson for site owners

Keep a simple list of the software your site and server use, including libraries and services, and subscribe to security announcements for each. When a major flaw is announced, you can then answer quickly whether you are exposed. Apply updates fast, remove software that you do not need and place a filtering layer in front of your applications if possible.

On a VPS you control the software stack, so such a list is your responsibility. Our security page covers the protections around it, and the knowledge base has guides for updating server software.