Eclipse Jetty – Ende der Lebensdauer (EOL): Versionen, Upgrade-Pfad und Optionen

Wichtigste Erkenntnisse

• Jetty 8, 9, 10 und 11 haben alle das Ende ihres Lebenszyklus erreicht. Am 1. Januar 2026 haben Webtide und das Jetty-Projekt die Veröffentlichung von Releases für die Versionsreihen 9, 10 und 11 in Maven Central eingestellt, sodass Korrekturen für neue CVEs nicht mehr über öffentliche Kanäle bereitgestellt werden.
• Nur Jetty 12.0 und 12.1 werden weiterhin von der Community unterstützt. Jetty 12.1 ist die aktuelle Version; Webtide hat angekündigt, dass die Updates für 12.0 irgendwann im Jahr 2026 eingestellt werden, ohne jedoch bereits ein konkretes Datum zu nennen.
• Der Umstieg auf Jetty 12 ist mehr als nur ein Versionswechsel. Er erfordert JDK 17 und – je nachdem, welche EE-Umgebung Sie anvisieren – eine Migration von „javax“ zu „jakarta“ sowie, bei eingebetteten Spring-Boot-Anwendungen, einen Umstieg auf Spring Boot 3.2 oder höher.
• Falls eine Migration noch nicht möglich ist, kommen realistisch gesehen folgende Optionen in Frage: vom Anbieter unterstützter erweiterter Support, selbst gepflegte Backports oder der Austausch von Jetty. Der erweiterte Support ist in der Regel die Lösung mit dem geringsten Aufwand; die selbstständige Pflege wird von den Teams häufig unterschätzt.

Im letzten Quartal haben Sie alle Patches installiert. Dann hat ein Abhängigkeitsscan „jetty-server 9.4.x“ identifiziert, das drei Ebenen tief in einem Dienst vergraben war, den seit 2021 niemand mehr angerührt hat – und die benötigte korrigierte Version ist nicht bei Maven Central verfügbar. So sieht die Situation bei Eclipse Jetty EOL im Jahr 2026 aus: Jetty 9, 10 und 11 haben alle das Ende ihrer Lebensdauer erreicht, und seit dem 1. Januar 2026 veröffentlicht das Projekt keine Releases für diese Versionsreihen mehr.

In diesem Leitfaden erfahren Sie, welche Versionen das Ende ihres Lebenszyklus erreicht haben, wie Sie feststellen können, ob Sie eine solche Version verwenden, wie das Risiko konkret aussieht und wie Sie am saubersten davon loskommen.

Ist Eclipse Jetty nicht mehr weiterentwickelt?

Ja, und der Zeitplan enthält mehr bewegliche Teile, als den meisten Teams bewusst war. Für Jetty 10 und 11 endete der Community-Support am 1. Januar 2024, und ab Januar 2025 wurden sie als „End of Life“ (EOL) deklariert. Jetty 9 verlor am 1. Juni 2022 den Community-Support und sollte ursprünglich im Januar 2025 das Lebensende erreichen, doch dank von Kunden finanzierter Sicherheitsupdates wurden bis zur Veröffentlichung von 9.4.58.v20250814 im August 2025 weiterhin Releases bereitgestellt.

Das Datum, das Ihre Risikoeinschätzung verändert, liegt noch nicht lange zurück. Seit dem 1. Januar 2026 veröffentlichen Webtide und das Jetty-Projekt keine Jetty-Versionen 9, 10 oder 11 mehr in Maven Central oder einem anderen öffentlichen Repository. Wenn also heute eine CVE für eine Version vor 12 veröffentlicht wird, gibt es oft bereits einen korrigierten Build. Dieser ist jedoch nirgendwo zu finden, wo Ihr Build darauf zugreifen kann.

Jetty 12.0 und 12.1 sind die einzigen von der Community unterstützten Versionszweige, wobei 12.0 als veraltet gilt.

