Ende der Unterstützung für Apache Struts: Sorgen Sie für die Sicherheit Ihrer Java-Webanwendungen | TuxCare ELS

Wichtigste Erkenntnisse

• Wenn eine Struts-Version das Ende ihres Lebenszyklus erreicht, werden für den gesamten Abhängigkeitsstapel – darunter OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2 und andere – ebenso wie für das Framework selbst keine koordinierten Sicherheitspatches mehr bereitgestellt.
• Die Migration von Struts 2.5.x auf 6.x erfordert Upgrades der Java-Laufzeitumgebung, Änderungen an der Servlet-API, die Neufassung von OGNL-Ausdrücken, den Austausch von Interceptor-Schnittstellen sowie die Beseitigung von Zugriffsmustern auf statische Methoden – all dies erfordert eine sorgfältige Planung und umfangreiche Tests und lässt keinen Spielraum für einen engen Zeitplan.
• TuxCare ELS erweitert den Sicherheitsschutz für Struts-Versionen, deren Lebenszyklus beendet ist, sowie deren Abhängigkeitsstrukturen, sodass Unternehmen die Sicherheit und Compliance gewährleisten können, während sie eine wohlüberlegte, mit ausreichenden Ressourcen ausgestattete Migration nach ihrem eigenen Zeitplan planen.

Struts ist seit über zwei Jahrzehnten das Rückgrat der Java-Webentwicklung im Unternehmensbereich. Seine Model-View-Controller-Architektur, das ausgereifte Plugin-Ökosystem und die tiefe Integration in den breiteren Java-Enterprise-Stack haben es zum bevorzugten Framework für groß angelegte Webanwendungen in den Bereichen Finanzdienstleistungen, Behörden, Gesundheitswesen und Telekommunikation gemacht. Doch Struts hat eine Geschichte, die die Frage nach dem Ende des Lebenszyklus zu einer Angelegenheit von ungewöhnlich hoher Tragweite macht. Es weist die folgenschwerste CVE-Bilanz aller Java-Web-Frameworks in der Produktion auf, und Unternehmen, die EOL-Versionen von Apache Struts einsetzen, tragen ein Risikoprofil, das durch den Equifax-Hack von 2017 von einer theoretischen Gefahr zu einer Schlagzeile auf den Titelseiten wurde.

Dieser Artikel erläutert, was das Ende des Lebenszyklus (EOL) von Apache Struts für Java-Anwendungsteams tatsächlich bedeutet, wo sich die tatsächlichen Sicherheitsrisiken im Abhängigkeitsbaum verbergen, warum der Migrationspfad zu aktuellen Versionen anspruchsvoller ist, als es zunächst den Anschein hat, und wie Sie mit dem „Endless Lifecycle Support“ (ELS) von TuxCare vollständige Sicherheit und Compliance gewährleisten können, ohne eine Migration erzwingen zu müssen, für die Ihre Teams noch nicht bereit sind.

Wie sieht der Produktlebenszyklus von Apache Struts aus?

Struts folgt keinem formell dokumentierten, zeitbasierten Release-Rhythmus, wie dies bei einigen anderen Open-Source-Projekten der Fall ist. Das PMC der Apache Software Foundation, das für das Projekt verantwortlich ist, veröffentlicht EOL-Mitteilungen direkt auf der Projektwebsite, wenn ein Hauptzweig kurz vor dem Ende seiner Lebensdauer steht, und gibt in der Regel eine sechsmonatige Vorwarnung, bevor der Support offiziell endet. EOL-Mitteilungen sind nicht an einen festen Kalender gebunden; sie spiegeln die Kapazitäten der Community zur Pflege eines bestimmten Zweigs sowie die Verfügbarkeit eines unterstützten Nachfolgers wider.

Sie können sich beispielsweise unseren Leitfaden zum Ende der Lebensdauer von Apache Kafka ansehen, um zu erfahren, wie Streaming-Infrastrukturen mit ähnlichen Support-Abbrüchen umgehen, oder nachlesen, wie Big-Data-Frameworks den Meilenstein „Ende der Lebensdauer “ von Apache Spark bewältigen. Wenn Sie Data-Warehousing-Komponenten verwalten, können Sie in unserem ausführlichen Leitfaden außerdem mehr über das Ende der Lebensdauer von Apache Hive erfahren.

Das Projekt folgt den Regeln der semantischen Versionierung und bietet weiterhin Unterstützung für seine derzeit aktiven Zweige. In der Vergangenheit wurden EOL-Mitteilungen stets mit einer sechsmonatigen Übergangsphase begleitet, in der nach der ersten Ankündigung ausschließlich Sicherheitspatches bereitgestellt wurden; danach erhält der Zweig keinerlei Patches mehr. Das bedeutet, dass es keine Übergangsfrist für Sicherheitslücken gibt, die nach dem endgültigen EOL-Datum bekannt werden; für jede CVE, die einen EOL-Zweig betrifft, wird kein offizieller Community-Fix bereitgestellt.

