Eclipse Jetty EOL: Versions, Upgrade Path & Options

Key Takeaways

• Jetty 8, 9, 10, and 11 are all end of life. On January 1, 2026, Webtide and the Jetty project stopped publishing releases for the 9, 10, and 11 lines to Maven Central, so fixes for new CVEs no longer arrive through public channels.
• Only Jetty 12.0 and 12.1 are still community supported. Jetty 12.1 is the current line; Webtide has said 12.0 updates will stop sometime in 2026, without committing to a date yet.
• Moving to Jetty 12 is more than a version bump. It requires JDK 17, and depending on which EE environment you target, a javax to jakarta migration and, for embedded Spring Boot apps, a move to Spring Boot 3.2 or later.
• If you cannot migrate yet, the realistic options are vendor-backed extended support, self-maintained backports, or replacing Jetty. Extended support is usually the lowest-effort bridge; self-maintaining is the one teams underestimate.

You patched everything last quarter. Then a dependency scan flagged jetty-server 9.4.x buried three levels deep in a service nobody has touched since 2021, and the fixed version you need is not on Maven Central. That is the state of Eclipse Jetty EOL in 2026: Jetty 9, 10, and 11 have all reached end of life, and since January 1, 2026, the project no longer publishes releases for those lines publicly.

This guide covers which versions are end of life, how to tell if you are running one, what the risk actually looks like, and the cleanest path off.

Has Eclipse Jetty Reached End of Life?

Yes, and the timeline has more moving parts than most teams noticed. Jetty 10 and 11 reached end of community support on January 1, 2024, and were declared end of life as of January 2025. Jetty 9 lost community support on June 1, 2022 and was slated for EOL in January 2025, though customer-sponsored security releases kept coming until 9.4.58.v20250814 shipped in August 2025.

The date that changes your risk calculus is more recent. Since January 1, 2026, Webtide and the Jetty project no longer publish Jetty 9, 10, or 11 releases to Maven Central or any other public repository. So when a CVE drops against a pre-12 line today, a fixed build often does exist. It just is not anywhere your build can reach.

Jetty 12.0 and 12.1 are the only community-supported lines, and 12.0 is on notice.

Note: Jetty 9 is the version most likely to be running in your environment without anyone deciding to install it. Versions of Apache Solr, Spark, ActiveMQ, and Hadoop have all shipped with Jetty embedded, and the Jetty Maven plugin pulls it into builds, so it tends to enter the building as a bundled or transitive dependency rather than a deliberate choice.

Key Eclipse Jetty Versions and Dates

The version-to-status mapping is what most readers actually need, so here it is up front, current as of July 2026 and taken from the official Eclipse Jetty announcements and release listings.

One caveat on that second column: higher fixed version numbers exist for the EOL lines, including 9.4.60 and later, 10.0.28 and later, and 11.0.28 and later. Those builds are not published to Maven Central, which is why the table stops where it does.

How to Check If You are Running EOL Eclipse Jetty

There are two situations that need different checks. Standalone Jetty is easy to find. Embedded Jetty is where teams get burned.

If you run Jetty as a standalone server, ask it directly:

java -jar $JETTY_HOME/start.jar –version

That prints the exact build, for example jetty-12.1.11. You can also read VERSION.txt in the Jetty home directory.

If Jetty is embedded in a Spring Boot app, a Solr instance, or any fat JAR, the version is hidden in your dependency tree. For Maven:

mvn dependency:tree -Dincludes=’org.eclipse.jetty*’

Keep the trailing wildcard. Jetty 12 publishes its environment artifacts under separate group IDs such as org.eclipse.jetty.ee10, and an exact-match filter of org.eclipse.jetty will not report them. If you would rather not fight the filter syntax, mvn dependency:tree | grep -i jetty catches everything.

For Gradle:

./gradlew dependencies | grep -i jetty

And to catch Jetty JARs sitting on disk inside other products:

find / -name ‘jetty-*.jar’ 2>/dev/null

Point that at a real application root rather than / if the host has large or networked mounts, and remember that a JAR inside a fat JAR or a container layer will not show up as a separate file at all.

If the output shows 9.x, 10.x, or 11.x, you are running EOL Jetty. If it shows 12.0.x or 12.1.x, you are on a supported line, with the caveat that 12.0 updates are due to stop this year.

What Happens If You Keep Running EOL Eclipse Jetty

