Jetty End of Life Dates: Jetty 9, 10, 11, and 12 (2026 Guide)

As of January 1, 2026, Webtide and the Jetty project have stopped publishing releases for Jetty 9, Jetty 10, and Jetty 11 to Maven Central. Any new CVE disclosed against these versions will not receive an official patch through public channels. If your application portfolio contains Jetty 9, 10, or 11, you are now responsible for every future vulnerability on a code base that has no upstream maintainer.

Eclipse Jetty has been one of the most widely deployed Java servlet containers and HTTP servers for over two decades. It ships embedded inside Apache Solr, Hadoop, Spark, ActiveMQ, and Maven. It has historically backed major platforms like Google App Engine. A single enterprise application portfolio can easily contain three or four major Jetty versions across different services, each with a different lifecycle status, different CVE exposure, and different upgrade path.

This guide is the definitive reference for every modern Jetty release, the specs each implements, the official EOL dates, and your options for staying secure after support ends.

‍

How Jetty's Support Policy Works

The Eclipse Foundation does not publish a fixed-duration support window like Angular's 18 months or Node.js's 30 months. Instead, Jetty uses a two-phase model:

1. Community Support. The active release line receives bug fixes, new features, and security patches.
2. End of Community Support (EoCS). A previous line that still receives critical security patches but no new features. After EoCS, only Webtide customers see new releases.
3. End of Life (EOL). No further releases of any kind. No security patches. No compatibility fixes. The code base is frozen.

In practice, the Jetty project maintains two release lines simultaneously for most of their lifecycle, then transitions older lines to EoCS once the newer line is mature enough to absorb production workloads. The only reliable signal for an upcoming EoCS or EOL is an official announcement on the Eclipse Jetty website or the jetty-announce mailing list.

‍

Complete Jetty Version Timeline

‍

Jetty 9.x

Jetty 9 was the workhorse of the Java ecosystem for nearly a decade. The final maintained line, Jetty 9.4, runs on JDK 8 and implements Servlet 3.1 in the javax.servlet namespace. It is still one of the most commonly deployed Jetty versions in production, thanks to its long support window, broad compatibility with legacy Java applications, and integration with countless enterprise frameworks.

• Initial Release: March 2013 (9.0.0)
• Jetty 9.4.0 Release: December 8, 2016
• Final Maintained Release: 9.4.x series
• End of Community Support: June 1, 2022
• Final EOL (Maven Central cutoff): January 1, 2026
• Current Status: End of Life

Jetty 9 is also the version most likely to be silently embedded inside older Java applications, often as a transitive dependency that operators are not even aware of. Once a CVE is disclosed, the path from "we have Jetty 9 somewhere" to "we have patched Jetty 9 everywhere" can take months in a large enterprise. With Maven Central updates now frozen, there is no patched version to pull at all.

‍

Jetty 10.x

Jetty 10 was a bridge release. It moved the minimum JDK from 8 to 11 and adopted Servlet 4.0, but kept the historical javax.servlet namespace. For most teams, Jetty 10 was the easiest upgrade target out of Jetty 9 because application code did not need a namespace migration.

• Initial Release: December 2020 (10.0.0)
• Servlet API: Servlet 4.0
• Namespace: javax.servlet
• Minimum JDK: 11
• End of Community Support: January 1, 2024
• Final EOL (Maven Central cutoff): January 1, 2026
• Current Status: End of Life

After January 1, 2024, Jetty 10 received only customer-sponsored security releases through Webtide. As of January 1, 2026, even those public security releases have stopped.

Jetty 11.x

Jetty 11 was the first release line to adopt the Jakarta EE namespace migration. Functionally, Jetty 11 is similar to Jetty 10, but every servlet, filter, and listener interface moved from javax.servlet to jakarta.servlet. This was a hard break: application code that compiled against Jetty 9 or 10 will not compile against Jetty 11 without a namespace migration.

• Initial Release: December 2020 (11.0.0)
• Servlet API: Jakarta Servlet 5.0
• Namespace: jakarta.servlet
• Minimum JDK: 11
• End of Community Support: January 1, 2024
• Final EOL (Maven Central cutoff): January 1, 2026
• Current Status: End of Life

Teams that moved to Jetty 11 to align with Jakarta EE 9 now find themselves on an EOL version. For many enterprise applications still on Java 11, the path to Jetty 12 means a coordinated JDK and servlet container upgrade, not a simple library bump.

‍

Jetty 12.x

Jetty 12 is the current stable release and represents the most significant architectural change in the project's history. It is built on JDK 17, uses a new core HTTP engine that is independent of the servlet API, and supports multiple environments simultaneously through the new ee modules.