Aktueller Support-Status der Struts-Version:

Version	Datum der Veröffentlichung	Auslaufdatum	Status
Struts 1x	2000–2008	April 2013	EOL
Struts 2.3x	2012	Mai 2019	EOL
Struts 2.5x	Mai 2016	April 30, 2024	EOL
Struts 6x	Juni 2022	Noch nicht bekannt gegeben	Aktiv (aktuell)
Struts 7x	Dezember 2024	Noch nicht bekannt gegeben	Aktiv

Struts 2.5.x, die in Unternehmensumgebungen am häufigsten eingesetzte Version, erhielt im Dezember 2023 ihre finale Version (2.5.33) und erreichte am 30. April 2024 offiziell das Ende ihres Lebenszyklus. Unternehmen, die ihre Migration auf Struts 6.x oder 7.x noch nicht abgeschlossen haben, nutzen nun ein Apache Struts-Framework, dessen Lebenszyklus abgelaufen ist und für das keine Sicherheitspatches mehr bereitgestellt werden.

Die praktischen Auswirkungen dieses Lebenszyklusmodells sind erheblich. Da das Projekt keine festen EOL-Termine Jahre im Voraus bekannt gibt, stellen Unternehmen häufig fest, dass eine EOL-Ankündigung eintrifft, bevor eine Migration budgetiert, mit Ressourcen ausgestattet und geplant wurde. Die sechsmonatige Vorlaufzeit für das EOL von Apache Struts reicht für große Unternehmensanwendungen mit umfangreicher Struts-Integration nicht aus, um eine getestete und validierte Migration abzuschließen.

Was bedeutet das Ende der Lebensdauer von Apache Struts für Java-Webanwendungen?

Für Unternehmen, die Struts als Webschicht für geschäftskritische Java-Anwendungen einsetzen, die öffentlich zugängliche HTTP-Anfragen bearbeiten, Datei-Uploads verwalten, Formularübermittlungen verarbeiten und vor Geschäftslogikschichten stehen, die auf Finanzdaten, Patientendaten oder behördliche Systeme zugreifen, ist die EOL-Kennzeichnung von Apache Struts keine reine Verwaltungsangelegenheit. Es handelt sich um ein Sicherheitsereignis mit direkten Auswirkungen auf die Compliance.

Nach dem EOL-Datum werden keine Sicherheitspatches mehr bereitgestellt

Sobald eine Struts-Version das Ende ihres Lebenszyklus erreicht hat, stellt die Apache-Community die Veröffentlichung von Sicherheitspatches für diese Version ein. Für alle Sicherheitslücken, die nach dem EOL-Datum bekannt werden – sei es im Kern-Dispatcher des Frameworks, in der OGNL-Auswertungs-Engine, bei der Verarbeitung von Datei-Uploads oder im Interceptor-Stack –, wird kein offizieller Patch mehr bereitgestellt. Die einzige Abhilfemaßnahme, die die Community anbietet, ist die Migration auf eine unterstützte Version.

Für Teams, die große, produktionskritische Webanwendungen betreiben, bei deren Migration Action-Klassen neu geschrieben, Interceptor-Schnittstellen ersetzt, OGNL-Ausdrücke in allen Vorlagen aktualisiert und das Verhalten über Dutzende oder Hunderte von Anwendungsendpunkten hinweg validiert werden müssen, ist dies kurzfristig nicht immer möglich. Genau in der Zeitspanne zwischen dem Inkrafttreten des EOL-Status und dem Zeitpunkt, zu dem eine Migration realistisch abgeschlossen und validiert werden kann, häufen sich ungepatchte Sicherheitslücken an.

Sicherheits- und Compliance-Risiken nach Ablauf der Lebensdauer

Die Auswirkungen auf die Compliance beim Einsatz einer Struts-Version am Ende des Lebenszyklus (EOL) sind unmittelbar. PCI DSS (Anforderung 6.3.3) schreibt vor, dass Patches für kritische und hochgradige Sicherheitslücken innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen. Bei einer Struts-Version am Ende des Lebenszyklus gibt es jedoch keine Patches, die installiert werden könnten, sodass eine Einhaltung der Vorschriften auf normalem Wege unmöglich ist. SOC-2-Prüfer weisen auf Software hin, deren Lebenszyklus in Produktionsumgebungen abgelaufen ist. Unternehmen, die Apache Struts-Bereitstellungen mit abgelaufenem Lebenszyklus betreiben, sehen sich mit Dokumentationslücken konfrontiert, die in Sicherheitsfragebögen zutage treten, die Zertifizierung durch Anbieter verzögern und in regulierten Branchen die Verlängerung von Kundenverträgen verhindern.

Für Unternehmen, in denen Struts-Anwendungen in einem PCI-Geltungsbereich betrieben werden, personenbezogene Daten verarbeiten oder Dienste mit vertraglichen SLA-Verpflichtungen unterstützen, ist das Compliance-Risiko aufgrund dieses EOL-Ereignisses keine theoretische Angelegenheit. Es handelt sich um einen Audit-Befund, der nur darauf wartet, aufgedeckt zu werden.