The risk is not theoretical, and it is not only about the version you can see. It splits into three parts: new CVEs whose fixes never reach a public repository, Jetty’s long history of HTTP parsing bugs, and the audit exposure that comes with running unsupported software.

New CVEs with no public patch

A vulnerability disclosed today against Jetty 9, 10, or 11 gets no release on Maven Central. That is the practical effect of the January 2026 change, and it is a stranger problem than it first sounds, because the fix usually does exist.

CVE-2026-2332 is the clean example. It is an HTTP request smuggling flaw in Jetty’s chunked transfer encoding parser: Jetty ends chunk extension parsing at a CRLF inside a quoted string instead of treating it as an error, which lets an attacker desynchronize Jetty from a front-end proxy. Published April 14, 2026, CVSS 7.4, and it affected 9.4.0 through 9.4.59, 10.0.0 through 10.0.27, 11.0.0 through 11.0.27, 12.0.0 through 12.0.32, and 12.1.0 through 12.1.6. The public fixes landed in 12.0.33 and 12.1.7. Fixed builds also exist for the EOL lines as 9.4.60, 10.0.28, and 11.0.28, but they are not on Maven Central. Jetty’s own advisories now say as much, listing EOL patches as available through commercial providers including TuxCare.

Then it happened again. CVE-2026-5795, a JASPI authentication bypass caused by ThreadLocal state surviving an early return, was fixed publicly in 12.0.34 and 12.1.8, with 9.4.61, 10.0.29, and 11.0.29 available only through those same extended-support channels. Two high-severity advisories in one spring, both patched, neither patch reachable from a public build if you are on a pre-12 line.

A Spring Boot 2.7 app embedding Jetty 9.4 shows the shape of the trap. Overriding the Jetty version in your build only works if there is something public to override it to, and for 9.4 there is not anymore. The alternative is a 12.x artifact, which means JDK 17, jakarta namespaces, and a Spring Boot major upgrade, so the CVE tends to just sit in the report. The fix exists; getting a supported build of it onto your servers is the hard part, and closing that gap without a forced upgrade is what vendor-backed patching is for.

Jetty’s HTTP parsing track record

Jetty’s recurring weak spot is HTTP/1.x request handling, and the pattern is consistent enough to plan around. CVE-2026-2332 is a chunked-encoding parsing bug, and it is far from the first. CVE-2023-40167 involved Jetty accepting a + character before the Content-Length value, a parsing quirk that can enable request smuggling when a front end reads that header differently.

The 2017 batch tells the same story across three parser bugs. CVE-2017-7656 involved accepting an HTTP/1-style request line that declared HTTP/0.9, which could poison a cache when an intermediary forwarded the version without acting on it. CVE-2017-7657 was an integer overflow in chunk length parsing, so a large chunk could be read as a smaller one and its body treated as a pipelined request. CVE-2017-7658 involved conflicting Content-Length and chunked encoding indicators. In the latter two, the damaging case was Jetty behind an intermediary that imposed authorization and passed the request through unchanged: the smuggled request arrived on the far side of that check.

Two things follow from that history. If Jetty sits behind a proxy, load balancer, or CDN, treat parser CVEs as high priority rather than academic, because the intermediary is what makes them exploitable. And if you cannot patch immediately, normalizing or stripping chunk extensions at the front end is a real interim mitigation for this class of bug.

Hidden embedding and compliance exposure

The transitive-dependency problem makes everything above harder. Because versions of Solr, Spark, ActiveMQ, and Hadoop bundle Jetty, and the Jetty Maven plugin drags it into builds, the “we do not use Jetty” assumption is often wrong. In a large portfolio it is common to find more than one Jetty major version across different services, each with its own exposure and its own owner.

There is also the audit side. PCI DSS sets explicit patching and vulnerability-management requirements, FedRAMP expects documented scanning and remediation timelines, and while SOC 2 is an attestation against controls you defined rather than a patching mandate, an auditor will still ask how an unsupported HTTP server squares with the controls you wrote down. An EOL Jetty does not fail an audit on its own. It does make you explain yourself, and “the upstream fix is not published anymore” is a poor answer without a compensating control behind it.

Watch Out: A green dependency scan on your application repos does not mean you are clear. EOL Jetty most often hides inside third-party products you deployed as a single artifact, so the vulnerable JAR may never appear as a direct dependency in your own pom.xml. Scan deployed artifacts and container images, not only the repositories you build.