• Jetty 12.0.0 Release: August 7, 2023
• Jetty 12.1.0 Release: August 15, 2025 (current stable line)
• Minimum JDK: 17
• Environments Supported:
  
  • ee8: Servlet 4.0, javax.servlet namespace
  • ee9: Jakarta Servlet 5.0, jakarta.servlet namespace
  • ee10: Jakarta Servlet 6.0, jakarta.servlet namespace
  • ee11: Jakarta Servlet 6.1 (Jakarta EE 11)
• Current Status: Stable (12.1.x); 12.0.x slated for deprecation in 2026

The multi-environment model is genuinely useful for organizations with mixed Servlet 4 and Jakarta workloads. A single Jetty 12 server can host both javax and jakarta web applications in isolated environments, easing the migration path. However, the JDK 17 requirement is a real barrier for applications still on JDK 8 or 11.

Webtide has signaled that Jetty 12.0.x will reach end of community support sometime in 2026 in favor of Jetty 12.1.x, though the exact timeline has not been finalized. Plan migrations to 12.1.x rather than 12.0.x for new deployments.

‍

CVEs Affecting End-of-Life Jetty Versions

Because Jetty 9, 10, and 11 are now fully EOL, no official patches will be issued for vulnerabilities disclosed against these versions on or after January 1, 2026. The following recent CVEs illustrate the type of exposure that EOL Jetty users now carry permanently unless they upgrade or adopt extended support.

CVE-2024-13009: Buffer Release Flaw Causing Cross-Request Data Sharing in Jetty 9.4

A flaw in the gzip request body inflation path can cause a buffer to be incorrectly released when an inflation error occurs, leading to corrupted data or, more dangerously, inadvertent sharing of data between requests. This is the worst class of bug for a multi-tenant or session-bearing application: one client can end up reading bytes that belonged to another client's request. Affected versions span Jetty 9.4.0 through 9.4.56. The fix shipped in Jetty 9.4.57.v20241219, which is now the last public 9.4 release. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, rated High severity by the GitHub Advisory Database due to the cross-request scope change. Any Jetty 9 deployment still on 9.4.56 or earlier carries this permanently.

CVE-2024-8184: ThreadLimitHandler Memory Exhaustion

A flaw in ThreadLimitHandler.getRemote() allows unauthenticated attackers to trigger OutOfMemoryError by sending crafted requests, exhausting server memory and causing denial of service. Affected versions span Jetty 9.3.12 through 9.4.55, 10.0.0 through 10.0.23, 11.0.0 through 11.0.23, and 12.0.0 through 12.0.8. Patches shipped in 9.4.56, 10.0.24, 11.0.24, and 12.0.9, all of which were published to Maven Central. This was exactly the kind of routine post-EoCS patch release that Webtide will no longer make starting January 1, 2026. Any new vulnerability of this class disclosed in 2026 or later will not receive an equivalent public fix for the 9/10/11 lines.

CVE-2024-22201: HTTP/2 SSL Connection Leak Under TCP Congestion

An HTTP/2 SSL connection that is established and TCP-congested will be leaked when it times out, rather than being properly closed. An attacker can cause many connections to enter this state, eventually exhausting the server's file descriptors so it stops accepting new connections from valid clients. CVSS 7.5 (High), CWE-400 and CWE-770. Patches shipped in Jetty 9.4.54, 10.0.20, 11.0.20, and 12.0.6.

CVE-2024-6763: HttpURI Open Redirect / SSRF Risk

Eclipse Jetty's HttpURI class performs insufficient validation on the authority segment of a URI. The behavior of HttpURI differs from common browsers when parsing certain invalid URIs, so the host value extracted by Jetty may not match the host the browser ultimately resolves. When the URI passes a Jetty-side validation check and is then trusted downstream, this mismatch can enable open redirect or server-side request forgery (SSRF). CVSS 3.7 (Low), CWE-1286.

CVE-2023-36479: CgiServlet Quoting Bypass

A flaw in org.eclipse.jetty.servlets.CGI affects deployments running CGI scripts where a binary filename contains a space. The servlet escapes the command by wrapping it in quotation marks, but with a specifically crafted command structure plus an optional command prefix, the wrong command can be executed via Runtime.exec. CVSS 3.5 (Low), CWE-149 (Improper Neutralization of Quoting Syntax). This is not a classic arbitrary command injection: exploitation requires the use of the CGI servlet and a very specific filename and argument pattern.

CVE-2023-36478: HTTP/2 HPACK Header Decoder Integer Overflow

An integer overflow in MetaDataBuilder.checkSize allows HTTP/2 HPACK header values to exceed their size limit, leading to denial of service. Affected versions are Jetty 9.3.0 through 9.4.52 (http2-hpack module), 10.0.0 through 10.0.15, and 11.0.0 through 11.0.15. Jetty 12 is not affected. Patches were issued for supported lines only.

A more recent issue, CVE-2026-5795, continues this pattern. The vulnerability affects the JaspiAuthenticator and can lead to authentication bypass and privilege escalation. Organizations still running Jetty 9, 10, or 11 will not receive an official fix from upstream.

For HeroDevs' full ongoing CVE coverage for Jetty, see the Jetty vulnerability directory.

‍

What Happens After Jetty End of Life

When a Jetty release line reaches EOL, three things change immediately for production users:

1. Security patches stop. New CVEs disclosed against EOL versions will not be patched on the affected branches by the Eclipse Jetty project or Webtide. As of January 1, 2026, this is true for every Jetty 9, 10, and 11 release.
2. Compatibility breaks accumulate. As JDK versions, TLS specifications, HTTP/2 and HTTP/3 implementations, and common Java libraries (Logback, SLF4J, Jackson, and others) evolve, EOL Jetty versions will not be updated to keep up. This degrades reliability over time, even without an active exploit.
3. Compliance audits flag it. SOC 2, PCI DSS 4.0, HIPAA, FedRAMP, DORA, and the EU Cyber Resilience Act all require organizations to use supported software with documented security maintenance. The CRA enforcement deadline is September 2026, and the "due diligence" obligations under Article 14 explicitly require manufacturers to provide vulnerability handling for the support lifetime of the product. An EOL Jetty embedded in a production service is a finding that auditors will not let slide.

The challenge is compounded by Jetty's namespace migration. Moving from Jetty 9 or 10 (javax) to Jetty 11 or 12 (jakarta) requires rewriting every import in every servlet, filter, listener, and dependency that touches the Servlet API. For large applications with hundreds of integration points, this is months of work, not a weekend upgrade.

‍

Options for Running End-of-Life Jetty

1. Upgrade to Jetty 12.1

The best long-term strategy for most teams. Jetty 12's multi-environment model means you can run ee8 (Servlet 4, javax) modules alongside ee9 and ee10 (Jakarta) modules in the same server, which significantly reduces the cost of incremental migration. A Maven coordinate for the ee8 server module looks like this:

<dependency>

    <groupId>org.eclipse.jetty.ee8</groupId>

    <artifactId>jetty-ee8-servlet</artifactId>

    <version>12.1.0</version>

</dependency>

The catch is the JDK 17 requirement: applications still on JDK 8 or 11 need a coordinated runtime upgrade.

2. Migrate to a Different Servlet Container

Some organizations use a Jetty EOL event as the trigger to move to Apache Tomcat, Undertow, or a fully different application platform. This is the most expensive option and is rarely justified by the Jetty EOL alone.

3. Adopt Commercial Extended Support

HeroDevs is one of two named Webtide partners providing extended support for end-of-life Jetty versions. HeroDevs Never-Ending Support (NES) for Jetty provides secure drop-in replacements for Jetty 9, 10, and 11. NES delivers CVE patches via a private Maven registry, with the same org.eclipse.jetty group IDs and artifact names as the open-source release, so applications consume the patched binaries without code changes. This buys time to plan a controlled migration to Jetty 12.1 while staying secure and compliant.

For background on the partnership, see Webtide and HeroDevs Join Forces to Offer Enterprise-Grade Support for Jetty and CometD.

‍

Quick Reference: Is My Jetty Version Supported?

‍

Taking Action

Jetty's release cadence and EOL policy create a real maintenance burden for any organization running it at scale. Jetty 9 has been past End of Community Support since June 2022. Jetty 10 and 11 have been past EoCS since January 2024. As of January 1, 2026, all three lines are fully EOL with no further Maven Central updates. CVEs continue to be disclosed against the underlying HTTP, HTTP/2, and servlet stack on a regular basis. Browser and JDK changes will continue to erode compatibility. Compliance frameworks, particularly the EU Cyber Resilience Act, will continue to tighten.

The worst option is doing nothing. Whether the right path is a controlled upgrade to Jetty 12.1, a strategic migration, or extended support to buy time for a larger modernization effort, the decision needs to be made on your timeline rather than your auditor's.

If your organization is running an end-of-life version of Jetty, contact HeroDevs to learn about your options.

For related Java ecosystem EOL guidance, see our coverage of Spring Framework end-of-life dates and Apache Struts end-of-life dates.