The Log4j Vulnerability — Who Finds the Part Buried in the Wall?

One Logging Component

On November 24, 2021, a security engineer on the Alibaba Cloud security team in China sent an email to the Apache Software Foundation (ASF), a non-profit corporation. It was a report that a vulnerability had been found in Log4j, software looked after by the foundation (U.S. Cyber Safety Review Board report). The security page of the Apache Logging Project in question identifies the discoverer as Chen Zhaojun of this team (Apache Logging Project security page). A vulnerability is, as stated in "Security — Unseen by Others, Unchanged in Secret, Open When Needed", a weak spot in a system where an attacker can dig in and make the software do things its creators never intended. This report would become, a few weeks later, an incident involving thousands of security professionals around the world all at once (U.S. Cyber Safety Review Board report).

Log4j is a logging framework built in a programming language called Java, collecting and managing information about activities that happened in a system (U.S. Cyber Safety Review Board report). It is a component in charge of writing down what happened while a program was running—in other words, logging. Open-source is software whose creators make the code public so anyone can read, use, and modify it. Log4j is also open-source. Log4j was easy to use, free to download, and did its job well, earning popularity among Java developers. Developers embedded it inside thousands of other software packages (U.S. Cyber Safety Review Board report).

A library is a bundle of code made so that multiple programs can borrow and plug in the same function instead of writing it from scratch. Log4j is that kind of component. It is similar to buying and attaching standardized hinges when building a house instead of carving them by hand. A dependency is another software component that a program includes and uses inside itself to run properly. When you plug in a library, that library becomes a dependency of that program. According to the board report citing figures from the security firm Sonatype, Log4j was downloaded 28.6 million times during the three months from August to November 2021, and nearly 7,000 open-source projects were using Log4j as a dependency by December 14, 2021 (U.S. Cyber Safety Review Board report).

This component was cared for by a group of volunteers. They maintained Log4j as a project under the foundation, and the foundation is a non-profit corporation supporting that project (U.S. Cyber Safety Review Board report). Log4j version 2 was first released in 2012. In 2013, before the official version came out, the project team went through standard procedures to accept a community-suggested feature intended to make data storage and retrieval easier, reviewing and reflecting that feature in the code on July 18 (U.S. Cyber Safety Review Board report).

The public documents followed by this article are six. The central document is the report issued in July 2022 by the Cyber Safety Review Board (CSRB). This board is a government-affiliated body established by executive order of President Biden that makes recommendations to the Secretary of Homeland Security, and among the 15 members of this initial review, 8 belong to federal agencies and 7 come from private companies and non-profit organizations. The board states itself to be an "independent review", noting that it is not an enforcement or regulatory agency and does not assign blame. The review was requested by the Director of the Cybersecurity and Infrastructure Security Agency (CISA) of the United States, and there are members from CISA on the board as well (U.S. Cyber Safety Review Board report). CISA is the cybersecurity agency of the U.S. government, and its response guidance is the second document. The remaining four are documents from the Apache side involved: the foundation notice (December 14, 2021), the February 2022 U.S. Senate testimony by foundation president David Nalley, the 2021 security report by foundation vice president of security Mark Cox, and the logging project security page which is still updated and used today. This article traces events that took place overseas, following documents from the U.S. government and Apache.

Because it was a small, free component that did its job well, Log4j slipped inside the walls of countless programs.

Sixteen Days From Report to Release

The foundation judged that because Log4j was so widely used, postponing the disclosure of vulnerability information was unrealistic (Cyber Safety Review Board report). The foundation reviewed the fix code in a public repository where anyone could see it as early as November 29, incorporated the fix on December 5, and released a release candidate on December 6. It did not issue a security advisory at that time (Cyber Safety Review Board report). Here, the board points out a characteristic of open source. Because projects like Log4j develop their code in public places, security fixes are also visible to others while they are being made (Cyber Safety Review Board report). According to the board's observation, open-source projects may need to begin public announcements and responses simultaneously with fixes.