Upgrade Path: Moving to Eclipse Jetty 12

The migration work depends heavily on whether your Jetty is standalone or embedded. Each step below gates the next, so the order matters.

•   JDK 17 first. Both Jetty 12.0 and 12.1 set Java 17 as the minimum runtime. If you are on Java 8 or Java 11, this is the gating move and usually the largest single piece of work.
•   Then pick your EE environment. Jetty 12 runs applications inside environment-specific modules: 12.0 ships EE8, EE9, and EE10, and 12.1 covers EE8 through EE11. EE10 uses jakarta.servlet (Servlet 6.0) and EE11 uses Servlet 6.1, so code and libraries importing the Java EE javax.* APIs have to move for those targets. EE8 keeps the javax.* namespace, which means you can land the Jetty 12 core first and schedule the namespace work separately. Worth stating plainly for anyone scripting this: only the Java EE packages moved. javax.crypto, javax.sql, and the rest of Java SE stay exactly where they are.
•   Spring Boot version coupling for embedded users. This is the trap. Embedded Jetty 12 needs Spring Boot 3.2 or later, because Spring Boot 3.0 and 3.1 shipped with Jetty 11 and required downgrading the Servlet API to 5.0 to use Jetty at all. Spring Boot 3.x in turn requires Java 17 and the Jakarta EE 9 namespace, so a “bump Jetty” ticket becomes a Spring Boot 2 to 3 migration with a 3.2 floor.

Consider a SaaS application on Spring Boot 2.7 with embedded Jetty 9.4. The Jetty upgrade is not a line in pom.xml. It is a multi-sprint project touching the JDK, the Java EE imports across the codebase, Spring Security configuration, and a long tail of libraries that need Jakarta-compatible releases.

The decision splits cleanly. If you run standalone Jetty and you are already on Java 17, the migration is more contained than an embedded one, but budget review time for renamed Maven artifacts, the new module and environment layout, your jetty-base configuration, and your deployment descriptors. If Jetty is embedded in a Spring Boot 2.x app, plan the Spring Boot 3.2-or-later migration first and treat the Jetty version as a downstream effect. And if you are already working through a Spring Framework EOL migration, sequence the two together, because the jakarta work overlaps almost completely.

Expert Tip: Eclipse Transformer can mechanically rewrite javax.* references to jakarta.* in bytecode for dependencies you cannot rebuild from source. It removes a lot of mechanical churn, but transformed artifacts need full regression testing and the original vendor will not support them, so treat it as a bridge for one blocked dependency rather than a migration strategy.

Your Options If You Cannot Upgrade Right Now

Sometimes the migration cannot happen this quarter. The Spring Boot 3 work is too big, or a vendor product pins an old Jetty you do not control. You still have three realistic moves: vendor-backed extended support, self-maintaining backports in-house, or replacing Jetty.

1. Use TuxCare Endless Lifecycle Support for Jetty

If migration is months out, vendor-backed extended support keeps EOL Jetty patched without forcing the upgrade onto your timeline. TuxCare’s Endless Lifecycle Support delivers security fixes for end-of-life open source software, and its Jetty coverage spans the 7, 8, 9.2, 9.4, 10, and 11 lines, including the post-EOL builds that address the 2026 CVEs: 9.4.60 and later, 10.0.28 and later, and 11.0.28 and later. Webtide partnered with TuxCare to provide this, which is why Jetty’s own advisories now point EOL users toward commercial patch providers.

Delivery fits the toolchain you already have. Patched artifacts are published as signed packages to a TuxCare-managed, Maven-compatible registry, so existing Maven and Gradle builds consume them by pointing at a different repository and updating the version, not by changing how you build.

Jetty’s own footprint is small and clean: jetty-server pulls in jetty-http, jetty-io, jetty-util, and slf4j-api. The catch is where the CVEs land. jetty-http and jetty-server are exactly where the request-smuggling and URI-parsing bugs live, and jetty-http is usually the artifact your scanner flags after it arrived three levels down through something else. ELS covers direct and transitive dependencies at no extra cost, so the modules that actually carry Jetty’s vulnerabilities get patched, not only the artifact you declared.

For most teams this is the pragmatic bridge. It takes the immediate security pressure off and gives you documented patch coverage to bring to an audit conversation while you plan the Java 17 and Spring Boot 3.2 work properly, instead of rewriting embedded web server integrations on someone else’s deadline.

2. Self-Maintain Jetty Internally