CVE-Verlauf: Was die Schwachstellenliste verrät

Struts weist von allen Java-Web-Frameworks, die derzeit im Einsatz sind, die umfangreichste Liste an CVE-Einträgen auf, und diese Entwicklung macht deutlich, warum die Bereitstellung von Patches für Produkte am Ende ihrer Lebensdauer (EOL) keine Option ist.

CVE-2017-5638 (CVSS 10.0 Kritisch) ist die Sicherheitslücke, durch die bei dem Equifax-Hack – einem der schwerwiegendsten Datenlecks der Geschichte – persönliche und finanzielle Daten von 147 Millionen Menschen offengelegt wurden. Die Schwachstelle lag im Jakarta Multipart-Parser: Ein Angreifer konnte einen bösartigen Content-Type-HTTP-Header erstellen, der eine fehlerhafte Ausnahmebehandlung im Parser auslöste, was zur Ausführung beliebiger Befehle auf dem Server unter den Berechtigungen des Webserver-Prozesses führte. Es war keine Authentifizierung erforderlich. Exploits waren innerhalb weniger Tage nach der Offenlegung öffentlich verfügbar, und die aktive Ausnutzung in der Praxis begann sofort. Ein Patch wurde am 7. März 2017 veröffentlicht. Da Equifax diesen nicht installierte, blieben ihre Systeme 144 Tage lang ungeschützt – lange genug, damit Angreifer im Rahmen einer ausgedehnten Kampagne Sozialversicherungsnummern, Geburtsdaten und Führerscheinnummern abgreifen konnten. Der Vorfall führte zu einem Vergleich in Höhe von 700 Millionen US-Dollar, einer Anhörung vor dem Kongress und wurde zum definitiven Fallbeispiel dafür, was eine ungeschützte Struts-Anfälligkeit tatsächlich kostet. Die Lösung war verfügbar. Das Zeitfenster zwischen der Verfügbarkeit des Patches und seiner Installation war ausschlaggebend für den Ausgang.

CVE-2023-50164 (NVD CVSS 3.1: 9,8 Kritisch) zeigte, dass die kritische RCE-Sicherheitslücke in Struts nicht mit der Schwachstellengeneration von 2017 endete. Diese Schwachstelle lag in der Datei-Upload-Logik des Frameworks: Ein Angreifer konnte Datei-Upload-Parameter manipulieren, um einen Pfadtraversal zu ermöglichen, und anschließend eine schädliche Datei an einen für den Webserver zugänglichen Speicherort hochladen – wodurch die Ausführung von Remote-Code ermöglicht wurde. Der CVSS-Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H deutet darauf hin, dass keine Authentifizierung erforderlich ist, keine Benutzerinteraktion stattfindet, der Zugriff über das Netzwerk möglich ist und die Vertraulichkeit, Integrität und Verfügbarkeit vollständig kompromittiert sind. Proof-of-Concept-Exploits wurden innerhalb weniger Tage nach der Offenlegung im Dezember 2023 veröffentlicht. Die betroffenen Versionen umfassten die gesamte Struts-2-Historie von 2.0.0 bis 2.5.32 und von 6.0.0 bis 6.3.0. Struts 2.5.33 erhielt einen Patch – allerdings ist Struts 2.5.33 die letzte Version der Struts 2.5.x-Reihe, was bedeutet, dass dieser Zweig nun das Ende der Lebensdauer (EOL) erreicht hat. Alle künftig gegen Struts 2.5.33 offengelegten CVEs werden keine Community-Korrektur erhalten.

CVE-2024-53677 (NVD CVSS 3.1: 9,8 Kritisch) ist das anschaulichste Beispiel dafür, was der EOL-Status von Apache Struts heute in der Praxis bedeutet. Diese im Dezember 2024 bekannt gewordene kritische Path-Traversal-Sicherheitslücke im Datei-Upload-Mechanismus von Struts betrifft alle Versionen von Struts von 2.0.0 bis 6.3.0.2 – einschließlich Struts 2.5.33, der letzten EOL-Version. Der Angriffsvektor ist identisch mit dem von CVE-2023-50164: Ein Angreifer manipuliert Datei-Upload-Parameter, um zu einem unbeabsichtigten Serverpfad zu gelangen und eine schädliche Datei hochzuladen, wodurch er Remote-Code-Ausführung erreicht. Die Behebung erfordert ein Upgrade auf Struts 6.4.0 und die Migration zum neuen Action File Upload-Interceptor. Struts 2.5.33 erhielt als EOL-Zweig keinen Patch. Jede Organisation, die noch Struts 2.5.x einsetzt, ist dauerhaft dieser kritischen RCE-Sicherheitslücke ausgesetzt, ohne dass ein offizieller Behebungsweg verfügbar ist – genau das Apache Struts EOL-Risikoszenario, das dieser Artikel behandelt.

Genau diese Art von Sicherheitslücke – nicht authentifizierter, über das Netzwerk zugänglicher RCE in der Webanwendungsinfrastruktur im Produktivbetrieb – stellt bei EOL-Versionen ein dauerhaft ungelöstes Sicherheitsrisiko dar. Der Fall Equifax hat gezeigt, dass es sich hierbei nicht um ein Risiko handelt, das Unternehmen allein durch Überwachung oder Erkennung bewältigen können. Die einzige dauerhafte Abhilfe ist eine gepatchte Version.

Das verborgene Risiko: Der Abhängigkeitsbaum von Struts

Die Angriffsfläche einer Struts-Installation beschränkt sich nicht nur auf die Framework-Binärdatei selbst. Struts wird mit einer Vielzahl von Abhängigkeiten ausgeliefert, die ihre eigenen Sicherheitsrisiken mit sich bringen – und wenn Struts das Ende seines Lebenszyklus erreicht, endet auch die koordinierte Bereitstellung von Patches für diese Abhängigkeiten im Zusammenhang mit dieser Struts-Version.

Das Modul „struts2-core“ bezieht OGNL (die „Object-Graph Navigation Language“-Bibliothek) als direkte Laufzeitabhängigkeit ein – und OGNL hat eine eigene CVE-Historie, die auf seine Rolle als primäre Engine zur Auswertungsauswertung zurückzuführen ist, die bei zahlreichen Struts-Sicherheitslücken ausgenutzt wurde. FreeMarker ist für die Template-Rendering enthalten. Apache Commons FileUpload verarbeitet Multipart-Formulardaten und war direkt an CVE-2017-5638 beteiligt. Apache Commons BeanUtils, Commons Collections, Commons IO und Commons Lang sind allesamt Laufzeitabhängigkeiten. Log4j2 ist für die Protokollierung enthalten – eine Bibliothek, deren eigene Geschichte kritischer Sicherheitslücken (Log4Shell, CVE-2021-44228) eine eigene Welle von Notfall-Patches im gesamten Java-Ökosystem ausgelöst hat. Jackson Databind übernimmt die JSON-Verarbeitung in Plugins. Die Integration des Spring-Frameworks bringt spring-core, spring-beans, spring-context, spring-web und Spring AOP mit sich, wenn das Spring-Plugin verwendet wird. Hibernate Validator wird für die Bean-Validierung hinzugezogen.

Jede dieser Abhängigkeiten verfügt über einen eigenen CVE-Stream. Wenn ein Struts-Zweig das Ende seines Lebenszyklus (EOL) erreicht, stellt die Community die Veröffentlichung koordinierter Updates für alle diese Abhängigkeiten im Rahmen dieser Struts-Version ein. Sicherheitsscanner, die auf EOL-Struts-Installationen ausgeführt werden, generieren Befunde im gesamten Abhängigkeitsbaum, für die für diese Version keine offizielle Korrektur verfügbar ist, sodass Sicherheitsteams mit einer wachsenden Liste nicht behebbarer Scan-Ergebnisse konfrontiert sind.

Der Abhängigkeitsbaum von Struts2-core umfasst mehr als 20 direkte und transitive Abhängigkeiten, wenn gängige Plugins einbezogen werden. Jedes dieser Plugins verfügt über einen eigenen transitiven Baum. Die praktische Patching-Fläche einer Struts 2.5.x-Produktionsumgebung mit einem typischen Plugin-Set ist wesentlich größer als die des Framework-Binärprogramms allein, und jede Komponente in diesem Baum erhält keine koordinierte Unterstützung mehr, sobald der übergeordnete Struts-Zweig das Ende seines Lebenszyklus (EOL) erreicht.

Möglichkeiten für Sicherheit und die Einhaltung von Vorschriften

Unternehmen, die Apache Struts-Versionen nutzen, deren Lebenszyklus abgelaufen ist, haben drei Möglichkeiten. Zwei davon sind mit erheblichem technischem Aufwand, operativen Risiken und längeren Zeitplänen verbunden. Die dritte Möglichkeit – der „Endless Lifecycle Support“ von TuxCare – schließt die Sicherheitslücke sofort, während Ihre Teams die Migration sorgfältig planen.

Option 1: Auf eine aktuelle Struts-Version umsteigen

Die langfristige Lösung besteht darin, die Anwendung auf eine aktuell unterstützte Struts-Version zu migrieren. Die aktiv unterstützten Versionen sind Struts 6.x und Struts 7.x, wobei 7.1.1 die aktuellste Version (Stand: Oktober 2025) ist.

In der Praxis bedeutet dies, insbesondere für große Anwendungen, die auf Struts 2.5.x basieren, dass es sich nicht um eine einfache Versionserhöhung handelt. Es handelt sich vielmehr um eine Migration, die koordinierte Änderungen im gesamten Anwendungscode, in der Konfiguration und in der Laufzeitumgebung erfordert. Struts 6.0 erfordert mindestens Java 8 und die Servlet-API 3.1 – Unternehmen, die ältere Java-Umgebungen nutzen, müssen die Laufzeitumgebung aktualisieren, bevor die Framework-Migration fortgesetzt werden kann. Alle Struts 2.3-Konfigurationskonstanten wurden in 6.0 entfernt; jede Anwendung, die veraltete Konstanten verwendet, muss auf deren Ersatzwerte aktualisiert werden. Der Namespace des XWork-Pakets wurde neu organisiert, was Aktualisierungen der Importe in allen Action-Klassen erfordert. Der Zugriff auf statische Methoden über OGNL-Ausdrücke, ein in vielen Struts 2.x-Anwendungen verwendetes Muster, wurde in 6.0 vollständig entfernt und muss durch Wrapper für Action-Instanzmethoden ersetzt werden. Die Länge von OGNL-Ausdrücken ist standardmäßig auf 256 Zeichen begrenzt, wodurch längere Ausdrücke, die möglicherweise über FreeMarker-Templates und JSPs verteilt sind, unterbrochen werden.

 

Die Umstellung auf Struts 7.x bringt erheblich mehr Anforderungen mit sich, von denen zwei bereits einen enormen Aufwand bedeuten, noch bevor auch nur eine einzige Zeile Struts-Code geändert wird. Erstens erfordert Struts 7.x Java 17 als Mindest-Laufzeitumgebung. Für Unternehmen, die noch Java 8 oder Java 11 einsetzen – was bei Struts-Implementierungen in großen Unternehmen häufig der Fall ist –, bedeutet dies die Planung und Durchführung eines vollständigen JVM-Upgrades in allen Umgebungen: Entwicklung, CI, Staging und Produktion. Zweitens erfordert Struts 7.x Jakarta EE, was bedeutet, dass jeder einzelne `javax.*`-Import im gesamten Code-Bestand auf das entsprechende `jakarta.*`-Äquivalent aktualisiert werden muss. Diese Migration des Namensraums von `javax` zu `jakarta` betrifft `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*` und jedes andere `javax.*`-Paket, wo immer es in Aktionsklassen, Konfigurationsdateien, benutzerdefinierten Interceptors, JSPs und allen Bibliotheken von Drittanbietern im Abhängigkeitsbaum vorkommt, die noch keine Jakarta EE-kompatiblen Versionen veröffentlicht haben. In großen Unternehmens-Codebasen kann diese Namespace-Migration allein Tausende von Import-Anweisungen über Hunderte von Dateien hinweg umfassen und erfordert eine durchgängige Validierung auf jeder Ebene des Anwendungsstacks. Erst nachdem diese beiden Voraussetzungen erfüllt sind, beginnt die Struts-spezifische Migrationsarbeit: Jeder Setter einer Action-Klasse, der Request-Parameter akzeptiert, muss explizit mit `@StrutsParameter` annotiert werden – eine Änderung, die Hunderte von Settern in einer ausgereiften Anwendung betreffen kann. Die Standardwerte für das Namespace-Mapping wurden so geändert, dass exakte Übereinstimmungen erforderlich sind, was möglicherweise zu fehlerhaften Verknüpfungen in bestehenden Vorlagen führt. Der bisherige File Upload Interceptor wurde vollständig entfernt und durch den Action File Upload Interceptor ersetzt, was Konfigurations- und Codeänderungen in Anwendungen erfordert, die Datei-Uploads verarbeiten. Für Anwendungen mit erheblichen Investitionen in Struts – also die meisten Anwendungen, für die die Migrationsfrage von Bedeutung ist – dauert eine ordnungsgemäß geplante und getestete Migration auf Struts 7.x Monate, nicht Wochen.

Option 2: Umstellung auf ein anderes Web-Framework

Manche Unternehmen nutzen das Ende der Lebensdauer von Apache Struts als Anlass, um alternative Java-Web-Frameworks zu prüfen: Spring MVC, Jakarta EE mit Faces, Micronaut, Quarkus oder andere. Das architektonische Argument ist in manchen Kontexten stichhaltig, insbesondere dort, wo moderne REST-First-Architekturen den aktuellen Anforderungen der Anwendung besser gerecht werden oder wo Cloud-native Bereitstellungsmodelle von einem schlankeren Framework profitieren würden.

Eine vollständige Framework-Migration ist weitaus kostspieliger als ein Struts-Versions-Upgrade. Action-Klassen, JSP-Vorlagen, FreeMarker-Ansichten, Tiles-Layouts, Validierungskonfigurationen, Interceptor-Stacks und struts.xml-Zuordnungen müssen alle ersetzt oder erheblich überarbeitet werden. Das Programmiermodell ist anders, das Bereitstellungsmodell ist anders, und Struts-Versionen, deren Lebenszyklus endet (EOL), laufen während des gesamten Evaluierungs-, Planungs- und Migrationsprozesses weiterhin in der Produktion. Dies ist eine strategische Infrastrukturentscheidung, die einen eigenen, sorgfältig geplanten Zeitplan verdient und nicht durch ein vorzeitig eintretendes EOL-Datum erzwungen werden sollte.

Option 3: TuxCare Extended Lifecycle Support: Der empfohlene Weg

Dies ist die Lösung, die das unmittelbare Problem behebt, ohne neue Probleme zu verursachen. Der „Endless Lifecycle Support“ von TuxCare für Struts bedeutet, dass Sie Ihre aktuelle Struts-Version weiterhin in der Produktion einsetzen können und gleichzeitig fortlaufende Sicherheitspatches für das Framework und dessen Abhängigkeitsbaum über Ihre bestehende Maven- oder Gradle-Toolchain erhalten, ohne dass eine erzwungene Migration erforderlich ist.

Die Sicherheitslücke wird sofort geschlossen. Ihre Compliance-Situation bleibt gewahrt. Ihre Teams können die Migration in einem Zeitrahmen planen, der betrieblichen Erfordernissen entspricht – einschließlich der erforderlichen Vorlaufzeit, um Action-Klassen für die Parameterinjektion in Struts 7.x anzupassen, OGNL-Ausdrucksmuster in allen Vorlagen zu aktualisieren und das Verhalten über den gesamten Satz von Anwendungsendpunkten hinweg zu validieren. Keine erzwungene Migration unter Termindruck, kein Compliance-Notfall, keine Verhaltensrückschritte in Produktions-Webanwendungen, die Live-Nutzer bedienen.

Die Risiken einer überstürzten Struts-Migration

Wenn auf einem Sicherheits-Dashboard ein EOL-Status angezeigt wird und das Compliance-Team Fragen stellt, ist der Druck, sofort zu handeln, groß. Zu verstehen, was eine überstürzte Struts-Migration tatsächlich bedeutet, ist genauso wichtig wie das Verständnis für das Risiko selbst.

Was eine Struts-Migration eigentlich beinhaltet

Eine ordnungsgemäße Struts-Migration – insbesondere von 2.5.x auf 6.x oder 7.x – ist ein mehrphasiges Anwendungsprojekt und nicht nur eine einfache Aktualisierung der Abhängigkeitsversionen. Sie erfordert die Überprüfung des gesamten Code-Bestands auf veraltete APIs und entfernte Funktionen, die Aktualisierung der Java-Laufzeitumgebung, falls die aktuelle Version unter den Mindestanforderungen von Struts 6.x liegt, die Aktualisierung von Servlet-API-Referenzen und Deployment-Descriptor-Konfigurationen, das Ersetzen veralteter Konfigurationskonstanten in der gesamten struts.xml, die Aktualisierung aller von der Umstrukturierung des XWork-Pakets betroffenen Action-Klassen-Importe sowie das Umschreiben von OGNL-Ausdrücken, die auf den Zugriff auf statische Methoden angewiesen sind oder die neue Zeichenbegrenzung von 256 Zeichen überschreiten.

Codeanpassung: Jeder Setter einer Action-Klasse, der Formular- oder Request-Parameter akzeptiert, muss mit @StrutsParameter in Struts 7.x versehen werden. In einer großen Anwendung mit Dutzenden oder Hunderten von Action-Klassen handelt es sich hierbei um eine systematische Änderung der Codebasis, die eine gründliche Überprüfung erfordert, um zu vermeiden, dass Injektionspunkte versehentlich ausgelassen werden – was zu stillen Fehlern bei der Verarbeitung von Formularübermittlungen führen würde.

Kompatibilitätsprüfung: Jede JSP-, FreeMarker- und Velocity-Vorlage in der Anwendung muss auf OGNL-Ausdrücke überprüft werden, die den Zugriff auf statische Methoden nutzen, Längenbeschränkungen überschreiten oder auf veraltete Tag-Bibliotheken verweisen. Änderungen im Rendering-Verhalten von Vorlagen – einschließlich der Standard-Auto-Escaping-Einstellungen von FreeMarker – können zu subtilen Unterschieden in der Ausgabe führen, die bei End-to-End-Tests zutage treten.

Anpassung der Toolchain: Build-Konfigurationen, CI/CD-Pipelines und Deployment-Deskriptoren, die auf Struts-spezifische Plugins, DTD-Deklarationen und Konfigurationskonstanten verweisen, müssen überprüft und aktualisiert werden. Das Tiles-Plugin wurde im Laufe der Versionen geändert; die Velocity-Unterstützung wurde in ein eigenes Plugin ausgelagert. Jede Plugin-Abhängigkeit, die in der Zielversion entfernt wurde, muss ersetzt oder aus dem Build entfernt werden.

Testaufwand: Umfassende End-to-End-Tests über die gesamte Anwendung hinweg – einschließlich Formularübermittlungen, Datei-Uploads, Validierungsabläufe, Interceptor-Verhalten und Ergebnisdarstellung – dürfen nicht übersprungen werden. Verhaltensänderungen im Parameter-Injektionsmodell, Standardwerte für Namespace-Zuordnungen und die OGNL-Auswertungssemantik müssen vor der Produktionsfreigabe unter realistischen Anforderungsmustern validiert werden.

Was passiert, wenn eine Migration überstürzt durchgeführt wird?

Wenn Teams diese Arbeit unter Termindruck zusammenpressen, sind die Folgen vorhersehbar und folgen einem einheitlichen Muster.

Erhöhte Support-Belastung: Lücken in den Annotationen von Action-Klassen, versäumte Aktualisierungen von OGNL-Ausdrücken und nicht überprüfte Änderungen bei der Template-Darstellung führen in der Produktion zu Fehlern bei der Formularübermittlung, unterbrochenen Validierungsabläufen und unerwartetem Seitenrendering. Dies löst eine Welle von Vorfällen aus, die die Entwicklungs- und Betriebsteams zusätzlich zu ihrer normalen Arbeitslast bewältigen müssen.

Systeminstabilität: Struts-Anwendungen bilden häufig die Grundlage für kundenorientierte Arbeitsabläufe wie Kreditanträge, Patientenportale und die Einreichung von Anträgen bei Behörden, bei denen sich Verhaltensrückfälle unmittelbar auf echte Nutzer auswirken. Geringfügige Änderungen bei der Parameterbindung, der Ausführungsreihenfolge von Interceptors oder der Darstellung der Ergebnisse können zu sporadischen Fehlern führen, die schwer zu reproduzieren sind und sich erst bei einem Produktionsanfragenvolumen zeigen, das in Vorproduktionstests selten erreicht wird.

Anhäufung technischer Schulden: Unter Zeitdruck implementierte Workarounds werden dauerhaft. Massenweise und ohne Überprüfung annotierte Aktionsklassen führen zu unbeabsichtigten Parameter-Injektionspunkten. OGNL-Ausdrücke wurden schnell umgestaltet, ohne die Sicherheitsauswirkungen des neuen Whitelist-Modells zu verstehen, wodurch Schwachstellen entstanden, die vor der Migration nicht vorhanden waren. Das EOL-Problem von Apache Struts wurde aufgeschoben, nicht gelöst.

Ungeplante Kosten: Notfall-Entwicklungsstunden, verzögerte Feature-Veröffentlichungen, Overhead für die Reaktion auf Vorfälle und die Opportunitätskosten, die entstehen, wenn erfahrene Entwickler Fehler in Produktions-Webanwendungen beheben, anstatt neue Funktionen zu entwickeln – all dies summiert sich schnell und auf eine Weise, die im Voraus schwer vorhersehbar ist.

Die einfache Lösung: TuxCare ELS für Apache Struts EOL

TuxCare bietet unbegrenzten Lebenszyklus-Support für Struts-Versionen, deren Lebenszyklus abgelaufen ist. Anstatt eine Migration zu erzwingen, auf die Ihre Teams noch nicht vorbereitet sind, können Sie Ihre aktuelle Struts-Bereitstellung weiter betreiben und erhalten dabei fortlaufend Sicherheitspatches über Ihre bestehende Maven- oder Gradle-Build-Toolchain.

TuxCare ist seit über einem Jahrzehnt in diesem Bereich tätig und stellt Sicherheitspatches für Betriebssysteme, Laufzeitumgebungen, Bibliotheken und Anwendungsframeworks bereit, deren Lebenszyklus abgelaufen ist. Das Unternehmen hat im gesamten Open-Source-Ökosystem bereits über 220.000 Sicherheitspatches bereitgestellt. Wenn TuxCare sagt, dass es weiß, wie man EOL-Software im Unternehmensmaßstab sicher hält, ist das keine Marketingfloskel. Das Unternehmen hat dies in großem Maßstab und konsequent umgesetzt.

Vollständige Abdeckung des Abhängigkeitsbaums: TuxCares ELS für Struts deckt das Framework sowie dessen direkte und transitive Abhängigkeiten ab, darunter OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2 und andere Bibliotheken, die ihre eigenen CVE-Risiken bergen – und das ohne zusätzliche Kosten. Schwachstellenscanner machen keinen Halt vor Paketgrenzen, und das gilt auch für die Abdeckung von TuxCare. Die gesamte Patch-Oberfläche wird abgedeckt, nicht nur das Struts-Artefakt der obersten Ebene.

Optimierter, automatisierter Patch-Prozess: TuxCare überwacht das NVD, Sicherheitshinweise von Anbietern, Apaches eigene CVE-Liste und GitHub-Sicherheitsfeeds – also alle Kanäle, über die Schwachstellen in Struts und seinen Abhängigkeiten bekannt gegeben werden. Wenn eine CVE identifiziert wird, übernehmen algorithmische Tools und KI-gestützte Automatisierung das Backporting von Sicherheitskorrekturen auf die unterstützte Version, und Sicherheitsexperten validieren jeden Patch, bevor er ausgeliefert wird. Jedes Update durchläuft Integritäts-, Funktions- und Regressionstests, bevor es Ihre Repositorys erreicht. Ausführliche technische Details finden Sie dem technischen Whitepaper von TuxCare zum Open-Source-Patching-Prozess.

Nahtlose Integration: Unabhängig davon, ob Sie Struts derzeit über Maven oder Gradle nutzen, können Sie Ihre Update-Quelle mit minimalen Änderungen an Ihrem bestehenden Workflow auf das sichere Repository von TuxCare umstellen. Es sind keine Änderungen an Ihrer Build-Pipeline, Ihren CI/CD-Workflows oder der Arbeitsweise Ihrer Teams erforderlich. Sicherheitsupdates werden automatisch über Ihre bestehende Toolchain bereitgestellt.

Schnelle Reaktion mit SLA-Garantie: Wenn neue Schwachstellen in EOL-Versionen von Apache Struts bekannt werden – sei es im Framework selbst oder in dessen Abhängigkeitsbaum –, liefert TuxCare Patches innerhalb eines garantierten Zeitrahmens, der durch Service-Level-Vereinbarungen abgesichert ist. Sicherheitslücken mit hohem und kritischem Schweregrad (CVSS 7+) werden innerhalb von 14 Tagen nach der öffentlichen Bekanntgabe behoben. Sie müssen nicht auf einen Community-Backport warten, der für eine EOL-Version von Struts niemals erscheinen wird. Sie erhalten produktionsreife Patches nach einem Zeitplan, auf den Sie sich verlassen können, sowie rund um die Uhr Experten-Support für die Einstufung von Sicherheitslücken und die Fehlerbehebung.

Kosteneffiziente Sicherheitskontinuität: Die Kosten für TuxCare ELS betragen nur einen Bruchteil dessen, was eine Notfall-Framework-Migration kostet, wenn diese aufgrund einer Compliance-Frist in Bezug auf Entwicklungszeit, Betriebsrisiken, Incident Response und verzögerte Roadmap-Arbeiten erzwungen wird. Vorhersehbare Sicherheitsabdeckung, ein kontrollierter Migrationszeitplan und keine Compliance-Notfälle machen den erweiterten Support zur richtigen Unternehmensstrategie.

Um genau zu sehen, welche Sicherheitslücken in den nicht mehr unterstützten Struts-Versionen behoben wurden, unterhält TuxCare einen Live-CVE-Tracker für Struts.

Lassen Sie nicht zu, dass das Ende der Lebensdauer von Apache Struts Ihre Webanwendungen gefährdet

Das Ende der Lebensdauer von Apache Struts bedeutet nicht, dass Ihre Anwendung sofort gefährdet ist, und es bedeutet auch nicht, dass Sie eine Notfallmigration durchführen müssen, auf die Ihre Teams nicht vorbereitet sind. Doch dieser EOL-Status von Apache Struts bedeutet, dass der Sicherheitsschutz, auf den sich Ihre Webanwendungsinfrastruktur stützte, nicht mehr gegeben ist, und der Hackerangriff auf Equifax hat deutlich gezeigt, welche Folgen eine ungeschützte Struts-Exposition in großem Maßstab haben kann.

Die Organisationen, die damit gut umgehen, sind diejenigen, die diesen EOL-Status als ein zu bewältigendes Sicherheitsproblem betrachten und nicht als eine Frist, auf die unter Druck reagiert werden muss. Sie können eine wohlüberlegte Migration auf Struts 6.x oder 7.x planen, wenn dies tatsächlich den Kapazitäten Ihres Teams entspricht – einschließlich der zusätzlichen Zeit, die benötigt wird, um Action-Klassen korrekt zu annotieren, OGNL-Ausdrucksmuster in Ihrer gesamten Template-Ebene zu aktualisieren und das Verhalten über Ihren gesamten Endpunkt-Satz hinweg zu validieren. Sie können prüfen, ob eine umfassendere Framework-Migration einem echten architektonischen Zweck dient. Oder Sie können TuxCare ELS nutzen, um vollständige Sicherheit und Compliance zu gewährleisten, während Sie diese Entscheidungen nach Ihrem eigenen Zeitplan treffen – und nicht nach dem eines Compliance-Prüfers.

Erweiterter Support ist keine Notlösung. Er ist die Option, die die Sicherheit Ihrer Struts-Anwendungen gewährleistet, Ihre Compliance-Situation aufrechterhält und es Ihren Entwicklerteams ermöglicht, sich auf die Entwicklung zu konzentrieren – statt auf die Behebung von Notfällen. Wenn das Ende der Lebensdauer von Apache Struts derzeit auf Ihrem Sicherheitsradar steht, besuchen Sie den Endless Lifecycle Support für Open-Source-Software von TuxCare , um zu erfahren, wie erweiterter Support Ihre Webanwendungsinfrastruktur so lange schützen kann, wie Sie es benötigen.