On December 9, an Alibaba engineer emailed the foundation again. The message stated that this vulnerability was being discussed on the Chinese messenger WeChat. The Chinese security firm that posted that writing did not answer the board when asked how they knew. The board wrote that the hypothesis that they or someone related discovered the vulnerability from the release candidate is "reasonable," though it could not confirm it (Cyber Safety Review Board report).

The foundation released version 2.15.0, which fixed the issue, on December 10, earlier than originally planned, and the common vulnerability identifier CVE-2021-44228 was also published on the same day (Cyber Safety Review Board report). A fixed version, in other words, a patch as mentioned in "Security — Unseen by Others, Unchanged in Secret, Open When Needed", is a revised version that fixes a vulnerability in an already released program and distributes it again. The board report separately records the day the vulnerability was exposed to the world as December 9 and the day the fixed version was officially released as December 10. One measurement study introduced below sets the disclosure date as December 10 and calls this vulnerability Log4Shell (DOI: 10.1109/tnsm.2024.3440188).

The National Institute of Standards and Technology (NIST) vulnerability database assigned this vulnerability the maximum severity score of 10.0. This means the attack is not complex, requires no privileges, and does not require the user to click anything (Cyber Safety Review Board report). CISA wrote that unauthenticated remote actors could take over systems affected by this vulnerability (CISA response guidance). The president of the foundation testified that a feature added to Log4j in 2013 interlocked with a part of the Java runtime environment to expose this flaw, and the flaw had lain dormant for several years (Apache Foundation President Senate Testimony). As a result, if a specific instruction was hidden within text handed over to the program to record, it could follow that instruction to call and execute code from the outside (arXiv:2407.00246, preprint). Any service using this library that opened a window toward the internet was potentially vulnerable (DOI: 10.1109/tnsm.2024.3440188). A single component of a vulnerable version could become a window facing outward for a service that used it.

The 18 Days That Produced Three More Fixed Versions

It did not end with the version from December 10. After the disclosure, researchers successively found additional vulnerabilities, and the foundation released repeated versions (U.S. Cyber Safety Review Board Report). On December 13, version 2.16.0 came out (Apache Foundation Notice), and the second vulnerability disclosed the next day (CVE-2021-45046) was fixed in this version. On December 18, a vulnerability that could halt services was fixed in 2.17.0, and the December 28 disclosure was fixed in 2.17.1 (U.S. Cyber Safety Review Board Report).

The weight of the second vulnerability changed within documents from the same party. The December 14 foundation notice stated that version 2.15.0 had fixed the most severe vulnerability, but the fix was incomplete in some non-default settings, allowing attackers to conduct a denial-of-service attack, which is an attack that stops services (Apache Foundation Notice). The logging project's current security page lists the same vulnerability as remote code execution, with a severity of "9.0 CRITICAL" (Apache Logging Project Security Page). The board also recorded this as a remote code execution vulnerability (U.S. Cyber Safety Review Board Report). The assessment in the initial notice was raised later.

The fixed versions were sometimes split into different branches depending on the Java version. The first vulnerability was fixed separately in versions for Java 6, Java 7, and Java 8 or higher (Apache Logging Project Security Page). The version that the December 14 foundation notice listed for Java 7 was 2.12.2 (Apache Foundation Notice), but on December 28, CISA urged upgrades to 2.17.1 for Java 8, 2.12.4 for Java 7, and 2.3.2 for Java 6 (CISA Response Guidance). Even for systems running the same Java 7, the version to upgrade to changed within the span of two weeks. The board noted that as additional vulnerabilities followed rapidly, confusion and "patch fatigue" grew, and organizations had to keep up with new information in real-time about which version to upgrade to (U.S. Cyber Safety Review Board Report).

