Apache CXF EOL: Versionen, Supportstatus und nächste Schritte

Wichtigste Erkenntnisse

• Apache CXF 3.5.x und frühere Versionen haben das Ende ihres Lebenszyklus erreicht; von Apache sind keine weiteren Sicherheitspatches mehr zu erwarten.
• Derzeit sind nur die Versionsreihen 4.1.x und 4.2.x aktuell – für 3.6.x und 4.0.x sind die letzten geplanten Versionen bereits erschienen.
• „EOL CXF“ bedeutet, dass es derzeit bekannte, noch nicht gepatchte CVEs gibt und dass Apache keine Korrekturen für später entdeckte Schwachstellen bereitstellt.
• Sie haben folgende Möglichkeiten: ein Upgrade auf CXF 4.x, einen vollständigen Austausch oder die Inanspruchnahme des erweiterten Supports, um in der Zwischenzeit weiterhin mit den neuesten Patches versorgt zu bleiben.

Wenn Sie über einen Java-Services-Stack verfügen, der schon seit den Tagen von Spring XML im Einsatz ist, ist die Wahrscheinlichkeit groß, dass Apache CXF irgendwo darin enthalten ist und still und leise Ihre SOAP-Endpunkte, die eine oder andere JAX-RS-API und vielleicht eine WS-Security-Integration verwaltet, die seit Jahren niemand mehr geöffnet hat. Und die Wahrscheinlichkeit ist nicht gering, dass für die von Ihnen verwendete Version schon seit einiger Zeit keine Patches mehr bereitgestellt werden.

Alle CXF-Versionen der 3.5.x-Reihe und früher haben das Ende ihrer Lebensdauer erreicht, was bedeutet, dass vom Apache-Projekt keine Sicherheitsupdates mehr bereitgestellt werden.

In diesem Beitrag erfahren Sie, welche CXF-Versionen nicht mehr unterstützt werden, was dies konkret für Ihre Sicherheit und Compliance bedeutet und welche drei realistischen Optionen Sie haben: ein Upgrade auf 4.x, den vollständigen Austausch von CXF oder die Gewährung von mehr Zeit durch erweiterten Support.

Ist Apache CXF nicht mehr weiterentwickelt?

Apache veröffentlicht keine festen EOL-Termine für CXF. In der Praxis funktioniert dies nach einem rollierenden Modell: Die Zweige, für die Apache aktiv Releases veröffentlicht, sind auf der Download-Seite des Projekts zu finden, und sobald neue Versionen erscheinen, werden ältere entfernt und nicht mehr weiterentwickelt. Derzeit wird auf dieser Seite CXF 4.2.x als aktuellster Zweig aufgeführt (Baseline JDK 17, Jakarta EE 11), dicht gefolgt von 4.1.x (JDK 17, Jakarta EE 10). Die 3.6.x-Reihe hat bereits das veröffentlicht, was Apache ausdrücklich als ihre letzte geplante Version bezeichnet, nämlich 3.6.11, und die 4.0.x-Reihe wurde auf die gleiche Weise mit 4.0.11 abgeschlossen – bei keinem dieser Zweige sollten Sie mit zukünftigen Fehlerbehebungen rechnen.

Alles ab Version 3.5.x und darunter ist abgeschlossen. Apache hat die letzte Wartungsversion der 3.5.x-Reihe (3.5.11) veröffentlicht und sich neuen Projekten zugewandt – keine Backports, keine CVE-Korrekturen, es ist nichts mehr zu erwarten. Wenn Ihr Maven- oder Gradle-Build „org.apache.cxf“ noch auf Version 3.5.x oder früher festlegt, verwenden Sie EOL-Software in der Produktion, unabhängig davon, ob jemand darauf hingewiesen hat oder nicht.

Zu beachtende EOL-Versionen und Supportstatus von Apache CXF

Apache veröffentlicht für CXF keine offiziellen Enddaten für „aktive LTS“- und „Wartungs-LTS“-Versionen, wie es bei einigen anderen Laufzeiten der Fall ist. Der Support richtet sich danach, welcher Zweig aktuell ist. Daher ordnet die nachstehende Tabelle jeden Zweig seiner jeweiligen JDK-Basisversion, seinem Namespace und seinem aktuellen Status auf der Download-Seite von Apache zu, anstatt nicht existierende Meilensteine zu erfinden.

CXF-Zweigstelle	JDK-Baseline / Namensraum	Status der Apache-Unterstützung
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	Aktuell, aktuellste
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	Aktuell
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	Letzte geplante Version veröffentlicht (4.0.11); nun archiviert
3.6.x	JDK 11 / Java EE 8 (javax.*)	Letzte geplante Version veröffentlicht (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	Ende des Supportzyklus (letzte Version: 3.5.11)
3.4.x und früher	JDK 8 / javax.*	Ende des Lebens

Achtung: Die Umstellung von javax.* auf jakarta.* fällt genau auf die Grenze zwischen den Versionen 3.x und 4.x. Das ist kein Konfigurationsflag, das man einfach umschalten kann – es ist der wichtigste Grund dafür, dass der Sprung von CXF 3 auf CXF 4 zu einem echten Migrationsprojekt wird und nicht nur zu einem Versionswechsel.

Was das Ende des Supports für Apache CXF für Ihre Java-Services-Umgebung bedeutet

Der Einsatz einer CXF-Version, deren Lebenszyklus beendet ist, ist kein abstraktes strategisches Problem, das irgendwo in einer Tabellenkalkulation steht. Er hat drei konkrete Auswirkungen: die CVEs, die offen bleiben, diejenigen, von denen man nie etwas erfahren wird, und die Bibliotheken, die CXF mit sich bringt.

Nicht behobene CVEs mit öffentlich dokumentierten Lösungen

Die CVEs sind bereits bekannt, und je älter Ihr Branch ist, desto mehr davon betreffen Sie.

CVE-2022-46363 ermöglicht das Auflisten von Verzeichnissen aus der Ferne oder die Exfiltration von Code, wenn das CXFServlet mit den Attributen „static-resources-list“ und „redirect-query-check“ zusammen falsch konfiguriert ist. Das NVD bewertet die Schwachstelle mit 7,5; die Korrekturen wurden in den Versionen 3.5.5 und 3.4.10 implementiert. CVE-2024-28752, eine SSRF-Sicherheitslücke, die ausschließlich Bereitstellungen betrifft, die Aegis DataBinding verwenden (nicht die Standard-Datenbindung), weist einen NVD-Wert von 9,3 auf und betrifft Versionen vor 4.0.4, 3.6.3 und 3.5.8. Diese beiden Patch-Versionen zeigen, wie sich die Backports im Laufe der Zeit verengen: Der Fix aus dem Jahr 2022 erreichte sowohl 3.4.x als auch 3.5.x, während der Fix aus dem Jahr 2024 bei 3.5.8 endete – er erreichte 3.4.x überhaupt nicht. Je weiter zurück Ihr Branch liegt, desto früher verschwindet er aus der Liste der behobenen Versionen.

Und das ist kein historisches Problem. Apache hat allein im Jahr 2026 14 neue CXF-Sicherheitshinweise veröffentlicht, darunter eine XXE-Sicherheitslücke in der WS-Transfer-Funktionalität, eine LDAP-Injection-Schwachstelle im XKMS-LDAP-Repository, eine Reihe von OAuth2-Schwachstellen sowie einen unvollständigen Fix für ein früheres JMS-bezogenes Problem zur Remote-Code-Ausführung. Aktuelle Zweige übernehmen diese Korrekturen. Ausgelaufene Zweige tun dies nicht.

Das ist wirklich die Gefahr bei nicht mehr unterstützter Software. Die Sicherheitslücke ist dokumentiert, der Patch ist öffentlich, der Diff ist direkt in der Commit-Historie zu finden. Angreifer müssen nichts selbst aufdecken – sie können die Sicherheitsmitteilung und den Patch studieren und dann nach Installationen suchen, auf denen noch eine anfällige Version läuft. Der Verizon DBIR 2026 ergab, dass die Ausnutzung von Sicherheitslücken mittlerweile der mit Abstand häufigste Erstzugangsvektor ist und 31 % der Sicherheitsvorfälle ausmacht – ein Anstieg gegenüber 20 % im Vorjahr. Damit hat sie zum ersten Mal in der 19-jährigen Geschichte des Berichts den Missbrauch von Zugangsdaten vom ersten Platz verdrängt.

Die CVEs, für die Apache in Ihrem Zweig niemals Patches bereitstellen wird

Das größere Risiko ist das, das man noch nicht erkennen kann. Sobald ein Zweig das Ende seines Lebenszyklus (EOL) erreicht hat, werden Fehler, die danach in diesem Code entdeckt werden, von Apache einfach nicht mehr behoben.

Angenommen, im nächsten Jahr taucht in CXF eine Sicherheitslücke auf, die die 3.5.x-Reihe betrifft. Sie wird in den aktuellen 4.x-Zweigen behoben, bleibt aber überall sonst stillschweigend offen. Sie lesen den Sicherheitshinweis, überprüfen Ihre Version und stellen fest, dass es für Ihren Zweig überhaupt keine gepatchte Version gibt. An diesem Punkt stehen Sie vor einer Notfallmigration oder einem Backport durch den Anbieter, und beides lässt sich nicht von heute auf morgen bewerkstelligen.

Genau diese Lücke soll durch herstellerunterstützte Patches geschlossen werden. Der „Endless Lifecycle Support“ von TuxCare  stellt weiterhin Sicherheitspatches für CXF-Zweige bereit, von denen sich Apache bereits abgewendet hat – eine Möglichkeit, weiterhin Patches zu erhalten, ohne ein Upgrade durchführen zu müssen, für das Sie noch nicht bereit sind.

Wenn Sie sehen möchten, was bereits in Bezug auf EOL-CXF-Versionen und deren Abhängigkeiten erfasst wird, nutzen Sie den TuxCare CVE Tracker können Sie CXF-Sicherheitslücken nach Schweregrad und Behebungsstatus filtern, ohne selbst die NVD durchforsten zu müssen.

Die mitlaufenden transitiven Abhängigkeiten

CXF läuft nicht isoliert. Es bindet Bibliotheken für die XML-Analyse, StAX-Streaming und XML-Sicherheit ein, und jede dieser Bibliotheken hat ihre eigene CVE-Historie, die es zu berücksichtigen gilt.

Wenn CXF auf einer EOL-Version eingefroren wird, werden diese Abhängigkeiten in der Regel ebenfalls eingefroren. Die Auswirkungen reichen tiefer als CXF selbst – sie erstrecken sich auf alle älteren Bibliotheksversionen, auf die sich der eingefrorene Build festgelegt hat. Das gleiche Muster haben wir bei Apache Camel und Apache Struts beobachtet; es ist ein wiederkehrendes Problem bei Frameworks, an denen seit längerer Zeit nicht mehr gearbeitet wurde.

Von der Ausführung von Apache CXF nach Ablauf der Lebensdauer betroffene Compliance-Rahmenwerke

Prüfer interessiert es nicht wirklich, ob CXF „intern“ oder „hinter einer Firewall“ läuft. Nicht unterstützte Software wird in der Regel als eigenständiger Beanstandungspunkt aufgeführt, da sie die Annahmen bezüglich der Patch-Verwaltung untergräbt, auf denen die meisten Rahmenwerke basieren. Genau hier bereitet das EOL von CXF den Anwendern häufig Probleme.

PCI DSS 4.x

PCI DSS Anforderung 6.3.3 sieht vor, dass relevante Patches mit dem Status „kritisch“ oder „hohe Sicherheitsstufe“ innerhalb eines Monats nach ihrer Veröffentlichung installiert werden, während alle anderen relevanten Patches nach einem dokumentierten, risikobasierten Zeitplan installiert werden müssen. Bei einer CXF-Version, deren Support ausgelaufen ist und für die keine Patches mehr verfügbar sind, können beide Zeitpläne nicht eingehalten werden – es gibt nichts mehr, was installiert werden könnte. Befindet sich irgendwo in Ihrer Umgebung für Karteninhaberdaten eine anfällige CXF-Komponente, führt diese Lücke zu einem Befund gemäß Anforderung 6.3.3. Compliance-Tools können die betroffene Version zwar für Sie kennzeichnen, aber sie können keine Patches für Komponenten installieren, die von Apache nicht mehr unterstützt werden.

SOC 2

Die Sicherheitskriterien von SOC 2 setzen voraus, dass Sie über einen funktionierenden Prozess zum Schwachstellenmanagement. Software, für die keine Patches verfügbar sind, lässt sich damit nur schwer vereinbaren. Die Frage, die sich Prüfer letztendlich stellen, lautet nicht, ob Sie Patches schnell installieren – sondern ob Sie überhaupt Patches installieren können. 

FIPS und Arbeitslasten auf Bundesebene

Wenn Sie in einem Umfeld arbeiten, das validierte Kryptografie erfordert, verkompliziert ein EOL-Framework die gesamte Kette. Der Lebenszyklusstatus von CXF macht ein FIPS-validiertes Modul zwar nicht automatisch ungültig, doch ein „eingefrorenes“ Framework kann Sie an Versionen von Krypto-Bibliotheken binden, deren Validierungsstatus abgelaufen ist, ohne dass noch Upstream-Releases verfügbar sind, mit denen Sie weiterarbeiten könnten.

Optionen nach dem Ende des Lebenszyklus von Apache CXF

Sie haben hier drei konkrete Möglichkeiten, und welche davon die richtige ist, hängt davon ab, wie viel Migrationsrisiko Sie derzeit im Vergleich zu später verkraften können. Keine davon lautet „nichts tun“. Das ist seit dem Tag, an dem Ihr Zweig das EOL erreicht hat, keine echte Option mehr.

• Sie können in diesem Quartal keine Migration durchführen, müssen aber auf dem neuesten Stand bleiben? Erweiterter Support.
• Sie haben JDK 17 und Zeit für die Entwicklung? Führen Sie ein Upgrade auf 4.x durch.
• Wird CXF nur wenig genutzt, oder stellen Sie ohnehin auf eine andere Plattform um? Dann ersetzen Sie es.

Nutzen Sie den unbefristeten Lebenszyklus-Support für Apache CXF

Eine direkte Möglichkeit, das unmittelbare Risiko aus dem Weg zu räumen, ohne die Anwendung neu schreiben zu müssen, ist der vom Anbieter unterstützte Sicherheitssupport. Der „Endless Lifecycle Support“ (ELS) von TuxCare sorgt dafür, dass Apache CXF nach dem Ende des Lebenszyklus (EOL) weiterhin gepatcht wird, einschließlich der von Apache vollständig eingestellten Zweige wie 3.5.x, wobei Korrekturen bereitgestellt werden, sobald neue CVEs veröffentlicht werden. Derzeit sind insbesondere CXF 3.5.9 und 3.5.11 abgedeckt, wobei für beide Versionen auch lange nach der letzten 3.5.x-Veröffentlichung von Apache weiterhin CVE-Patches bereitgestellt werden. Die Korrekturen werden über signierte, von TuxCare gehostete Repositorys verteilt, die sich in Ihren bestehenden Maven- oder Gradle-Workflow integrieren lassen.

Was die meisten Teams unterschätzen, ist der Abhängigkeitsbaum. CXF wird mit Laufzeitbibliotheken für die XML-Analyse, die Schemaverarbeitung und die Sicherheit ausgeliefert, und diese müssen genauso gepatcht werden wie der CXF-eigene Code. TuxCare ELS deckt sowohl direkte als auch transitive Abhängigkeiten ohne zusätzliche Kosten ab, sodass Sie nicht das Framework patchen müssen, während eine anfällige Bibliothek tiefer im Baum ungepatcht bleibt.

Dieser Weg ist vor allem dann sinnvoll, wenn die Migration einen hohen technischen Aufwand erfordert und Sie sie derzeit nicht einplanen können. Sie bleiben bei Ihrer aktuellen Version, Ihre SOAP- und REST-Dienste laufen ohne Neuprogrammierung weiter, und Sie erhalten weiterhin Sicherheitsupdates, während Sie das Upgrade in Ihrem eigenen Tempo planen, anstatt unter dem Druck einer Sicherheitslücke zu stehen. Es ist eine Brücke, nicht das Ziel. Das Ziel bleibt weiterhin, irgendwann auf den aktuellen Stand zu kommen – nur zu Bedingungen, die Sie tatsächlich selbst bestimmen können.

Es eignet sich besonders gut für zwei Situationen: einen eingefrorenen, aber geschäftskritischen Dienst, der eine Migration von javax.* zu jakarta.* in diesem Jahr nicht verkraften kann, und eine geerbte Codebasis, bei der noch niemand den Umfang der Migration vollständig ermittelt hat. In beiden Fällen verschafft ELS genau das zurück, was das EOL-Ende mit sich bringt: Zeit.

Upgrade auf Apache CXF 4.x

Die saubere, langfristige Lösung besteht darin, auf einen aktuellen 4.x-Zweig umzusteigen. Das ist die richtige Entscheidung, wenn Sie über die entsprechenden technischen Ressourcen verfügen und Ihre Laufzeitumgebung tatsächlich umgestellt werden kann.

Es gibt dabei zwei Haken. Erstens läuft CXF 4.x auf dem „jakarta.*“-Namespace, sodass alle „javax.ws.rs“- und „javax.xml.ws“-Importe sowie damit verbundene Importe in Ihrem Anwendungscode umgestellt werden müssen, und jede Abhängigkeit, die noch auf den alten „javax.*“-APIs basiert, muss jakarta-kompatibel aktualisiert oder ersetzt werden. Zweitens hat sich die JDK-Basis geändert: CXF 4.0.x basiert auf JDK 11, während 4.1.x und 4.2.x JDK 17 erfordern. Tools wie der Eclipse Transformer können einen Großteil der Namensraumumstellung automatisch übernehmen, aber alles, was in Ihrer Konfiguration reflektiv oder stringbasiert ist, muss manuell überprüft werden. Betrachten Sie dies als ein Projekt und nicht als eine Aufgabe für einen Nachmittag.

Ein Hinweis zum neuesten Zweig: Apache weist darauf hin, dass die aktuelle Version 4.2.x auf Alpha-Builds von Undertow basiert, sodass die Undertow-Integration möglicherweise noch nicht stabil ist. Wenn Undertow Teil Ihrer Infrastruktur ist, ist die Version 4.1.x vorerst die sicherere Wahl.

CXF durch ein alternatives Framework oder einen alternativen Ansatz ersetzen

Wenn CXF nur einen kleinen Teil Ihres Stacks abdeckt, kann dessen Austausch tatsächlich weniger Aufwand bedeuten als eine vollständige Migration auf Version 4.x. Teams, die überwiegend REST-Endpunkte betreiben, wechseln manchmal zu Spring MVC oder WebFlux auf Spring Boot oder zu einer JAX-RS-Implementierung wie Jersey oder RESTEasy. Für intensive SOAP- und WS-Security-Nutzer gibt es ehrlich gesagt nicht so viele saubere Ausstiegsmöglichkeiten, da CXF ursprünglich genau für diese Art von Workload entwickelt wurde – und genau deshalb bleiben diese Teams oft länger bei CXF, als ihnen lieb ist.

Seien Sie ehrlich zu sich selbst, was den Aufwand angeht, bevor Sie sich darauf festlegen. Ein Austausch bedeutet eine Neudefinition Ihrer Service-Grenzen – mit allen damit verbundenen Tests. Wenn Sie umfangreiche WSDL-Verträge, WS-Security-Richtlinien oder MTOM-Anhänge im Spiel haben, unterschätzt der Ansatz „einfach das Framework austauschen“ den tatsächlichen Arbeitsaufwand in der Regel bei weitem.

Sichern Sie Apache CXF auch nach Ablauf der Supportfrist mit TuxCare

Der Einsatz von Apache CXF, dessen Lebenszyklus bald endet (EOL), birgt ein schleichendes Risiko. Es funktioniert einwandfrei – bis eine öffentlich bekannte CVE oder ein Audit die Situation über Nacht zu einem Notfall macht. Sie müssen sich nicht zwischen einer sofortigen, mit Umstellungen verbundenen Migration und dem stillen Hinnehmen des Risikos entscheiden.

Durch den erweiterten Support bleibt Ihre aktuelle Version auf dem neuesten Stand, während Sie das Upgrade nach Ihrem eigenen Zeitplan planen können, und eine Migration auf Version 4.x oder ein Framework-Wechsel löst dieses spezielle EOL-Problem, sobald Sie dazu bereit sind. Der einzige Weg, der immer schlecht endet, ist, die Sache einfach auf sich beruhen zu lassen. Beginnen Sie damit, die Kosten Ihrer Optionen zu ermitteln, oder sehen Sie sich an, wie TuxCare ältere Open-Source-Stacks ganz allgemein sicher hält unter ELS für Open-Source-Software.

FAQs