Werkzeug Security: CVEs, Risiken und bewährte Verfahren im Jahr 2026

Wichtigste Erkenntnisse

• Werkzeug bietet Sicherheitshilfen für die Passwort-Hash-Erzeugung, die Bereinigung von Dateinamen und die sichere Verknüpfung von Pfaden sowie einen PIN-geschützten Debugger.
• Die CVE-Vorgeschichte konzentriert sich auf den Debugger, die Auswertung mehrteiliger Formulare und die Funktion „safe_join()“- sowie die Auswertung von Cookies.
• Der 3.1.x-Zweig ist der einzige, für den Sicherheitskorrekturen vom Upstream garantiert werden, und ab Version 3.1.6 sind alle hier behandelten CVEs behoben.
• ELS von TuxCare portiert Sicherheitskorrekturen auf Werkzeug 1.0.1, 2.2.3 und 2.3.8 und stellt sie über pip bereit.

Ein Abhängigkeitsscanner markiert werkzeug als anfällig, und niemand im Team kann sich daran erinnern, es installiert zu haben, da Flask es selbstständig eingebunden hat. Werkzeug ist das Toolkit, das Flask zugrunde liegt und hinter jeder Route die Abwicklung von Anfragen und Antworten übernimmt. Es verfügt über eine eigene CVE-Historie und eigene Standardeinstellungen, unabhängig von den Ergänzungen, die Flask darüberlegt.

In diesem Artikel erfahren Sie, wovor Werkzeug schützt, wo sich die verifizierten CVEs befinden, wie Sie Ihre eigene Anfälligkeit überprüfen können und wie Sie eine Werkzeug-Anwendung in der Produktion absichern können.

Was „Werkzeug“ ist und wie es zu „Flask“ passt

„Werkzeug“ ist eine WSGI-Hilfsbibliothek, die vom Pallets-Projekt, derselben Gruppe, die auch hinter Flask, Jinja und Click steht. Sie übernimmt die Low-Level-Mechanismen von HTTP-Anfragen und -Antworten: das Parsen von Headern, Cookies und Multipart-Formularinhalten, das Abgleichen von URL-Routen sowie die Bereitstellung eines Debuggers für die lokale Entwicklung. 

Flask baut auf Werkzeug auf, anstatt es zu ersetzen. Flask stellt Routing-Dekoratoren, Vorlagen und eine Anwendungsstruktur bereit, doch seine Request- und Response-Objekte sind Unterklassen derjenigen von Werkzeug, und ein Großteil der zugrunde liegenden WSGI-Mechanismen stammt ebenfalls von Werkzeug. Bei der Installation von Flask wird Werkzeug als Abhängigkeit mitinstalliert, weshalb die meisten Teams es nutzen, ohne es bewusst in eine Requirements-Datei aufzunehmen.

In der Produktion analysiert ein WSGI-Server wie Gunicorn die rohen HTTP-Daten und übergibt Flask eine WSGI-Umgebung. Von dort aus ist eine Schwachstelle in der Anfragebearbeitung von Werkzeug für jeden erreichbar, der eine Anfrage an Ihre Anwendung senden kann. Das Routing erfolgt, bevor Ihre View-Funktion ausgeführt wird, und die meisten anderen Anfragedaten werden erst analysiert, wenn sie gelesen werden. Die Formularauswertung beginnt beispielsweise in dem Moment, in dem der Code request.form oder request.filesberührt.

Die nativen Sicherheitsfunktionen von Werkzeug

Werkzeug stellt verschiedene Sicherheitshilfen und Schutzmechanismen bereit, die eine Flask-Anwendung nutzen kann, ohne eine weitere Abhängigkeit hinzuzufügen. Die meisten davon sind nur dann von Nutzen, wenn die Anwendung sie tatsächlich aufruft.