The foundation's president stated in the Senate that a complete solution arrived about two weeks after reporting (Apache Foundation President Senate Testimony). Following the same period with the dates from the board report and CISA guidance, December 28, when the final version was released, is about five weeks after the reporting date of November 24. The two counts diverge depending on which version is considered the "complete solution." For those who had to follow the versions one by one, the fixed versions did not arrive all at once.

When Did the Attack Begin

The earliest known exploitation is activity observed by a technology services company over two days starting December 1. A proof of concept is trial code created to show that a vulnerability actually works. That company assessed that this activity matched the testing of a proof of concept by an Alibaba engineer (US Cyber Safety Review Board report). After reviewing classified and unclassified government information and industry data, the Board found no evidence that anyone, including Chinese, Iranian, North Korean, or Russian actors, actually exploited it further before the public disclosure on December 9 (US Cyber Safety Review Board report).

Accounts from the parties involved sound different. The foundation security report stated that this vulnerability was widely exploited starting the day before the patched version was released (Apache Foundation 2021 Security Report). Based on the December 10 version, the day before was December 9, which matches the date the Board recorded as the disclosure date. Thus, the two documents do not conflict in dates. The pictures, however, differ. In the Board records, the only activity confirmed before disclosure as pre-disclosure is those two days matching testing. Moving December 1 to "the day the attack began" strips away the Board's caveat that the activity matched testing.

After disclosure, it was fast. One technology services company saw a surge in scans looking for this vulnerability in under two hours after disclosure, and five days after disclosure, internet company Cloudflare observed 400 exploitation attempts per second. Both are observations by companies cited in the Board report (US Cyber Safety Review Board report). The scanning side did not consist only of attackers. Researchers and security teams also generated many scans, making it hard to distinguish from malicious activity, and security company Akamai assessed that about 57% of exploitation activity observed in the first week of disclosure came from known malicious actors. This is also an assessment cited in the Board report (US Cyber Safety Review Board report).

The same trend appeared in measurements that closely tracked the two months following disclosure across multiple observation points, followed by another year. The scans that rushed in immediately after disclosure quickly subsided, but surged again in waves throughout 2022; benign scanners showed interest only in the first few days, while malicious scanners continued to target this vulnerability. At those observation points, the majority of malicious activity appeared to come from a single entity (DOI: 10.1109/tnsm.2024.3440188). Results measured until October 2025 using an observation network based in India also showed that activity targeting this vulnerability persisted for years, converging onto an increasingly small number of recurring infrastructure. This result matches the timeline of a previous study, but shows systematic differences due to the location and scope of the observation points (arXiv:2601.04281, preprint). In the observation networks of both studies, the commotion in the first week of disclosure was created jointly by defenders and attackers, and the side that remained after the commotion subsided was the attackers.

What happened next was transcribed by the Board from observations by security companies. A cybersecurity company investigated several ransomware incidents utilizing this vulnerability between January and March 2022. Ransomware is malicious code that renders files unusable—such as by encrypting them—and demands money in exchange for restoring them, as discussed in "Phishing and Social Engineering — Ringing the Doorbell Instead of Breaking the Lock". Researchers at security company Check Point observed state-sponsored actors exploiting this vulnerability, and exploitation by the internet-of-things botnet Mirai was also reported (US Cyber Safety Review Board report). The Board did not attribute these incidents to specific actors.

There Was No List to Tell Where It Was Inside

On December 13, CISA Director Jen Easterly said that this vulnerability was "one of the most serious that I've seen in my career, if not the most serious." Tens of thousands of security professionals around the world moved simultaneously to find and block hundreds of millions of devices that may have been affected (US Cyber Safety Review Board Report). Hundreds of millions is the number of potentially affected devices.

The search was blocked first. The Board determined that defenses were hindered by the fact that there was neither a comprehensive "customer list" for Log4j nor a list of where it was embedded as a subsystem. Companies and vendors scrambled to find where they used Log4j (US Cyber Safety Review Board Report). The Board gave two reasons. Log4j is routinely embedded inside other software components, so those running the steps or systems built on top of it often do not even know it exists, and it is difficult to find with common search methods. And as is industry practice, the Log4j team and the Foundation neither manage nor know who uses that software or how it is ultimately used (US Cyber Safety Review Board Report). What the Board pointed out as hindering defense was the fact that there was nowhere a list to tell where that component was inside.

Even when found, it was often impossible for users to fix on their own. CISA guided that vulnerabilities in products and services containing Log4j are fixed when the makers of those products reflect security updates, and users must look for the vendors' security updates (CISA Response Guidance). The Board noted that many organizations relied on vendors' responses to understand and fix the vulnerabilities, and some remained worried even after vendors announced fixes due to the interdependence between programs and components. Installing the fixed version itself was also a decision weighing risks. This was because they had to choose between the risk that operations could stop, fixing quickly and completely, and supplementary measures to use in the meantime (US Cyber Safety Review Board Report).

The cost was paid in time. One federal department reported spending 33,000 hours on Log4j response to protect its network. The response, lasting weeks and months, delayed important work including responses to other vulnerabilities, and the Board noted that it caused burnout among defense personnel, which could affect staff attrition in the long run (US Cyber Safety Review Board Report).

CISA issued a statement on December 10 and placed this vulnerability on the "Known Exploited Vulnerabilities" list the same day. On December 13, it opened a public repository collecting a list of vulnerable products and components along with a web page, helping responders figure out where Log4j was in their environments. On December 17, it issued an emergency directive requiring federal civilian agencies to respond within two weeks (US Cyber Safety Review Board Report). The Board evaluated that many things were done "properly": the Foundation's established development process, coordinated disclosure, rapid patching, and quick guidance from the government and vendors. Even so, organizations struggled, and many organizations have not yet fixed all vulnerable Log4j, the Board noted (US Cyber Safety Review Board Report). This evaluation of the government's response is that of a Board commissioned by the CISA Director and including CISA members.

There is also the Board's interpretation of 2013, when the flaw was introduced. If someone with a good understanding of security impact had closely reviewed it when adding that feature, they might have found the unintended feature, namely the vulnerability, but the Board judged that the volunteer developers leading this project in 2013 did not have the resources to conduct such a review. Foundation developers told the Board that automated security testing would not have caught this vulnerability, but a broad code audit might have found it (US Cyber Safety Review Board Report). The Board noted that open-source developers are usually not paid for maintenance, especially older versions embedded deeply and widely, citing Log4j as an extreme case. The Board's conclusion is that this volunteer-based community needs sustained financial support and expertise to pull off industry-standard secure coding and expert audits (US Cyber Safety Review Board Report).

The parties involved also documented their own circumstances. According to a Foundation security report, the Foundation's security team and project management team are both volunteers and do not promise official deadlines for handling issues, and the security reporting channel is handled by a very small number of volunteers drawn from various projects. The same report notes that while the Foundation usually releases patches for critical issues quickly, users are attacked by older issues they have not updated for years, and vendors use older versions with unfixed known vulnerabilities even after support ends (Apache Foundation 2021 Security Report). The Board is an organization that stated it does not assign blame, and it described the causes in terms of review resources and the structure of users rather than an individual's mistake.

Parts Within Parts

There is a tally showing that the average Java application in 2022 depended on 40 external libraries (DOI: 10.1109/saner56733.2023.00028). This is where the structure begins in which you no longer know where your parts are located. Indirect dependencies are parts that a part you deliberately chose brought along tucked inside itself. Developers directly determine the parts they choose and their versions, but they do not choose indirect dependencies directly, and changing them requires separate effort. Such indirect dependencies are often greater in number than the ones chosen directly (arXiv:2310.07847, preprint — a study of the JavaScript ecosystem).

Vulnerabilities enter by that route as well. Among roughly 4 million versions in the Java component repository Maven Central, only about 1% had vulnerabilities directly, but about 46.8% of versions were affected by vulnerabilities through indirect dependencies (DOI: 10.1109/msr66628.2025.00063). This figure counts not only Log4j, but known vulnerabilities in general. The authors' interpretation is that when a small number of vulnerable parts are used heavily, a wide portion of the ecosystem is affected.

Evidence on the other side came from the same ecosystem. In another study examining 3 million Maven packages, about one-third of the packages were caught as vulnerable only when accounting for indirect dependencies. Yet packages with a path where calls actually reach the vulnerable code within the dependency accounted for less than 1% of the total, which is far fewer than counted by looking at the dependency list alone (DOI: 10.1109/saner56733.2023.00028). Having a vulnerable part inside the house and that part's weak spot being reachable from the outside are different matters. However, to screen for that, you must first know where the parts are.

We trace this structure from the position of a single company. That company never chose Log4j; it simply used a product bought from a vendor. If Log4j was contained within a part inside that product, the company is likely in the "later stages" mentioned by the board, making its existence easy to miss (U.S. Cyber Safety Review Board report). Even when the fixed version of Log4j came out on December 10, the Log4j inside that company's system remains unchanged. This is because the maker of that product must reflect the update for it to be fixed (CISA guidance). The fixed version must start from the part inside the wall, pass through the parts and products wrapping it, and emerge outward one step at a time to reach that company.

Why It Stays Even When a Fixed Version Comes Out

The fixed version can get stuck at each step. On the vendor product side, the board noted agencies' reliance on vendors, while among open-source components, a preprint showed that blockage in numbers. According to that preprint, even when fixed versions come out immediately after a vulnerability is disclosed, libraries and applications in the Maven ecosystem keep using vulnerable versions, and the authors wrote that Log4j was still heavily affecting the Maven ecosystem even as of 2023. The authors showed that fixed versions blocked by upper-level libraries were the cause of this persistence, and also proposed a tool that automatically lifts blocked version ranges (arXiv:2308.03419, preprint). This means that if an upper-level component does not bump its version, projects below it struggle to move to a fixed version.

There was also a delay in Java projects updating Log4j, and projects that release versions more frequently tended to fix serious security issues faster (arXiv:2504.09834, preprint). Even older versions remain. Version 1 of Log4j reached end-of-life in 2015, and vulnerabilities reported for version 1 since August 2015 are neither checked nor fixed (Apache Logging Project Security Page). Yet the foundation stated it knows that version 1 is still used as a dependency by some applications (Apache Foundation Notice), and there are also analyses that version 1, whose support has ended, is still in use (arXiv:2504.03167, preprint). Documents differ in how they weigh version 1. The board separately noted a remote code execution vulnerability affecting version 1.2 (Cyber Safety Review Board Report), whereas the logging project in question writes that version 1 lacks a certain feature found in version 2, making its risk lower (Apache Logging Project Security Page). However, other vulnerabilities in version 1, whose support has ended, are no longer fixed either.

Delays are also common in studies measuring vulnerabilities overall, not just Log4j. In the aforementioned Maven Central study, the time it took to fix vulnerabilities, including those of high or critical severity, commonly spanned several years (DOI: 10.1109/msr66628.2025.00063). Across open-source projects in multiple languages, vulnerable dependencies were indirect dependencies in most languages, and critical vulnerabilities remained for an average of over a year before being fixed (DOI: 10.1109/issre62328.2024.00020). Bumping versions also carries burdens. Among security patches in seven ecosystems, 13.2% indicated via their version numbers that they might not be compatible with previous versions (DOI: 10.1109/tse.2022.3181010). In Log4j, fixed versions came out three more times within 18 days, and the board noted that installing the fixed version itself was a risk decision between operational downtime and speed (Cyber Safety Review Board Report).

An endemic-like vulnerability is a vulnerability that does not disappear all at once after a fixed version is released, but lingers for a long time in various parts of system. The board judged Log4j to be precisely such a vulnerability, and predicted that vulnerable Log4j would remain in systems for several years, perhaps more than a decade (Cyber Safety Review Board Report). The president of the foundation in question also testified that because Log4j is used almost everywhere, it could take months or years for all deployed vulnerable instances to disappear (Apache Foundation Senate Testimony). On April 8, 2022, CISA revised its guidance, noting that agencies should continue to find and fix vulnerable Log4j and plan for long-term vulnerability management. It was a recommendation to include custom-developed software and systems not exposed to the internet, as initial information might have been lacking so that only some assets were checked (CISA Response Guidance). What documents and research point to as the reason vulnerabilities remain even when a fixed version comes out is the chain of components and the burden of bumping versions.

Where Was the Bill of Materials?

In May 2021, roughly half a year before the Log4j incident, the U.S. White House issued an executive order to raise software supply chain security, bringing one measure into widespread awareness (DOI: 10.1145/3664476.3669975). Much like keeping a list of materials used when building a house, the idea is to keep a list of parts for software. A Software Bill of Materials (SBOM) is a list detailing which parts of which versions are inside a piece of software. While the board noted that SBOMs should theoretically allow organizations to find vulnerable parts in their own environments, it wrote that none of the representatives from organizations using SBOMs whom the board heard from reported using an SBOM to find the vulnerable Log4j. The board's judgment is that current SBOMs have limitations, such as inconsistent item labeling and missing version information for parts (U.S. Cyber Safety Review Board Report).

The foundation president told the Senate that ideas like an SBOM do not block vulnerabilities, but can speed up finding vulnerable software to limit the impact. He added that the ability to quickly update to the latest version remains a major hurdle for the software industry (Apache Foundation President Senate Testimony).

Research points to this list still being rare and incomplete. SBOM adoption in public GitHub repositories was low but growing, and actual SBOM files were obtainable for less than half of them (DOI: 10.1109/icsme58846.2023.00016). Running SBOM tools on small sample projects in four languages showed that no tool fulfilled all requirements, and many tools failed to completely list parts and dependencies (DOI: 10.1145/3664476.3670926). Evaluating four open-source SBOM tools using Log4j as a test case, the tools revealed that the part was included and that such a vulnerability existed, but failed to determine whether it actually reached that code (arXiv:2609.05380, preprint).

As one of its recommendations, the board wrote to improve SBOM tools and adoptability (U.S. Cyber Safety Review Board Report). A bill of materials can speed up finding, but it does not do the fixing for you.

How Much Damage Was Done Is Still Unknown

CISA wrote that it was responding to "active and widespread exploitation" of this vulnerability (CISA Response Guidance), and the foundation's security report wrote that it had been "widely exploited" (Apache Foundation 2021 Security Report). The board gives a different account regarding the scale of the harm. The board wrote that as of its drafting in July 2022, it was not aware of any significant attacks targeting critical infrastructure using Log4j. And somewhat surprisingly, it added that it was difficult to reach this conclusion, judging that exploitation was generally lower than many experts had anticipated given the severity of the vulnerability (Cybersecurity Safety Review Board Report).

The board also noted these circumstances: there is no authoritative source to show the trend of exploitation across regions, industries, and the ecosystem; many organizations do not separately collect information on Log4j exploitation; and reporting is largely voluntary. There is also no central repository that collects Log4j-related breach information (Cybersecurity Safety Review Board Report). To the question of how many systems were affected, the foundation replied that it only knew it was present in the foundation's projects, other open-source software, and various products, and that any number beyond that would be pure guesswork and grossly inaccurate (Apache Foundation Announcement).

The board also disclosed the limitations of its own review. It could not reach every sector during the 90 days, medical devices, the Internet of Things, and home network equipment may have had a different experience, and organizations outside the United States may have experienced this incident differently. And the board wrote that this incident is not over (Cybersecurity Safety Review Board Report). The earlier 400 requests per second and the wave of measurement studies counted attempts, and none of the documents followed by this article counted how many of those attempts became actual breaches. Attack attempts could be counted, but the actual damage has not been authoritatively counted anywhere.

Significance

The day a fixed version came out was the day the search for where those parts were located began. The first recommendation the committee made points in the same direction. It is that organizations must prepare for the Log4j vulnerability for many years to come. The committee also issued recommendations to increase open-source security investments and to pilot maintenance support for open-source software used in critical services (U.S. Cyber Safety Review Board Report).

The same blank space is visible on the research side. When the authors mapped the threat intelligence reports of the three incidents they grouped as supply chain attacks—SolarWinds, Log4j, and xz—against ten software supply chain security frameworks, the task of sustainable open-source software was missing from all ten frameworks. The authors concluded that even if organizations follow all the recommended tasks, software products will still remain vulnerable to such attacks (arXiv:2503.12192, preprint).

The questions of who provides the money and people to protect foundational software, and what comes after failing to fix known vulnerabilities, continue from "Heartbleed and OpenSSL — When One Bounds Check Was Missing" and "The Equifax Breach — After the Theft of Data No One Chose to Hand Over". What we still do not know is clear. It is how many household doors this single day actually opened, and how many vulnerable parts will remain inside the walls years from now. The basics of patches and defense-in-depth lie in "Security — Unseen by Others, Unchanged in Secret, Open When Needed".

Case Materials

• "Review of the December 2021 Log4j Event" (2022-07-11) — https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf — A post-incident review by the U.S. Cyber Safety Review Board (a government-affiliated committee established by presidential executive order, comprising 8 federal and 7 private-sector members, commissioned by the CISA Director). It covers the timeline, attack observations (citing security firm data), cause analysis, SBOMs, estimates and limitations of the damage scale, and recommendations.
• "Security :: Apache Logging Services" (Continuously updated, version retrieved 2026-10-18) — https://logging.apache.org/log4j/2.x/security.html — Apache's logging project vulnerability advisory, detailing affected versions, fixed versions, severity, and discoverers by CVE. No date given.
• "Apache Log4j Vulnerability Guidance" (Dated 2022-04-08, updated 2021-12-28 and 2022-04-08) — https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance — CISA response guidelines. Covers widespread exploitation, recommended versions, incorporating vendor updates, and long-term management.
• "Apache Log4j CVEs" (2021-12-14) — https://news.apache.org/foundation/entry/apache-log4j-cves — Notice from the Apache Software Foundation. Covers the list of CVEs at the time, the incompleteness of the 2.15.0 fix, the use of version 1, and answers regarding the scale of impact.
• "Foundation Statement at 8 February 2022 Senate Committee hearing on Homeland Security and Government Affairs" (2022-02-08) — https://news.apache.org/foundation/entry/foundation-statement-at-8-february — Testimony by David Nalley, President of the Apache Software Foundation, before the Senate committee. Covers the 2013 feature and its latency, the solution about two weeks later, a timespan of months and years, and SBOMs.
• "Apache Software Foundation Security Report: 2021" (2022-01-10) — https://blogsarchive.apache.org/foundation/entry/apache-software-foundation-security-report2 — Annual report by Mark Cox, Vice President of Security at the Apache Software Foundation. Covers widespread exploitation starting the day before the patched version, the reality of volunteer operations, and the use of end-of-life older versions.

Source Papers