You can fork the last public Jetty release and backport security fixes yourself. It is technically possible, and occasionally the right call for a heavily customized deployment that was never going to migrate cleanly anyway.

It is also expensive in the way that matters most: you become the maintainer of your own Jetty fork. Someone has to watch every new advisory, read the HTTP/1.x parser closely enough to port a smuggling fix correctly, and ship it through your build and release process with regression coverage behind it. Get the nuance wrong on a parser fix and you ship a patch that looks applied and is not, which is worse than knowing you are exposed. Sustaining that takes dedicated security engineering and release management capacity that most application teams do not have sitting idle.

3. Replace Jetty with an Alternative

Swapping Jetty for another servlet container is on the table, especially if you were considering an architecture change anyway. Tomcat and Undertow are the like-for-like options, and for a standalone deployment with straightforward servlet needs, Tomcat is one of the most common destinations. Netty is a different proposition: it is a lower-level asynchronous networking framework rather than a servlet container, so moving there is an architectural rewrite, not a replacement.

Be honest about the size of it. For an embedded app, replacing the server often means more rework than upgrading Jetty would have: a different configuration model, different connector and thread-pool tuning, and a fresh round of load testing. A replacement that “should be equivalent” has a way of surfacing edge-case behavior differences under production traffic. And if you are already doing the jakarta migration for Jetty 12, most of that work transfers, which makes staying on Jetty the lower-friction path for a lot of teams.

Stay Secure on EOL Eclipse Jetty with TuxCare

The version math is settled. Jetty 8, 9, 10, and 11 are end of life, public releases for the 9, 10, and 11 lines stopped on January 1, 2026, and moving to Jetty 12 is a real project rather than a checkbox. The open question is how you cover the gap between today and a finished migration.

If you can move to Jetty 12 this quarter, do it, and sequence the JDK 17 and Spring Boot 3.2 work realistically. If you cannot, do not run unpatched, because fixed builds for the EOL lines do exist and simply are not published publicly anymore. Vendor-backed support keeps known vulnerabilities patched and gives you evidence of an active remediation process while you plan. See how TuxCare handles EOL open source software, and check pricing to scope it against your portfolio.

FAQs

Which Eclipse Jetty versions are still supported?

Only Jetty 12.0 and 12.1 receive community support. Jetty 12.1 is the current line and gets active fixes; 12.0 still gets updates, but Webtide has said those will stop sometime in 2026 and has not committed to a date. Everything older, including Jetty 8, 9, 10, and 11, is end of life.

Is Eclipse Jetty 9 still safe to run in production?

Not without an active source of security fixes. Jetty 9.4 is end of life, its last public release was 9.4.58.v20250814 in August 2025, and since January 1, 2026 no 9.x releases are published to Maven Central. Later fixed builds exist, but only through extended-support providers, so running 9.4 responsibly means having that support in place, or compensating controls in front of it, and a migration plan behind both.

How do I know if my Spring Boot application uses an EOL version of Jetty?

Run mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ or ./gradlew dependencies | grep -i jetty. Keep the wildcard, because Jetty 12 publishes environment artifacts under group IDs such as org.eclipse.jetty.ee10 that an exact-match filter will miss. If the output shows a 9.x, 10.x, or 11.x Jetty artifact, your app is on an EOL line, even if Jetty arrived as a transitive dependency you never declared.

Does upgrading from Jetty 10 to Jetty 12 require migrating from javax to jakarta?

Only if you target Jetty 12’s EE10 or EE11 environment. Jetty 10 uses javax.servlet, EE10 uses jakarta.servlet (Servlet 6.0), and EE11 uses Servlet 6.1. Jetty 12 also ships EE8 and EE9 environments, and EE8 keeps the javax.* namespace, so you can move the Jetty core and the JDK first and treat the namespace migration as its own project.

What JDK version does Eclipse Jetty 12 require?

Java 17. Both Jetty 12.0 and 12.1 set Java 17 as the minimum runtime, so a JDK upgrade is the first gating step for any team coming from Jetty 9, 10, or 11 on Java 8 or Java 11.

Summary

Article Name

Eclipse Jetty EOL: Versions, Upgrade Path & Options

Description

Jetty 8, 9, 10, and 11 are end of life, and public releases stopped in January 2026. Get the version dates, detection commands, and your options.

Author

Rohan Timalsina

Publisher Name

TuxCare

Publisher Logo