Hinweis: Jetty 9 ist die Version, die höchstwahrscheinlich in Ihrer Umgebung läuft, ohne dass jemand bewusst entschieden hat, sie zu installieren. Versionen von Apache Solr, Spark, ActiveMQ und Hadoop wurden alle mit eingebettetem Jetty ausgeliefert, und das Jetty-Maven-Plugin bindet es in Builds ein, sodass es in der Regel eher als gebündelte oder transitive Abhängigkeit in den Build gelangt als durch eine bewusste Entscheidung.

Wichtige Eclipse-Jetty-Versionen und -Daten

Die Zuordnung von Versionen zu Status ist das, was die meisten Leser tatsächlich benötigen; daher finden Sie sie hier gleich zu Beginn – aktuell Stand Juli 2026 und entnommen aus den offiziellen Eclipse-Jetty-Ankündigungen und Release-Listen.

Ein Hinweis zur zweiten Spalte: Für die EOL-Reihen gibt es höhere feste Versionsnummern, darunter 9.4.60 und höher, 10.0.28 und höher sowie 11.0.28 und höher. Diese Builds werden nicht bei Maven Central veröffentlicht, weshalb die Tabelle an dieser Stelle endet.

So überprüfen Sie, ob Sie eine EOL-Version von Eclipse Jetty verwenden

Es gibt zwei Situationen, die unterschiedliche Überprüfungen erfordern. Das eigenständige Jetty-Modul ist leicht zu finden. Beim eingebetteten Jetty-Modul geraten Teams oft in Schwierigkeiten.

Wenn Sie Jetty als eigenständigen Server ausführen, fragen Sie direkt dort nach:

java -jar $JETTY_HOME/start.jar –version

Dadurch wird die genaue Build-Version ausgegeben, zum Beispiel jetty-12.1.11. Du kannst auch die Datei VERSION.txt im Jetty-Home-Verzeichnis einsehen.

Wenn Jetty in eine Spring-Boot-Anwendung, eine Solr-Instanz oder ein beliebiges „Fat-JAR“ eingebettet ist, ist die Version in Ihrem Abhängigkeitsbaum verborgen. Für Maven:

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

Behalten Sie den abschließenden Platzhalter bei. Jetty 12 veröffentlicht seine Umgebungsartefakte unter separaten Gruppen-IDs wie beispielsweise org.eclipse.jetty.ee10, und ein Filter für exakte Übereinstimmungen mit org.eclipse.jetty wird diese nicht melden. Wenn Sie sich lieber nicht mit der Filtersyntax herumschlagen möchten, mvn dependency:tree | grep -i jetty erfasst alles.

Für Gradle:

./gradlew dependencies | grep -i jetty

Und um Jetty-JARs zu erfassen, die sich in anderen Produkten auf der Festplatte befinden:

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

Verweisen Sie damit auf ein echtes Anwendungsverzeichnis statt auf / , wenn der Host große oder vernetzte Einbindungen hat, und denken Sie daran, dass eine JAR-Datei innerhalb einer „Fat JAR“ oder einer Container-Ebene überhaupt nicht als separate Datei angezeigt wird.

Wenn die Ausgabe 9.x, 10.x oder 11.x anzeigt, verwenden Sie eine EOL-Version von Jetty. Wenn sie 12.0.x oder 12.1.x anzeigt, verwenden Sie eine unterstützte Version, wobei zu beachten ist, dass die Updates für 12.0 noch in diesem Jahr eingestellt werden sollen.

Was passiert, wenn Sie die nicht mehr unterstützte Version von Eclipse Jetty weiterhin verwenden?

Das Risiko ist nicht nur theoretischer Natur, und es geht nicht nur um die Version, die Sie sehen können. Es lässt sich in drei Bereiche unterteilen: neue CVEs, deren Korrekturen nie in ein öffentliches Repository gelangen, Jettys lange Geschichte von Fehlern bei der HTTP-Auswertung sowie die Sicherheitsrisiken bei Audits, die mit dem Einsatz nicht mehr unterstützter Software einhergehen.