werkzeug.security bietet generate_password_hash() und check_password_hash(), die Passwörter mithilfe eines konfigurierbaren Algorithmus mit einem Salt versehen und hashen, anstatt dies dem Anwendungscode zu überlassen. secure_filename() entfernt Pfadtrennzeichen und andere unsichere Zeichen aus einem vom Benutzer angegebenen Dateinamen, sodass der zurückgegebene Name wesentlich sicherer in einem von der Anwendung kontrollierten Verzeichnis gespeichert werden kann. Die Funktion prüft jedoch nur den Namen. Sie überprüft nicht, was bereits auf der Festplatte vorhanden ist, und kann eine leere Zeichenkette zurückgeben, sodass der Upload-Code weiterhin beide Fälle behandeln muss.

safe_join() gibt es aus demselben Grund auf Verzeichnisebene. Es dient dazu, ein vertrauenswürdiges Basisverzeichnis mit einem vom Benutzer angegebenen Pfad zu kombinieren und alles zurückzuweisen, was über dieses Basisverzeichnis hinausgeht – genau das tut send_from_directory() nutzt, um Dateien sicher bereitzustellen. Der interaktive Debugger verlangt die Eingabe einer PIN, bevor er eine aktive Python-Konsole im Browser anzeigt. Dies soll verhindern, dass ein Fremder, der zufällig auf einen Debug-Endpunkt stößt, Code ausführen kann.

Keine dieser Schutzmaßnahmen ist für sich genommen vollständig. Jede einzelne mindert ein bestimmtes Risiko, und zwei davon, „safe_join()“ und die Debugger-PIN, wiesen dokumentierte Schwachstellen genau bei dem Risiko auf, das sie eigentlich abdecken sollten. Daher stammt ein Großteil der unten aufgeführten CVE-Einträge.

Werkzeug – Sicherheitsrisiken und CVEs

Stand September 2026 umfasst der öffentliche CVE-Eintrag von Werkzeug neun seit 2023 gemeldete Schwachstellen. Einige der neueren CVEs weisen sowohl einen CVSS v3.1- als auch einen CVSS v4.0-Wert auf, wobei die Tracker nicht immer beide Werte anzeigen. Welcher Wert höher ausfällt, hängt von der jeweiligen CVE ab. Die safe_join() erzielt unter v4.0 eine höhere Punktzahl, während CVE-2024-49767 unter v3.1 besser abschneidet. Wenn nur einer der Werte angezeigt wird, kann dies dazu führen, dass ein Befund mehr oder weniger dringend erscheint, obwohl der zugrunde liegende Fehler identisch ist.

Sicherheitslücke im Debugger, die die Ausführung von Remote-Code ermöglicht

Das Debugger-Problem CVE-2024-34069 und die Mechanismen zur Ausnutzung von CSRF werden ausführlich in der Analyse von TuxCare zu was das Ende des Lebenszyklus von Werkzeug für Python-Anwendungen bedeutet. Kurz gesagt stellt ein Debugger ein Risiko für die Codeausführung dar, selbst wenn er an den localhost gebunden ist und hinter einer PIN geschützt ist. Für den Angriff sind eine vom Angreifer kontrollierte Domain und Subdomain, ein Entwickler, der mit diesen interagiert und die Debugger-PIN eingibt, sowie eine erratene URL erforderlich, die den Debugger auslöst. Gelingt dies, gelangt der Angreifer an einen ausschließlich auf dem localhost laufenden Debugger und führt Code auf dem Rechner des Entwicklers aus. Das Problem wurde im Upstream in Version 3.0.3 behoben, und keine Upstream-Version der 2.x-Reihe enthält diesen Fix, da die Upstream-Unterstützung für die 2.x-Reihe mit Version 2.3.8 endete. Für Teams, die auf die 2.x-Reihe festgelegt sind, deckt der ELS von TuxCare dies mit einem zurückportierten Fix für Werkzeug 2.3.8 ab, und der CVE-Tracker listet den aktuellen Schutzumfang für jede unterstützte Version auf.

Denial-of-Service-Angriff durch mehrteiliges Parsing

Aus demselben Codepfad ergeben sich drei separate CVEs. CVE-2023-25577 ermöglichte es, dass eine Anfrage eine unbegrenzte Anzahl von Multipart-Teilen enthielt, sodass der Aufwand für die Analyse mit der vom Angreifer kontrollierten Anzahl der Teile skalierte, bis die CPU-Leistung oder der Arbeitsspeicher erschöpft waren. Dies wurde in Version 2.2.3 behoben, in der auch die max_form_parts eingeführt wurde. 

CVE-2023-46136 griff denselben Parser aus einem anderen Blickwinkel an, und zwar mit einem einzigen speziell gestalteten Teil. Eine Datei, die mit einem CR- oder LF-Zeichen beginnt und auf die Megabytes an Daten folgen, die keine weiteren CR- oder LF-Zeichen enthalten, zwingt den Parser dazu, einen immer größer werdenden Puffer immer wieder nach der Grenze abzusuchen. Das NVD stuft sie mit 7,5 („Hoch“) ein, während die GitHub-Sicherheitsempfehlung eine Einstufung von 5,7 („Mäßig“) vorsieht. Einige Tracker zeigen eine dritte Zahl an, nämlich 8,0 (hoch), die sich auf den CNA-Score im offiziellen CVE-Eintrag bezieht und nicht auf den aktuellen GitHub-Hinweis. Die vollständige Aufschlüsselung dieser Abweichung findet sich im Artikel zum Ende der Lebensdauer von Werkzeug.

CVE-2024-49767 schloss eine andere Sicherheitslücke im selben Parser. Ein speziell gestalteter Formularinhalt konnte max_form_memory_size vollständig umgehen, sodass die von einer Anwendung festgelegte Speichergrenze nie tatsächlich zum Tragen kam. Das NVD stuft diese Schwachstelle mit 7,5 als „Hoch“ (CVSS v3.1) ein, während der GitHub-Hinweis sie mit 6,9 als „Mäßig“ (CVSS v4.0) bewertet.

Eine Parser-Begrenzung ist nur dann hilfreich, wenn sie früh genug durchgesetzt wird, um die Nutzung von Speicher durch Angreifer zu verhindern, und die richtige Begrenzung hängt von der jeweiligen Angriffsart ab. max_form_parts begrenzt Fluten winziger Teile, wie sie beispielsweise hinter CVE-2023-25577 stehen. max_content_length und eine Begrenzung der Body-Größe am Reverse-Proxy begrenzen die Gesamtgröße der Anfrage, und keine dieser Maßnahmen hängt davon ab, dass der Multipart-Parser das Problem intern erkennt.

Windows-Pfadfehler in „safe_join“

safe_join() wurde in etwa sechzehn Monaten viermal gepatcht; jede Korrektur betraf Windows und bezog sich darauf, wie die Funktion entscheidet, ob ein Pfad sicher ist. 

CVE-2024-49766 ist die älteste der vier Schwachstellen. Bei Python-Versionen vor 3.11, die unter Windows ausgeführt werden, erkennt os.path.isabs() UNC-Pfade wie //server/share nicht als absolut, und „safe_join()“ stützt sich auf diese Überprüfung, sodass ein UNC-Pfad durchrutschen könnte. Dies wurde in Version 3.0.6 behoben.

Die anderen drei betreffen von Windows reservierte Gerätenamen wie CON, AUX und NUL, die Windows in jedem Verzeichnis als vorhanden und lesbar behandelt, unabhängig davon, was das Verzeichnis tatsächlich enthält. CVE-2025-66221 ergab, dass safe_join() diese Namen ohne Weiteres akzeptierte; dies wurde in Version 3.1.4 behoben. CVE-2026-21860 stellte fest, dass der erste Fix zusammengesetzte Dateiendungen wie CON.txt.html, Namen mit abschließenden Leerzeichen sowie einige weitere spezielle Namen, was mit Version 3.1.5 behoben wurde. Anschließend zeigte CVE-2026-27199, dass ein mehrteiliger Pfad wie example/NUL immer noch durchgelassen wurde, was mit Version 3.1.6 behoben wurde.

In jedem dieser drei Fälle mit Gerätenamen öffnet `send_from_directory()` das Gerät erfolgreich und bleibt dann beim Lesevorgang auf unbestimmte Zeit hängen, wodurch pro Anfrage ein Worker gebunden wird, bis dem Prozess keine Worker mehr zur Verfügung stehen, um den tatsächlichen Datenverkehr zu bedienen.

Sicherheitslücke beim Auswerten von Cookies 

CVE-2023-23934 ist der unauffälligste Eintrag auf dieser Liste. NVD stuft ihn mit 3,5 („Low“) ein, und GitHub, die CNA, die die CVE-Nummer vergeben hat, stuft ihn mit 2,6 („Low“) ein. Einige Browser akzeptieren ein Cookie in der Form von =Wert ohne Namen, und Werkzeug-Versionen vor 2.2.3 haben ein Cookie wie =__Host-test=bad als legitimes __Host-test Cookie. 

Eine böswillige oder kompromittierte Subdomain könnte also dieses fehlerhafte Cookie platzieren und dafür sorgen, dass Werkzeug einen vom Angreifer kontrollierten Wert unter dem geschützten __Host-test auslesen, was den gesamten Sinn des __Host- -Präfix zunichte. Das Problem wurde in Version 2.2.3 behoben.

Beide Werte sind niedrig, da der Angriff sowohl einen anfälligen Browser als auch eine bösartige oder kompromittierte benachbarte Subdomain erfordert. Die Folgen sehen anders aus, wenn das gefälschte Cookie ein Session-Token oder ein CSRF-Token enthält. CVSS bewertet den Mechanismus und hat keine Kenntnis davon, welche Daten eine bestimmte Anwendung in diesem Cookie speichert.

So überprüfen Sie Ihre Werkzeug-Version auf Sicherheitslücken

Die Überprüfung der Exposition dauert etwa zwei Minuten pro Dienst. Das Ziel besteht darin, eine Frage zu beantworten: Läuft die Werkzeug-Version tatsächlich in der Produktion auf einem Zweig, für den weiterhin Fehlerbehebungen bereitgestellt werden? 

Gehen Sie von dem aus, was tatsächlich installiert ist, und nicht von dem, was in einer Anforderungsdatei steht.

pip show Werkzeug

Führen Sie dies innerhalb des Containers oder der virtuellen Umgebung aus, die den Datenverkehr tatsächlich bedient. Alle Versionen älter als 3.1 liegen außerhalb des einzigen Zweigs, für den Sicherheitskorrekturen aus dem Upstream garantiert sind. Pallets kann auf Anfrage eine Korrektur auf den vorherigen Feature-Zweig zurückportieren, dies wird jedoch nicht zugesichert. Eine 3.1.x-Version unterhalb von 3.1.6 befindet sich zwar im richtigen Zweig, es fehlt jedoch noch mindestens ein Fix; die aktuelle Version zum Zeitpunkt der Erstellung dieses Artikels ist 3.1.8. In jedem Fall zeigen die Spalten „Betroffene Versionen“ und „Behoben in“ in der obigen Tabelle an, ob die jeweilige CVE zutrifft und welche Version den entsprechenden Upstream-Fix enthält, sowie die nur unter Windows verfügbare Funktion „safe_join()“-Zeilen sind nur auf Windows-Hosts von Bedeutung.

Anhand der Versionsnummern allein lässt sich nicht feststellen, welche CVEs für eine bestimmte Python-Version und ein bestimmtes Betriebssystem gelten. Führen Sie daher ein Audit-Tool in genau dieser Umgebung aus.

pip install pip-audit

pip-audit

Ohne Argumente, pip-audit überprüft die in der aktiven Umgebung installierten Pakete. Soll stattdessen eine Requirements-Datei überprüft werden, übernimmt das übernimmt diese Aufgabe. pip-audit wird von der Python Packaging Authority gepflegt und bezieht standardmäßig Schwachstellendaten aus PyPI, wobei OSV als alternative Quelle über -s osv. Einige Teams setzen zusätzlich einen zweiten Scanner wie beispielsweise Safety ein, um eine weitere Perspektive auf die Sicherheitshinweise zu erhalten.

Durch die Aktualisierung des Pakets auf der Festplatte wird der Werkzeug-Code, den ein laufender Worker bereits importiert hat, nicht ersetzt. Lang laufende Gunicorn- oder uWSGI-Worker behalten den alten Code so lange geladen, bis sie neu gestartet werden. Starten Sie die Worker daher nach jeder Änderung an Werkzeug neu und vergewissern Sie sich, dass die neue Version tatsächlich geladen und nicht nur installiert wurde. 

Speziell zu Sicherheitsmeldungen bei Werkzeug: listet der CVE-Tracker von TuxCare listet ELS-gepatchte Sicherheitslücken auf, sobald diese in älteren Versionen bestätigt werden, für die es keine Upstream-Korrekturen mehr gibt.

Bewährte Verfahren zur Absicherung von Werkzeug-Anwendungen

Ein Teil des Risikos bei Werkzeug ergibt sich aus der Konfiguration und nicht aus der Version, und diese Vorgehensweisen gelten für jede Version.

Beginnen Sie mit dem Debugger. Setzen Sie debug=False und aktivieren Sie den interaktiven Debugger niemals in der Produktionsumgebung, auch nicht bei einer Bindung an 127.0.0.1gebunden ist, da CVE-2024-34069 gezeigt hat, dass „localhost“ nicht die sichere Grenze ist, als die es erscheint. Führen Sie das Programm hinter einem WSGI-Server für die Produktion aus, wie z. B. Gunicorn, uWSGI oder Waitress, da run_simple() und flask run sind Entwicklungstools, die niemals für den Produktionsverkehr gedacht waren.

Legen Sie als Nächstes bewusst Anforderungslimits fest. max_content_length, max_form_memory_sizeund max_form_parts sollten den tatsächlichen Anforderungen der Anwendung entsprechen, und die Größe des Body sollte auch am Reverse-Proxy begrenzt werden, damit übergroße oder zu komplexe Multipart-Anfragen abgewehrt werden, bevor sie nennenswerte Speicher- oder CPU-Ressourcen beanspruchen können. Explizite Werte sind vor allem in Versionen vor 3.1 von Bedeutung, in denen max_form_memory_size standardmäßig auf „unbegrenzt“ gesetzt war. Werkzeug 3.1 hat diesen Standardwert auf 500 kB geändert. 

Statische Dateien sollten nach Möglichkeit über einen dedizierten Webserver wie nginx bereitgestellt werden, wodurch send_from_directory() und safe_join() vollständig aus diesem Anforderungspfad herausgehalten werden. Führen Sie den Anwendungsprozess außerdem als Nicht-Root-Benutzer aus, damit ein Pfadfehler, der doch einmal durchkommt, weniger Zugriffsmöglichkeiten hat.

Die Konfiguration schließt Sicherheitslücken, die durch ein Versions-Upgrade allein nicht behoben werden, und umgekehrt gilt das Gleiche. Keine dieser Einstellungen ersetzt die Verwendung einer aktuellen 3.1.x-Version, und alle in der obigen Tabelle aufgeführten CVEs sind in Version 3.1.6 und höher behoben.

Wie TuxCare ELS die Sicherheit von Werkzeug auch nach Ablauf der Lebensdauer gewährleistet

Ein Upgrade ist nicht immer innerhalb eines bestimmten Zeitrahmens möglich. Eine vom Anbieter bereitgestellte Version, eine zertifizierte Bereitstellung oder eine Python-Laufzeitumgebung, für deren Umstellung niemand Mittel eingeplant hat – all dies kann dazu führen, dass eine Anwendung noch lange an eine alte Werkzeug-Version gebunden bleibt, nachdem die in dieser Tabelle aufgeführten CVEs bereits auf sie zutreffen.

Der unbefristete Lebenszyklus-Support von TuxCare für Werkzeug bietet weiterhin Sicherheitsupdates für die Versionen 1.0.1, 2.2.3 und 2.3.8 an, die als signierte Pakete über pip bereitgestellt werden. Teams können bei der bereits verwendeten Version bleiben, während sie weiterhin Sicherheitsupdates erhalten. So führt eine neue CVE nicht automatisch zu einer Notfallmigration, und die eigentliche Migration kann nach eigenem Zeitplan erfolgen.

Häufig gestellte Fragen zur Werkzeug-Sicherheit

Wie kann ich überprüfen, ob meine Werkzeug-Version bekannte Sicherheitslücken aufweist?

Führen Sie pip show werkzeug in der bereitgestellten Umgebung aus, um die installierte Version zu überprüfen, und führen Sie anschließend pip-audit in derselben Umgebung aus, um die Pakete anhand bekannter Sicherheitshinweise zu überprüfen. Für die hier behandelten CVEs ist 3.1.6 die erste Upstream-Version, die alle Korrekturen enthält, obwohl 3.1.8 zum Zeitpunkt der Erstellung dieses Artikels die aktuelle Version und somit die bessere Wahl ist.

Werden durch ein Upgrade von Flask auch die CVEs von Werkzeug behoben?

Nicht unbedingt. Flask legt eine Mindestversion von Werkzeug fest und keine Obergrenze, und „pip install –upgrade flask“ lässt ein bereits installiertes Werkzeug unberührt, solange es diese Mindestanforderung noch erfüllt. Ein Upgrade von Flask lohnt sich, aber nur durch direkte Überprüfung der installierten Werkzeug-Version lässt sich dies mit Sicherheit feststellen.

Wie lässt sich Werkzeug in der Produktion am sichersten einsetzen?

Führen Sie es hinter einem dedizierten WSGI-Server wie Gunicorn, uWSGI oder Waitress aus, mit debug=Falseund expliziter Angabe von max_content_length, max_form_memory_sizesowie max_form_parts sowie statische Dateien, die von einem separaten Webserver bereitgestellt werden, anstatt send_from_directory()bereitgestellt werden.

Warum weisen manche CVEs von Werkzeug an verschiedenen Stellen unterschiedliche Schweregrade auf?

Mehrere kürzlich gemeldete CVEs für Werkzeug weisen sowohl einen CVSS v3.1- als auch einen CVSS v4.0-Wert auf, wobei die beiden Frameworks dieselben Details unterschiedlich gewichten. CVE-2026-27199, eine der „safe_join()“ , weist im NVD einen Wert von 5,3 nach CVSS v3.1 und im GitHub-Hinweis einen Wert von 6,3 nach CVSS v4.0 auf. Welcher Wert in einem Tracker angezeigt wird, hängt also davon ab, welche Quelle und welcher Standard standardmäßig verwendet werden. Das Verhalten der Sicherheitslücke ist in beiden Fällen identisch.

Zusammenfassung

Artikel Name

Werkzeug Security: CVEs, Risiken und bewährte Verfahren im Jahr 2026

Beschreibung

Werkzeugs CVE-Verlauf, integrierte Schutzmaßnahmen, Versionsprüfungen und Maßnahmen zur Absicherung von Flask-Anwendungen sowie ELS-Unterstützung für EOL-Versionen.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers