Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- „Nicht mehr unterstütztes Werkzeug“ bedeutet, dass keine Korrekturen mehr vom Upstream-Entwickler bereitgestellt werden, sodass betroffene Anwendungen bei Auftreten neuer Sicherheitslücken keinen Upstream-Patch erhalten.
- Überstürzte Upgrades können zu Produktionsfehlern, Abhängigkeitsproblemen, technischer Verschuldung und ungeplanten Kosten führen.
- TuxCare ELS sorgt dafür, dass ältere Werkzeug-Versionen auf dem neuesten Stand bleiben, während Sie den richtigen Zeitpunkt für ein Upgrade planen.
Sie haben auf Werkzeug eine solide Basis geschaffen. Das Routing funktioniert. Die Bearbeitung der Anfragen ist sauber. Die WSGI-Schicht tut genau das, was sie tun soll. Dann schlägt Ihr Abhängigkeitsscanner Alarm, oder jemand aus dem Sicherheitsteam fragt, welche Werkzeug-Version im Container läuft, und die Antwort lautet 2.2.3 – eine Version, die aus dem Jahr 2023 stammt.
Und was nun?
Das kommt häufiger vor, als es den Anschein hat – vor allem, weil sich fast niemand bewusst für eine bestimmte Werkzeug-Version entscheidet. Flask zieht sie ein, pip löst sie auf, und sie bleibt still und leise dort, bis etwas die Frage aufwirft. Schauen wir uns also einmal an, was tatsächlich passiert, wenn ein Werkzeug-Zweig keine Updates mehr erhält, und was man realistisch gesehen dagegen tun kann.
So funktionieren Werkzeug-Releases tatsächlich
Werkzeug wird vom Pallets-Projekt zusammen mit Flask, Jinja und Click gepflegt. Pallets veröffentlicht keinen Langzeit-Support-Kalender mit festen Wartungszeiträumen für jeden Zweig, wie es bei Python oder Node.js der Fall ist. Es gibt kein angekündigtes End-of-Life-Datum für Werkzeug 2.2, das irgendwo in einer Roadmap vermerkt wäre. Der Support muss aus den tatsächlich von den Betreuern veröffentlichten Versionen abgeleitet werden.
Der allgemeine Ablauf ist leicht nachzuvollziehen. Werkzeug 2.x hat Python 2 und 3.5 aufgegeben und die Codebasis auf Typangaben umgestellt. Werkzeug 3.x setzte diesen Weg fort, entfernte veraltete APIs und erhöhte die Mindestanforderungen an Python; mittlerweile ist Python 3.9 oder neuer erforderlich. Die derzeit aktive Version ist 3.1.x, wobei 3.1.8, veröffentlicht am 2. April 2026, die aktuellste stabile Version (Stand: August 2026) ist.
Hier liegt der Haken. Das intuitive Modell, wonach eine neue Hauptversion den vorherigen Zweig sofort außer Kraft setzt, ist nicht zuverlässig. Werkzeug 3.0.0 wurde Ende September 2023 veröffentlicht, und am 8. November 2023 erschien dennoch die Version 2.3.8 mit einem Sicherheitspatch. Backports kommen durchaus vor. Sie sind lediglich unvorhersehbar und werden nicht zugesichert.
Was die Versionshistorie jedoch deutlich macht, ist, worauf der Fokus liegt. Die 3.0-Reihe erhielt ihre letzte Version, 3.0.6, Ende Oktober 2024, wenige Tage vor der Veröffentlichung von 3.1.0, und seitdem gab es keine weiteren Veröffentlichungen mehr. Die 2.x-Reihe endete mit 2.3.8. In der Praxis ist also 3.1.x der einzige Zweig, für den noch Releases erscheinen, während die früheren Zweige inaktiv erscheinen, ohne jemals offiziell für tot erklärt worden zu sein. Das ist wohl schlimmer als ein veröffentlichtes EOL-Datum, denn man kann einem Prüfer keinen Kalender vorlegen und man kann nicht auf der Grundlage eines Wartungsfensters planen, das nie angeboten wurde.
Wenn Sie sich nicht sicher sind, wo Sie stehen, pip show werkzeug beantwortet die Frage in etwa zwei Sekunden. Wenn die Versionsnummer nicht mit 3.1 beginnt, sollten Sie nicht damit rechnen, dass der Upstream-Entwickler einen Fix für die nächste bekannt gewordene Sicherheitslücke bereitstellt.
Was ein nicht unterstütztes Werkzeug in der Produktion tatsächlich bedeutet
Der Support endet. Die Anwendung läuft weiter. Es treten keine sichtbaren Störungen auf. Warum spielt das also eine Rolle?
Denn nur weil die Veröffentlichung von Patches eingestellt wird, verschwinden die Sicherheitslücken noch lange nicht. Das Risiko besteht nicht darin, dass Angreifer eine Liste der „Werkzeug-Nachzügler“ führen. Es ist viel einfacher und langweiliger als das. Eine Sicherheitslücke wird bekannt, sie betrifft Ihren Zweig, und es gibt keinen Behebungsweg seitens des Upstreams. Da Werkzeug unterhalb von Flask angesiedelt ist, wird diese Lücke an alles weitervererbt, was Sie darauf aufgebaut haben.
Zwei Beispiele veranschaulichen das Problem sehr gut.
CVE-2024-34069 ist eine Schwachstelle im interaktiven Debugger von Werkzeug, die sowohl vom NVD als auch im Pallets-Hinweis mit 7,5 („High“) bewertet wurde. Die Ausnutzungsmöglichkeiten sind begrenzt. Der Angreifer muss einen Entwickler dazu bringen, mit einer von ihm kontrollierten Domain und Subdomain zu interagieren, ihn dazu veranlassen, die Debugger-PIN einzugeben, und eine URL in der Anwendung erraten, die den Debugger auslöst. Wenn alle drei Bedingungen erfüllt sind, führt dies zur Ausführung von Code auf dem Rechner des Entwicklers, selbst wenn der Debugger an „localhost“ gebunden ist. Die Schwachstelle wurde in Version 3.0.3 behoben.
Genau dieser Fix ist der springende Punkt. Werkzeug 3.0.3 ist die erste Version, die ihn enthält, und jede spätere 3.x-Version übernimmt ihn. Es gibt jedoch keine 2.x-Version mit diesem Patch, auch nicht 2.3.8, die letzte 2.x-Version. Wenn Ihre Softwareumgebung auf der 2.x-Linie basiert, gibt es in diesem Zweig keine Version, auf die Sie umsteigen könnten, um dieses Problem zu beheben.
Erfahren Sie mehr über Werkzeug Security und aktuelle Sicherheitslücken.
CVE-2023-46136 ist eine Denial-of-Service-Schwachstelle im Parser für Multipart-Formulare. Wenn ein Upload mit einem CR oder LF beginnt und anschließend Megabytes ohne diese Zeichen folgen, fügt der Parser die Bytes stückweise an ein internes Bytearray an und durchsucht den wachsenden Puffer erneut nach der Grenze, wodurch die CPU überlastet wird und der Worker daran gehindert wird, andere Aufgaben zu bearbeiten. Betroffen sind die Versionen 2.3.7 und früher sowie 3.0.0; die Schwachstelle wurde in den Versionen 2.3.8 und 3.0.1 behoben. Gut zu wissen, bevor Sie in einem Ticket darüber diskutieren: Das NVD stuft die Schwachstelle mit 7,5 als „hoch“ ein, während der Pallets-Hinweis sie mit 5,7 als „mäßig“ einstuft, da sich die beiden hinsichtlich des Angriffsvektors und der erforderlichen Berechtigungen nicht einig sind. Verschiedene Scanner können je nach der von ihnen verwendeten Datenquelle unterschiedliche Schweregrade melden. Die Anfälligkeit betrifft Anwendungen mit einem Endpunkt, der tatsächlich vom Angreifer bereitgestellte „Multipart“-Daten analysiert.
In einem gepflegten Zweig stellen beide Fälle eine Versionserhöhung dar. In einem nicht unterstützten Zweig bleibt eine neu bekannt gewordene Sicherheitslücke im Upstream-Zweig ungepatcht, bis Sie entweder ein Upgrade durchführen oder einen Backport von einer anderen Quelle beziehen.
Sicherheits- und Compliance-Risiken nach Ablauf des Supports
PCI DSS v4.0.1, die aktuelle Version des Standards, schreibt gemäß Anforderung 6.3.3 vor, dass Patches für kritische Schwachstellen innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen, während andere relevante Patches gemäß dem dokumentierten, risikobasierten Zeitplan der Organisation behandelt werden. In Version 4.0 war diese Ein-Monats-Frist auch auf Probleme mit hohem Schweregrad ausgeweitet worden, während in 4.0.1 wieder die engere Formulierung verwendet wurde. Die Ausrichtung dieser Überarbeitung ist weniger wichtig als die ihr zugrunde liegende Annahme, nämlich dass ein Patch zur Installation bereitsteht.
Wenn es für Ihren Zweig keine Korrektur auf der übergeordneten Ebene gibt, sind Sie mit der Behebung nicht im Verzug. Sie befinden sich außerhalb des Modells, auf dessen Grundlage die Anforderung formuliert wurde, und das ist ein schwierigeres Gespräch, das Sie mit einem Prüfer führen müssen.
SOC 2 enthält keine Vorschrift gegen Software, deren Lebenszyklus abgelaufen ist. Seien Sie daher vorsichtig, wie Sie dies intern formulieren. Dies wirft nämlich Fragen zum Schwachstellenmanagement auf und dazu, ob Sie einen funktionierenden Behebungsplan nachweisen können. Eine nicht mehr unterstützte Abhängigkeit mit offenen Befunden und ohne verfügbaren Patch ist genau die Art von Problem, die Folgeanfragen nach sich zieht, die Bearbeitung von Sicherheitsfragebögen verlangsamt und die Risikoprüfungen für Kunden zum Zeitpunkt der Vertragsverlängerung erschwert.
Ihre Möglichkeiten, wenn der Support ausläuft
Es gibt drei Möglichkeiten, und welche davon die richtige ist, hängt weniger von der CVE ab, die bei Ihnen ausgelöst wurde, als vielmehr davon, wie groß die „Werkzeug“-Oberfläche Ihrer Anwendung tatsächlich ist.
Auf die neueste Version von Werkzeug aktualisieren
Die Standardantwort – und für viele Teams die richtige. Werkzeug 3.1.x ist ausgereift, die API ist übersichtlicher und die Typ-Annotationen sind wirklich nützlich.
Interessant wird es bei der Annahme, dass es sich hierbei um eine Änderung von nur einer Zeile handelt. Werkzeug aktualisiert sich nicht von selbst. In Flask-Releases wird in der Regel eine Mindestversion von Werkzeug angegeben, anstatt eine Obergrenze festzulegen. Dadurch kann pip eine neuere Werkzeug-Version installieren, als sie jemals mit Ihrer Flask-Version getestet wurde. Das ist kein hypothetischer Fall. In Werkzeug 3.0 wurde url_quote, das Flask 2.2.2 am Anfang von app.py, sodass die Zuordnung beim Import fehlschlägt. Werkzeug 3.1 hat dies dann entfernt werkzeug.__version__, das der Flask-2.2.4-Testclient beim Erstellen einer User-Agent-Zeichenkette immer noch ausliest, was beim ersten Ausführen der Testsuite in einem neuen Container zu einem „AttributeError“ führt. Dies wird beschrieben in Flask-Problem 5652.
Ein Upgrade von Werkzeug kann also durchaus ein Upgrade von Flask bedeuten, was wiederum eine Überprüfung aller an Flask gekoppelten Erweiterungen erfordert – und damit eine Kompatibilitätsprüfung des gesamten Abhängigkeitsbaums. Wenn Ihre Codebasis klein ist, Ihre Erweiterungsliste kurz ist und Ihre Testabdeckung solide ist, machen Sie es gleich und hören Sie hier auf zu lesen. Handelt es sich hingegen um eine ausgereifte Anwendung mit einem Jahrzehnt an angesammeltem Middleware-Bestand, sollten Sie ein angemessenes Budget einplanen.
Auf ein anderes Framework umsteigen
Manche Teams sehen eine nicht unterstützte Abhängigkeit und kommen zu dem Schluss, dass die eigentliche Lösung ganz woanders zu finden ist. Django, wenn man eine Komplettlösung will, FastAPI, wenn man ein auf Starlette basierendes asynchrones API-Framework will, Starlette selbst, wenn man das ASGI-Toolkit ohne Vorgaben will, Bottle oder Falcon, wenn man etwas Leichteres will. Insbesondere FastAPI hat derzeit großen Aufschwung, ein „Async-First“-Design und kostenlos generierte OpenAPI-Dokumentationen.
Keine dieser Alternativen ist ein direkter Ersatz für Werkzeug. Die Routenlogik, die Analyse von Anfragen, das Rendern von Vorlagen, der Middleware-Stack, die Fehlerbehandlung und die Bereitstellungskonfiguration werden alle überarbeitet. Bei einer Anwendung, in der Werkzeug eine bedeutende Rolle spielt, wird eine sorgfältig geplante und getestete Migration zu einem Projekt, das sich über mehrere Sprints oder Quartale erstreckt – und nicht zu einer einfachen Aufräumaktion. Man sollte dies tun, weil man ohnehin schon asynchrones Programmieren einsetzen wollte, und nicht, weil ein Scanner an einem Dienstag einen Fehler gemeldet hat.
Nutzen Sie den erweiterten Support und verschaffen Sie sich mehr Zeit
Die dritte Möglichkeit besteht darin, die derzeitige Version beizubehalten und weiterhin Sicherheitspatches dafür zu erhalten. Damit liegt der Zeitplan nicht mehr in den Händen desjenigen, der die nächste Sicherheitslücke meldet, sondern wieder in Ihrer eigenen Planung. Weiter unten finden Sie eine ausführliche Darstellung, wie dies funktioniert.
Die wahren Kosten einer überstürzten Aktualisierung
Stellen Sie sich ein 30-köpfiges SaaS-Team vor, das den Auftrag erhält, einen schwerwiegenden Mangel zu beheben, bevor das SOC-2-Fenster in drei Wochen endet. Das Upgrade selbst ist nicht das Schwierige. Die Folgen sind es.
Fehler, die von der Testsuite übersehen wurden, treten nun in der Produktionsumgebung auf, und der Support erhält eine ganze Reihe von Tickets zu Verhaltensweisen, die zuvor einwandfrei funktionierten. Transitive Abhängigkeiten bringen ihre eigenen Randfälle mit sich – solche, die nur unter realer Last auftreten und zu sporadischen Ausfällen führen, die sich nur schwer reproduzieren lassen und bei einer Incident-Analyse noch schwerer zu erklären sind.
Dann fangen die Abkürzungen an. Refactorings werden übersprungen, Notlösungen häufen sich an, und alle sind sich einig, das Problem später ordnungsgemäß zu beheben. Sechs Monate später ist dieses „später“ immer noch nicht eingetreten, und der Code ist in einem schlechteren Zustand als vor dem Upgrade, das ihn eigentlich aufräumen sollte.
Bei den Kosten zeigt sich dasselbe Muster: Arbeitsstunden von Auftragnehmern, die niemand eingeplant hatte, Roadmap-Verpflichtungen, die sich um ein Quartal verzögern, und leitende Ingenieure, die ihre Woche damit verbringen, die Ausgabe des Pip-Resolvers zu lesen, anstatt das zu entwickeln, was die Kunden eigentlich wollten. Nichts davon taucht in der ursprünglichen Kalkulation auf, da sich diese nur auf die Versionserhöhung bezog.
So funktioniert TuxCare ELS für Werkzeug
TuxCare beschäftigt sich seit 15 Jahren mit der Bereitstellung von Patches für Open-Source-Software, deren Support ausgelaufen ist. Dabei wurden über 420.000 Patches bereitgestellt und mehr als 14.000 Sicherheitslücken in Betriebssystemen, Laufzeitumgebungen, Bibliotheken und Anwendungen behoben. Werkzeug wird durch den ELS for Libraries-Service von TuxCare abgedeckt.
Zu den derzeit unterstützten Versionen gehören Werkzeug 1.0.1, 2.2.3 und 2.3.8; weitere Versionen sind auf Anfrage erhältlich.
Was diesen Ansatz von anderen unterscheidet
Die Abhängigkeitsfläche von Werkzeug ist ungewöhnlich klein. Die 2.x-Versionen weisen genau eine erforderliche Laufzeitabhängigkeit auf, nämlich „MarkupSafe“, und Version 1.0.1 weist überhaupt keine auf, was die Frage der Abdeckung vereinfacht. ELS umfasst Sicherheitskorrekturen für direkte und transitive Abhängigkeiten ohne zusätzliche Kosten, was wichtiger ist, als es zunächst klingt, da das Risiko eines End-of-Life bereits eine Ebene unterhalb des Pakets liegen kann, das Sie tatsächlich überwachen.
Der Patching-Prozess läuft automatisiert ab, wobei Mitarbeiter die Ergebnisse überprüfen. TuxCare verfolgt rund um die Uhr CVEs über das NVD, Herstellerhinweise und GitHub-Sicherheitshinweise, portiert Upstream-Korrekturen mithilfe algorithmischer und KI-gestützter Automatisierung mit Validierung durch Experten und unterzieht jeden Build anschließend Integritäts-, Funktions- und Regressionstests, bevor er signiert und in den ELS-Repositorys veröffentlicht wird. Wenn Sie sich eher für die technischen Details als für die Zusammenfassung interessieren, finden Sie im Artikel „Open Source Patching Process“ eine ausführliche Beschreibung.
Die Integration bleibt innerhalb von pip. Entweder verweisen Sie pip auf das TuxCare-Repository mit index-url, oder du behältst das öffentliche PyPI bei und fügst es als extra-index-url, wobei die gepatchte Version direkt verlinkt wird. Gepatchte Versionen tragen eine Versionsangabe wie werkzeug==1.0.1.post1+tuxcare, sodass die gepatchte Version überall dort identifizierbar bleibt, wo Ihre aufgelösten Versionen erfasst sind. Es handelt sich um eine Änderung der Repository-Konfiguration unter Verwendung von Anmeldedaten und nicht um eine Neuerstellung Ihrer Bereitstellungspipeline.
Die Bereitstellung erfolgt nicht nach dem „Best-Effort“-Prinzip, sondern auf SLA-Basis. Die Pakete sind signiert und werden aus von TuxCare gehosteten Repositories bereitgestellt. Bei Problemen, die menschliches Eingreifen erfordern, steht rund um die Uhr Unterstützung für die Triage und Patch-Anfragen zur Verfügung. Für Audit-Zwecke enthält jede gepatchte Version SBOM-Daten sowie einen VEX-Feed, sodass VEX-kompatible Tools bereits behobene Befunde von denen unterscheiden können, die noch Maßnahmen erfordern.
Was die Kosten angeht, so lässt sich ehrlich gesagt nicht behaupten, dass eine verlängerte Unterstützung günstig ist. Vielmehr werden dadurch die Migrationsarbeiten, die Kompatibilitätstests und die Regressionstests aus dem Notfallzeitraum in einen geplanten Zeitraum verlagert, in dem die Kosten so ausfallen, wie sie ausfallen sollten.
Wie man anfängt
Wenn Sie wissen möchten, wie der Support für Ihre Version konkret aussieht, finden Sie im TuxCare CVE-Tracker eine Auflistung der behobenen Werkzeug-Sicherheitslücken, und in der ELS-Dokumentation werden die unterstützten Versionen sowie die Installationsoptionen ausführlich beschrieben.
Informationen zu den unterstützten Versionen, den Preisen und dazu, wie die Implementierung in der Praxis abläuft, finden Sie zunächst auf der Seite „Endless Lifecycle Support für Werkzeug “.
Lassen Sie nicht zu, dass ein nicht mehr unterstütztes Werkzeug Ihre Systeme gefährdet
Da Werkzeug als WSGI-Schicht unter Flask fungiert, werden Entscheidungen bezüglich seines Lebenszyklus nur selten separat getroffen. Wenn eine nicht mehr unterstützte Version einen Fehler im Code enthält, den Ihre Anwendung tatsächlich nutzt, weist auch Ihre Anwendung diesen Fehler auf – und Sie erfahren davon eher durch einen Scanner oder einen Fragebogen als durch eine Versionsnotiz.
Das ist kein Grund zur Panik. Sie können ein Werkzeug-Upgrade für ein Quartal planen, in dem Sie genügend Spielraum haben, um es gründlich durchzuführen. Sie können zu einem anderen Framework wechseln, wenn es einen echten technischen Grund gibt, der über den Scanner hinausgeht. Oder Sie können weiterhin Patches für die bereits verwendete Version erhalten, während Sie sich entscheiden. So können Sie Ihre Sicherheitslage aufrechterhalten und erhalten konkrete Nachweise für Abhilfemaßnahmen bei Compliance-Prüfungen, ohne Ihre Roadmap demjenigen preiszugeben, der die nächste CVE einreicht.
Die Teams, die diese Phase gut meistern, sind selten diejenigen mit den größten Budgets. Es sind diejenigen, die herausgefunden haben, welche Version sie tatsächlich nutzten, verstanden haben, was noch gepflegt wurde und was nicht, und die bewusste Entscheidungen getroffen haben, anstatt nur zu reagieren.
Sollte Sie eines dieser Themen derzeit beschäftigen, zeigt „Endless Lifecycle Support for Open-Source Software“, wie der erweiterte Support Komponenten, deren Lebenszyklus abgelaufen ist, im gesamten restlichen Stack so lange abdeckt, wie Sie diese benötigen.