Neue CVEs, für die es noch keinen öffentlichen Patch gibt

Eine heute bekannt gegebene Sicherheitslücke in Jetty 9, 10 oder 11 wird nicht auf Maven Central veröffentlicht. Das ist die praktische Auswirkung der Änderung vom Januar 2026, und es ist ein seltsameres Problem, als es zunächst klingt, da es in der Regel sehr wohl einen Fix gibt.

CVE-2026-2332 ist das anschauliche Beispiel. Es handelt sich um eine Schwachstelle im Zusammenhang mit HTTP-Request-Smuggling im Parser für die Chunked-Transfer-Encoding-Übertragung von Jetty: Jetty beendet das Parsen der Chunk-Erweiterung an einer CRLF-Zeichenfolge innerhalb einer in Anführungszeichen gesetzten Zeichenkette, anstatt dies als Fehler zu behandeln, wodurch ein Angreifer Jetty von einem Front-End-Proxy desynchronisieren kann. Veröffentlicht am 14. April 2026, CVSS 7,4; betroffene Versionen: 9.4.0 bis 9.4.59, 10.0.0 bis 10.0.27, 11.0.0 bis 11.0.27, 12.0.0 bis 12.0.32 sowie 12.1.0 bis 12.1.6. Die öffentlich verfügbaren Korrekturen wurden in den Versionen 12.0.33 und 12.1.7 bereitgestellt. Für die EOL-Versionen gibt es ebenfalls korrigierte Builds wie 9.4.60, 10.0.28 und 11.0.28, diese sind jedoch nicht auf Maven Central verfügbar. In den eigenen Sicherheitshinweisen von Jetty wird dies nun ebenfalls erwähnt, wobei EOL-Patches als über kommerzielle Anbieter wie TuxCare erhältlich aufgeführt werden.

Dann passierte es erneut. CVE-2026-5795, eine Umgehung der JASPI-Authentifizierung, die dadurch verursacht wurde, dass der ThreadLocal-Zustand nach einer vorzeitigen Rückkehr erhalten blieb, wurde in den Versionen 12.0.34 und 12.1.8 öffentlich behoben, wobei die Versionen 9.4.61, 10.0.29 und 11.0.29 nur über dieselben Kanäle für erweiterten Support verfügbar waren. Zwei Sicherheitshinweise mit hohem Schweregrad in einem Frühjahr, beide gepatcht, wobei keiner der Patches über einen öffentlichen Build erreichbar ist, wenn Sie eine Version vor 12 verwenden.

Eine Spring Boot 2.7-Anwendung, in die Jetty 9.4 eingebettet ist, verdeutlicht die Problematik. Das Überschreiben der Jetty-Version in Ihrem Build funktioniert nur, wenn es eine öffentlich zugängliche Version gibt, auf die Sie überschreiben können – und für 9.4 gibt es diese nicht mehr. Die Alternative ist ein 12.x-Artefakt, was JDK 17, Jakarta-Namespaces und ein umfangreiches Spring-Boot-Upgrade bedeutet; daher bleibt die CVE meist einfach im Bericht stehen. Die Korrektur existiert; die Herausforderung besteht darin, eine unterstützte Version davon auf Ihre Server zu bringen, und genau dafür sind vom Anbieter unterstützte Patches gedacht: um diese Lücke ohne ein erzwungenes Upgrade zu schließen.

Jettys Erfolgsbilanz bei der HTTP-Analyse

Eine immer wiederkehrende Schwachstelle von Jetty ist die Verarbeitung von HTTP/1.x-Anfragen, und dieses Muster tritt so regelmäßig auf, dass man entsprechend planen kann. CVE-2026-2332 ist ein Fehler beim Parsen von Chunked-Encoding, und es ist bei weitem nicht der erste. CVE-2023-40167 betraf Jetty, das eine + Zeichen vor dem Content-Length -Wert akzeptierte – eine Besonderheit bei der Analyse, die Request-Smuggling ermöglichen kann, wenn ein Frontend diesen Header anders interpretiert.

Die Fehler aus dem Jahr 2017 zeigen bei drei Parser-Fehlern ein ähnliches Muster. CVE-2017-7656 betraf die Annahme einer Request-Zeile im HTTP/1-Stil, die HTTP/0.9 deklarierte; dies konnte zu einer Cache-Verfälschung führen, wenn ein Zwischenserver die Version weiterleitete, ohne darauf zu reagieren. CVE-2017-7657 betraf einen Ganzzahlüberlauf bei der Analyse der Chunk-Länge, sodass ein großer Chunk als kleinerer gelesen und sein Body als Pipeline-Anfrage behandelt werden konnte. CVE-2017-7658 betraf widersprüchliche „Content-Length“- und „Chunked-Encoding“-Indikatoren. Bei den beiden letztgenannten war der schädliche Fall, dass Jetty hinter einem Zwischenserver lief, der eine Autorisierung durchführte und die Anfrage unverändert weiterleitete: Die eingeschleuste Anfrage gelangte auf der anderen Seite dieser Überprüfung an.

Aus dieser Vorgeschichte lassen sich zwei Schlussfolgerungen ziehen: Wenn Jetty hinter einem Proxy, einem Load Balancer oder einem CDN läuft, sollten Sie CVEs im Parser nicht als rein theoretisch, sondern als hochprioritär einstufen, da sie erst durch den zwischengeschalteten Server ausnutzbar werden. Und falls Sie nicht sofort einen Patch installieren können, stellt die Normalisierung oder das Entfernen von Chunk-Erweiterungen am Frontend eine wirksame vorübergehende Abhilfemaßnahme für diese Art von Fehlern dar.

Versteckte Einbettung und Offenlegung von Compliance-Risiken

Das Problem der transitiven Abhängigkeiten erschwert all das oben Genannte. Da Solr-, Spark-, ActiveMQ- und Hadoop-Versionen Jetty bündeln und das Jetty-Maven-Plugin es in die Builds einbindet, ist die Annahme „Wir verwenden Jetty nicht“ oft falsch. In einem großen Portfolio ist es üblich, dass in verschiedenen Diensten mehr als eine Jetty-Hauptversion zum Einsatz kommt, wobei jede ihre eigenen Risiken und ihren eigenen Verantwortlichen hat.

Hinzu kommt noch der Bereich der Audits. PCI DSS legt explizite Anforderungen an das Patch-Management und das Schwachstellenmanagement fest, FedRAMP erwartet dokumentierte Zeitpläne für Scans und Abhilfemaßnahmen, und während SOC 2 eine Bescheinigung hinsichtlich der von Ihnen definierten Kontrollmaßnahmen und keine verbindliche Vorgabe für Patches ist, wird ein Prüfer dennoch fragen, wie ein nicht mehr unterstützter HTTP-Server mit den von Ihnen festgelegten Kontrollmaßnahmen vereinbar ist. Ein Jetty-Server am Ende seiner Lebensdauer (EOL) führt allein noch nicht zum Scheitern eines Audits. Er zwingt Sie jedoch dazu, sich zu erklären, und „der Upstream-Fix wird nicht mehr veröffentlicht“ ist eine unzureichende Antwort, wenn keine kompensierende Kontrollmaßnahme dahintersteht.

Achtung: Ein „grüner“ Abhängigkeitsscan Ihrer Anwendungs-Repos bedeutet nicht, dass Sie auf der sicheren Seite sind. EOL-Jetty verbirgt sich meist in Produkten von Drittanbietern, die Sie als einzelnes Artefakt bereitgestellt haben, sodass die anfällige JAR-Datei möglicherweise nie als direkte Abhängigkeit in Ihrer eigenen pom.xmlauf. Scannen Sie bereitgestellte Artefakte und Container-Images, nicht nur die Repositories, die Sie erstellen.

Upgrade-Pfad: Umstellung auf Eclipse Jetty 12

Die Migrationsarbeiten hängen stark davon ab, ob Ihr Jetty als eigenständige Anwendung oder eingebettet läuft. Jeder der folgenden Schritte ist Voraussetzung für den nächsten, daher ist die Reihenfolge entscheidend.

•   Zunächst JDK 17. Sowohl Jetty 12.0 als auch 12.1 setzen Java 17 als Mindest-Laufzeitumgebung fest. Wenn Sie Java 8 oder Java 11, ist dies der entscheidende Schritt und in der Regel der größte einzelne Arbeitsaufwand.
•   Wählen Sie anschließend Ihre EE-Umgebung aus. Jetty 12 führt Anwendungen in umgebungsspezifischen Modulen aus: Version 12.0 enthält EE8, EE9 und EE10, während Version 12.1 die Versionen EE8 bis EE11 abdeckt. EE10 verwendet jakarta.servlet (Servlet 6.0) und EE11 verwendet Servlet 6.1, sodass Code und Bibliotheken, die die Java-EE-APIs „javax.*“ importieren, für diese Zielumgebungen angepasst werden müssen. EE8 behält den javax.*-Namensraum bei, was bedeutet, dass Sie zunächst den Jetty-12-Kern bereitstellen und die Arbeiten am Namensraum separat planen können. Für alle, die dies in Skripten umsetzen, sei ausdrücklich darauf hingewiesen: Es wurden nur die Java-EE-Pakete verschoben. javax.crypto, javax.sql und der Rest von Java SE bleiben genau dort, wo sie sind.
•   Versionierung von Spring Boot für Embedded-Anwender. Hier liegt die Falle. Embedded Jetty 12 benötigt Spring Boot 3.2 oder höher, da Spring Boot 3.0 und 3.1 mit Jetty 11 ausgeliefert wurden und ein Downgrade der Servlet-API auf 5.0 erforderten, um Jetty überhaupt nutzen zu können. Spring Boot 3.x wiederum erfordert Java 17 und den Jakarta EE 9-Namespace, sodass aus einem Ticket zum „Jetty-Update“ eine Migration von Spring Boot 2 auf 3 mit der Mindestversion 3.2 wird.

Betrachten wir eine SaaS-Anwendung auf Basis von Spring Boot 2.7 mit integriertem Jetty 9.4. Das Jetty-Upgrade ist keine einzelne Zeile in der pom.xml. Es handelt sich um ein über mehrere Sprints erstreckendes Projekt, das das JDK, die Java-EE-Importe in der gesamten Codebasis, die Spring-Security-Konfiguration sowie eine lange Reihe von Bibliotheken betrifft, für die Jakarta-kompatible Versionen erforderlich sind.

Die Entscheidung ist klar. Wenn Sie Jetty als eigenständige Anwendung betreiben und bereits Java 17 verwenden, ist die Migration weniger aufwendig als bei einer eingebetteten Version. Planen Sie jedoch Zeit für die Überprüfung der umbenannten Maven-Artefakte, der neuen Modul- und Umgebungsstruktur, Ihrer „jetty-base“-Konfiguration sowie Ihrer Deployment-Deskriptoren ein. Wenn Jetty in eine Spring Boot 2.x-Anwendung eingebettet ist, planen Sie zunächst die Migration auf Spring Boot 3.2 oder höher und betrachten Sie die Jetty-Version als Folgeeffekt. Und wenn Sie bereits an einem Spring-Framework-EOL arbeiten, führen Sie beide Migrationen nacheinander durch, da sich die Arbeiten an Jakarta fast vollständig überschneiden.

Expertentipp: Eclipse Transformer kann javax.*-Verweise im Bytecode automatisch in jakarta.* umschreiben, wenn es sich um Abhängigkeiten handelt, die Sie nicht aus dem Quellcode neu erstellen können. Das erspart viel automatische Arbeit, aber transformierte Artefakte müssen umfassenden Regressionstests unterzogen werden, und der ursprüngliche Anbieter bietet keinen Support dafür. Betrachten Sie es daher eher als Überbrückungslösung für eine blockierte Abhängigkeit und nicht als Migrationsstrategie.

Ihre Möglichkeiten, falls Sie derzeit kein Upgrade durchführen können

Manchmal lässt sich die Migration in diesem Quartal nicht durchführen. Der Aufwand für Spring Boot 3 ist zu groß, oder ein Herstellerprodukt ist an eine alte Jetty-Version gebunden, auf die Sie keinen Einfluss haben. Ihnen stehen dennoch drei realistische Optionen offen: erweiterter Support durch den Hersteller, die eigenständige Pflege von Backports im eigenen Haus oder der Austausch von Jetty.

1. Nutzen Sie den „Endless Lifecycle Support“ von TuxCare für Jetty

Wenn die Migration erst in einigen Monaten ansteht, sorgt der vom Anbieter unterstützte erweiterte Support dafür, dass EOL-Jetty weiterhin mit Patches versorgt wird, ohne dass Sie das Upgrade vorzeitig durchführen müssen. Der „Endless Lifecycle Support“ von TuxCare bietet Sicherheitspatches für Open-Source-Software nach Ablauf der Lebensdauer, und die Jetty-Abdeckung umfasst die Versionsreihen 7, 8, 9.2, 9.4, 10 und 11, einschließlich der Builds nach Ablauf der Lebensdauer, die die CVEs für 2026 beheben: 9.4.60 und höher, 10.0.28 und höher sowie 11.0.28 und höher. Webtide hat sich mit TuxCare zusammengetan, um dies anzubieten, weshalb die eigenen Sicherheitshinweise von Jetty EOL-Nutzer nun auf kommerzielle Patch-Anbieter verweisen.

Die Bereitstellung passt sich Ihrer bestehenden Toolchain an. Gepatchte Artefakte werden als signierte Pakete in einem von TuxCare verwalteten, Maven-kompatiblen Repository veröffentlicht, sodass bestehende Maven- und Gradle-Builds diese nutzen können, indem sie auf ein anderes Repository verweisen und die Version aktualisieren – ohne dass Sie Ihren Build-Prozess ändern müssen.

Jetty selbst hat einen geringen und übersichtlichen Speicherbedarf: jetty-server bezieht jetty-http, jetty-io, jetty-utilund slf4j-api. Der Haken liegt darin, wo die CVEs landen. jetty-http und jetty-server sind genau die Stellen, an denen die Fehler im Zusammenhang mit Request-Smuggling und der URI-Auswertung auftreten, und „jetty-http“ ist in der Regel das Artefakt, das Ihr Scanner meldet, nachdem es über drei Ebenen durch andere Komponenten hindurchgelangt ist. ELS deckt direkte und transitive Abhängigkeiten ohne zusätzliche Kosten ab, sodass die Module, die tatsächlich die Schwachstellen von Jetty enthalten, gepatcht werden – nicht nur das von Ihnen angegebene Artefakt.

Für die meisten Teams ist dies die pragmatische Übergangslösung. Sie entlastet Sie unmittelbar in puncto Sicherheit und liefert Ihnen eine dokumentierte Patch-Abdeckung, die Sie bei Audit-Gesprächen vorweisen können, während Sie die Umstellung auf Java 17 und Spring Boot 3.2 ordnungsgemäß planen – anstatt die Integrationen der eingebetteten Webserver nach den Fristen anderer neu schreiben zu müssen.

2. Interne Wartung des Jetty-Servers

Sie können die letzte öffentliche Jetty-Version forken und Sicherheitskorrekturen selbst zurückportieren. Das ist technisch möglich und gelegentlich die richtige Entscheidung für eine stark angepasste Bereitstellung, bei der eine saubere Migration ohnehin nie möglich gewesen wäre.

Es ist auch in der Hinsicht teuer, auf die es am meisten ankommt: Man wird zum Betreuer seines eigenen Jetty-Forks. Jemand muss jede neue Sicherheitsempfehlung im Auge behalten, den HTTP/1.x-Parser genau genug lesen, um einen „Smuggling“-Fix korrekt zu portieren, und diesen durch Ihren Build- und Release-Prozess mit anschließender Regressionsprüfung ausliefern. Wenn Sie bei einer Parser-Korrektur eine Nuance falsch einschätzen, liefern Sie einen Patch aus, der scheinbar angewendet wurde, es aber nicht ist – was schlimmer ist, als zu wissen, dass Sie angreifbar sind. Um dies aufrechtzuerhalten, sind spezielle Kapazitäten im Bereich Sicherheitsentwicklung und Release-Management erforderlich, über die die meisten Anwendungsteams nicht verfügen.

3. Jetty durch eine Alternative ersetzen

Der Wechsel von Jetty zu einem anderen Servlet-Container steht zur Debatte, insbesondere wenn Sie ohnehin eine Architekturänderung in Betracht gezogen haben. Tomcat und Undertow sind die direkt vergleichbaren Alternativen, und für eine eigenständige Bereitstellung mit einfachen Servlet-Anforderungen ist Tomcat eine der gängigsten Lösungen. Netty ist ein ganz anderes Konzept: Es handelt sich dabei eher um ein asynchrones Netzwerk-Framework auf niedrigerer Ebene als um einen Servlet-Container, sodass ein Umstieg auf Netty eine architektonische Neugestaltung und keinen bloßen Austausch darstellt.

Seien Sie ehrlich, was den Umfang angeht. Bei einer eingebetteten Anwendung bedeutet der Austausch des Servers oft mehr Aufwand als ein Upgrade auf Jetty: ein anderes Konfigurationsmodell, eine andere Abstimmung der Konnektoren und des Thread-Pools sowie eine neue Runde von Lasttests. Ein Ersatz, der „gleichwertig sein sollte“, bringt unter Produktionsbedingungen oft Unterschiede im Verhalten in Grenzfällen zum Vorschein. Und wenn Sie bereits die Migration auf Jetty 12 durchführen, lässt sich ein Großteil dieser Arbeit übertragen, was den Verbleib bei Jetty für viele Teams zum reibungsloseren Weg macht.

Mit TuxCare sicher durch die EOL-Phase von Eclipse Jetty

Die Versionsfrage ist geklärt. Jetty 8, 9, 10 und 11 haben das Ende ihres Lebenszyklus erreicht; die Veröffentlichung neuer Versionen der Reihen 9, 10 und 11 wurde am 1. Januar 2026 eingestellt, und die Umstellung auf Jetty 12 ist kein bloßer Haken auf einer Checkliste, sondern ein echtes Projekt. Die offene Frage ist, wie Sie die Lücke zwischen heute und dem Abschluss der Migration überbrücken.

Wenn Sie in diesem Quartal auf Jetty 12 umsteigen können, tun Sie dies und planen Sie die Arbeiten an JDK 17 und Spring Boot 3.2 realistisch ein. Falls dies nicht möglich ist, sollten Sie die Software nicht ohne Patches betreiben, da es zwar korrigierte Builds für die EOL-Versionen gibt, diese jedoch nicht mehr öffentlich veröffentlicht werden. Der vom Anbieter bereitgestellte Support sorgt dafür, dass bekannte Sicherheitslücken behoben werden, und liefert Ihnen während Ihrer Planung den Nachweis eines aktiven Behebungsprozesses. Erfahren Sie hier, wie TuxCare mit Open-Source-Software am Ende der Lebensdauer umgehtund informieren Sie sich über die Preise , um sie mit Ihrem Portfolio abzugleichen.

FAQs

Welche Eclipse-Jetty-Versionen werden noch unterstützt?

Nur Jetty 12.0 und 12.1 werden von der Community unterstützt. Jetty 12.1 ist die aktuelle Version und erhält aktive Fehlerbehebungen; 12.0 erhält zwar noch Updates, doch Webtide hat angekündigt, dass diese irgendwann im Jahr 2026 eingestellt werden, ohne jedoch ein konkretes Datum zu nennen. Alle älteren Versionen, einschließlich Jetty 8, 9, 10 und 11, sind nicht mehr unterstützt.

Ist Eclipse Jetty 9 im Produktivbetrieb noch sicher einsetzbar?

Nicht ohne eine aktive Quelle für Sicherheitsupdates. Jetty 9.4 hat das Ende seines Lebenszyklus erreicht; die letzte öffentliche Version war 9.4.58.v20250814 im August 2025, und seit dem 1. Januar 2026 werden keine 9.x-Versionen mehr auf Maven Central veröffentlicht. Es gibt zwar spätere, korrigierte Builds, diese sind jedoch nur über Anbieter von erweitertem Support erhältlich. 9.4 verantwortungsbewusst zu betreiben bedeutet daher, diesen Support sicherzustellen oder durch entsprechende Kontrollmaßnahmen im Vorfeld abzusichern und einen Migrationsplan für beide Fälle zu haben.

Wie kann ich feststellen, ob meine Spring Boot-Anwendung eine EOL-Version von Jetty verwendet?

Führen Sie folgenden Befehl aus mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ oder ./gradlew dependencies | grep -i jettyaus. Behalten Sie den Platzhalter bei, da Jetty 12 Umgebungsartefakte unter Gruppen-IDs wie „org.eclipse.jetty.ee10“ veröffentlicht, die ein Filter für exakte Übereinstimmungen übersehen würde. Wenn die Ausgabe ein Jetty-Artefakt der Versionsreihe 9.x, 10.x oder 11.x anzeigt, befindet sich Ihre App auf einer EOL-Linie, selbst wenn Jetty als transitive Abhängigkeit hinzugekommen ist, die Sie nie deklariert haben.

Ist für ein Upgrade von Jetty 10 auf Jetty 12 eine Umstellung von „javax“ auf „jakarta“ erforderlich?

Dies gilt nur, wenn Sie die EE10- oder EE11-Umgebung von Jetty 12 nutzen. Jetty 10 verwendet „javax.servlet“, EE10 verwendet „jakarta.servlet“ (Servlet 6.0) und EE11 verwendet Servlet 6.1. Jetty 12 enthält außerdem EE8- und EE9-Umgebungen, wobei EE8 den Namensraum „javax.*“ beibehält. Daher können Sie zunächst den Jetty-Kern und das JDK migrieren und die Umstellung des Namensraums als eigenständiges Projekt behandeln.

Welche JDK-Version benötigt Eclipse Jetty 12?

Java 17. Sowohl Jetty 12.0 als auch 12.1 setzen Java 17 als Mindestlaufzeitumgebung voraus. Daher ist ein JDK-Upgrade der erste entscheidende Schritt für jedes Team, das von Jetty 9, 10 oder 11 unter Java 8 oder Java 11 umsteigt.

Zusammenfassung

Artikel Name

Eclipse Jetty – Ende der Lebensdauer (EOL): Versionen, Upgrade-Pfad und Optionen

Beschreibung

Die Versionen Jetty 8, 9, 10 und 11 haben das Ende ihres Lebenszyklus erreicht, und die Veröffentlichung neuer Versionen wurde im Januar 2026 eingestellt. Hier finden Sie die Versionsdaten, Befehle zur Erkennung sowie Ihre Optionen.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers