Most Log4j CVE lists online stopped updating in early 2022, as if the story ended once the Log4Shell patch cycle settled. It did not. The Log4j vulnerability record spans from 2017 through 2026 across two major versions, and new entries were still being published this year.

This is a Log4j-only list, ordered by era, with severity, affected components, and fixed versions. That scope matters because the Apache Logging Services security page pools Log4j with Log4cxx and Log4net, which are separate projects. CVEs for those projects are excluded here.

As of September 2026, Apache lists 13 Log4j CVEs from 2017 through 2026 on its current security page. Log4j 1.x vulnerabilities reported after the project's 2015 end of life are not maintained there, so this article covers that separate NVD-tracked set as well. Counts and version ranges should be rechecked against Apache and NVD immediately before publishing because the list is still changing.

Key Takeaways

• The Apache security page lists 13 Log4j CVEs from 2017 through 2026 as of September 2026, excluding separate Log4cxx and Log4net issues.
• Log4Shell, CVE-2021-44228, triggered three follow-up CVEs in December 2021 as maintainers closed gaps left by earlier fixes.
• Log4j 1.x reached end of life in 2015. Vulnerabilities disclosed later will not receive a patched 1.x release, so migration is the only durable remediation.
• Seven Log4j CVEs were published in 2025 and 2026. Most concern TLS verification and log-output integrity rather than remote code execution.
• Issue #4255, reported in August 2026, demonstrated an application-dependent deserialization path to RCE but received no CVE, showing why a CVE list can never be the whole runtime story.

The 2021 Chain: Log4Shell, CVE-2021-45046, and Two More Fixes

The four December 2021 CVEs are often grouped together, but they do not have the same preconditions or impact.

CVE-2021-44228, Log4Shell

Log4Shell allowed attacker-controlled text in a log message or parameter to trigger a JNDI lookup and load arbitrary code from an LDAP server. It affected log4j-core, not applications that used log4j-api alone, and received a CVSS 3.1 score of 10.0.

The vulnerability was discovered by Chen Zhaojun of Alibaba Cloud Security Team. For Java 8 and later, 2.15.0 was the first direct fix, but organizations ultimately needed later releases because follow-up CVEs exposed gaps and additional issues. For remediation guidance, see how to patch the Log4j vulnerability.

CVE-2021-45046

The 2.15.0 fix was incomplete in certain non-default configurations. If a Pattern Layout used a Thread Context Lookup and an attacker controlled MDC data, malicious input could still produce information disclosure and, in some environments, remote code execution.

Apache scores the flaw 9.0 Critical. It was fixed in 2.16.0 for Java 8 and later, with separate maintenance releases for older Java branches.

CVE-2021-45105

CVE-2021-45105 was an uncontrolled recursion issue rather than RCE. Self-referential lookup content could cause a StackOverflowError and terminate the process, producing denial of service.

The CVSS score is 5.9 Medium. The Java 8 and later fix arrived in 2.17.0, with 2.12.3 for Java 7 and 2.3.1 for Java 6.

CVE-2021-44832

This vulnerability allowed RCE through a JDBC Appender configured with a JNDI data source URI. The precondition was much stronger than Log4Shell: the attacker needed permission to modify the Log4j configuration.

NVD identifies 2.17.1 as the Java 8 and later fixed version. The 6.6 Medium score reflects that higher access requirement, even though successful exploitation could still execute code.

The Log4j2 CVE Record Before 2021

Log4Shell was not the first serious Log4j 2 vulnerability. It was the first one that could be triggered so broadly through ordinary logged text.

CVE-2017-5645

Log4j 2's TCP and UDP socket servers deserialized log events received from other applications. A crafted binary payload sent to a server using those components could execute arbitrary code during deserialization.

The flaw scored 7.5 High and was fixed in 2.8.2. Its exposure was narrower than Log4Shell because the deployment had to be running the vulnerable socket server.

CVE-2020-9488

The SMTP appender did not properly validate that a TLS certificate matched the mail server hostname. A man-in-the-middle attacker positioned on the network path could intercept log messages sent over SMTPS.

The issue scored 3.7 Low and was fixed in 2.13.2 for Java 8 and later. It established a pattern that appears again in later Log4j appender and TLS issues: a vulnerability may affect one specific output path, not every deployment of the library.

Log4j 1.x Vulnerabilities That Will Never Be Fixed

Log4j 1 reached end of life in August 2015. Apache states that vulnerabilities reported after that date are not checked or fixed, so these entries are tracked in NVD rather than the current Apache Log4j advisory list.

CVE-2021-4104

This is sometimes described as the Log4j 1.x sibling of Log4Shell, but the mechanics differ. Log4j 1.x has no Lookups feature. Exposure requires a configuration using JMSAppender, where JNDI can deserialize untrusted data.

The remaining commonly tracked Log4j 1.x vulnerabilities include:

• CVE-2019-17571: deserialization of untrusted data through SocketServer can lead to remote code execution when that server is exposed.
• CVE-2022-23302: JMSSink can deserialize untrusted data under vulnerable configurations.
• CVE-2022-23305: JDBCAppender can enable SQL injection when attacker-controlled data reaches an unsafe SQL statement.
• CVE-2022-23307: Chainsaw can deserialize untrusted data from a remote source.

There is no secure Log4j 1.x version to upgrade to. The practical remediation is migration to Log4j 2 or another supported logging framework, followed by removal of the old library from deployed workloads.

The Log4j2 Vulnerability Record Since 2025

Seven New CVEs, One Repeating Pattern

The seven Log4j CVEs published in 2025 and 2026 are all scored Medium under CVSS 4.0. They focus on TLS verification, log injection, malformed structured output, and silent event loss rather than direct code execution.

The pattern is not only that Log4j continues to receive CVEs. It is that incomplete fixes produce follow-up entries. CVE-2026-34477 closed a configuration path missed by CVE-2025-68161. CVE-2026-49844 covered code paths left open by CVE-2026-34481. That is the same general dynamic seen in the rapid 2021 sequence, even though the newer impact is lower.

These issues also show why affected component and feature matter. A TLS Socket Appender flaw does not create the same exposure in an application that never configures that appender. A JSON layout bug requires the relevant layout and attacker-influenced values. Presence of the library is only the first question.

The RCE Candidate That Never Got a CVE

In August 2026, Log4j GitHub issue #4255 described a deserialization allowlist bypass that could become RCE under specific application conditions. The report disappeared, the issue was closed, and no CVE was assigned. Apache's published threat model treats this kind of filter as defense in depth rather than a guaranteed security boundary.

The behavior was still reproducible under the right conditions. Raven's full analysis of Log4Shell 2.0 explains both sides of the classification debate and why runtime behavior matters even when a finding never enters the CVE pipeline.

What a List of Log4j Security Vulnerabilities Cannot Tell You

Same Library, Very Different Preconditions

The list itself demonstrates the problem. CVE-2021-44228 required only that attacker-controlled text reach a vulnerable logging path. CVE-2021-44832 required write access to the logging configuration. CVE-2017-5645 required a deployment running Log4j socket servers. The 2026 layout issues require specific structured-output paths.

Traditional dependency scanning may flag all of them when a version falls in an affected range, including a transitive log4j-core jar that never loads or an appender the application never initializes. The scanner is correct that the component exists, but existence does not prove that the vulnerable function executes.

This is why vulnerability triage is so hard. A Log4j vulnerability list answers what has been reported. It cannot tell a specific team which preconditions exist in its production application. Runtime security adds that execution evidence.

Which of These Log4j CVEs Are Actually Reachable

From Thirteen CVEs to the Ones That Matter in Your Environment

For every entry above, the operational question is whether the vulnerable code path runs. Does the application start a socket server? Does it initialize the SMTP or Socket Appender? Does it use the affected XML or JSON layout? Is log4j-core loaded at all, or is it a dormant transitive dependency?

Runtime SCA answers that question by observing execution at the function level in production. Raven reconstructs dependency relationships and vulnerable paths through eBPF-based instrumentation, without requiring source code or build pipeline access. When a vulnerable function executes, Raven can trace the finding to the commit, author, build, image, deployment, and service that introduced it.

Raven reports that this function-level runtime reachability can de-prioritize up to 99% of vulnerabilities. That figure is a Raven product claim, not a universal property of every environment, but the underlying value is concrete: teams can separate a vulnerable version sitting on disk from the vulnerable Log4j code that actually runs.

This is the practical extension of reachability re-imagined. A current CVE list remains useful for inventory and patch planning. Runtime evidence tells teams which entries deserve attention first while remediation is underway.

The Log4j CVE record is still being written. Seven entries appeared in 2025 and 2026, and an application-dependent RCE candidate surfaced without receiving a CVE at all.

Keeping the list current matters, but a list is an inventory of what exists, not a measure of what threatens one environment. The preconditions differ enormously, and those differences should drive remediation order alongside severity.

See which Log4j vulnerabilities actually run in your environment, and which never will.