• "The Log4j Incident: A Comprehensive Measurement Study of a Critical Vulnerability" (2024) — DOI: 10.1109/tnsm.2024.3440188 — Measured from the public release date (December 10) across multiple observation points. The initial scanning rush quickly subsided, but waves continued throughout 2022; harmless scanners appeared only in the first few days, malicious scans persisted, and most malicious activity came from a single actor.
• "A Longitudinal Measurement Study of Log4Shell Exploitation from a Reactive Network Telescope" (2026) — arXiv:2601.04281 (preprint) — Indian observation network, December 2021 to October 2025. Exploitation activity persisted for several years and concentrated in a small number of recurring facilities. Systematic differences according to observation points.
• "SBOM.EXE: Countering Dynamic Code Injection based on Software Bill of Materials in Java" (2024) — arXiv:2407.00246 (preprint) — Log4Shell is a case where handling malicious input during execution led to remote code execution. Proposed an allowlist-based defense.
• "On the Effect of Transitivity and Granularity on Vulnerability Propagation in the Maven Ecosystem" (2023) — DOI: 10.1109/saner56733.2023.00028 — Average Java app had 40 external libraries in 2022. Out of 3 million Maven packages, roughly one-third are caught as vulnerable only when looking at indirect dependencies, and calls reaching the vulnerable code account for less than 1%.
• "Dependency Practices for Vulnerability Mitigation" (2023) — arXiv:2310.07847 (preprint) — Developers cannot control the dependencies of their dependencies, and indirect dependencies are frequently more numerous than direct dependencies (npm).
• "The Ripple Effect of Vulnerabilities in Maven Central: Prevalence, Propagation, and Mitigation Challenges" (2025) — DOI: 10.1109/msr66628.2025.00063 — Out of about 4 million versions, direct vulnerabilities are about 1%, and indirect vulnerabilities are about 46.8%. Fixing them commonly takes several years, and some continue to use vulnerable versions.
• "Mitigating Persistence of Open-Source Vulnerabilities in Maven Ecosystem" (2023) — arXiv:2308.03419 (preprint) — Even when fixed versions come out quickly, vulnerable versions persist (Log4j example), quantifying that patches blocked by upstream libraries are the cause. Proposed an automated version range recovery tool.
• "Mining for Lags in Updating Critical Security Threats: A Case Study of Log4j Library" (2025) — arXiv:2504.09834 (preprint) — There is a delay in updating Log4j in Maven, and projects that release versions frequently resolve critical security issues faster.
• "Do Developers Depend on Deprecated Library Versions? A Mining Study of Log4j" (2025) — arXiv:2504.03167 (preprint) — End-of-life Log4j version 1 is still being used.
• "A Comprehensive Study on the Impact of Vulnerable Dependencies on Open-Source Software" (2024) — DOI: 10.1109/issre62328.2024.00020 — About 1,000 projects across multiple languages. Vulnerable dependencies are mostly indirect, and critical vulnerabilities remain for an average of over a year.
• "Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages" (2022) — DOI: 10.1109/tse.2022.3181010 — 4,377 security advisories across seven ecosystems. Security patch versions have a median of 4 days, with 13.2% indicating broken compatibility via version numbers.
• "SBOM Ouverture: What We Need and What We Have" (2024) — DOI: 10.1145/3664476.3669975 — SBOM popularity grew due to the White House executive order on software supply chain security in May 2021. Generation tools have not yet reached full automation and maturity.
• "Software Bill of Materials Adoption: A Mining Study from GitHub" (2023) — DOI: 10.1109/icsme58846.2023.00016 — 186 public repositories using SBOM tools. Adoption is low but growing, with SBOM files available in only 46%.
• "Accuracy Evaluation of SBOM Tools for Web Applications and System-Level Software" (2024) — DOI: 10.1145/3664476.3670926 — No tool meets all requirements, and many tools produce incomplete SBOMs.
• "Propagation Model for SSC attacks: Why SBOM (tools) don't tell the whole truth" (2026) — arXiv:2609.05380 (preprint) — Evaluated four SBOM tools using Log4j as a test case. Only supports structural exposure and the presence of vulnerability types, failing to support code reachability or taint paths.
• "Closing the Chain: How to reduce your risk of being SolarWinds, Log4j, or XZ Utils" (2025) — arXiv:2503.12192 (preprint) — Mapped 106 threat intelligence reports to 73 tasks across 10 frameworks. Three tasks, including sustainable open source, are missing from all frameworks. Even following all of them still leaves vulnerabilities.