CVE-2026-38361: Mehrere nicht authentifizierte DoS-Schwachstellen in dash-uploader

Mehrere nicht authentifizierte Denial-of-Service-Probleme (DoS) in fohrloop/dash-uploader (Python, PyPI), einschließlich (aber nicht beschränkt auf) Absturz des Prozesses durch Speichererschöpfung (Out-of-Memory, OOM), Kürzung von Dateien auf null Byte, dauerhafte Erschöpfung des Speicherplatzes und vollständige Umgehung des dokumentierten max_file_size-Limits. Über denselben nicht bereinigten Parametersatz sind weitere Wege des Ressourcenmissbrauchs möglich.

⚠️ Es ist kein Patch verfügbar, und es wird auch nie einen geben

Das Repository wurde am 2025-07-19 archiviert und hat keinen aktiven Betreuer. Jede veröffentlichte Version (0.1.0 bis 0.7.0a2) ist betroffen und wird es auch bleiben. Das Paket verzeichnet weiterhin etwa 28.000 Downloads pro Monat.

Wer dash-uploader in der Produktion einsetzt, muss selbst eine Abhilfemaßnahme umsetzen. Die empfohlene Lösung ist die Migration auf die in Plotly Dash integrierte dcc.Upload-Komponente. Vollständige Optionen finden Sie unter Mitigation.

Beschreibung

Der HTTP-Handler von dash-uploader akzeptiert nicht authentifizierte POST-Anfragen mit angreiferkontrollierten Parametern, die ohne Begrenzungsprüfungen, Ratenlimits und Bereinigungsmechanismen in Speicherzuweisung, Dateioperationen und Verzeichniserstellung einfließen. Vier unabhängige Probleme im selben Codepfad:

1. OOM-Absturz (verifiziert)

Verifiziert auf einem System mit 7,7 GB Arbeitsspeicher: 5 gleichzeitige POST-Anfragen mit resumableTotalChunks=30000000 lösten innerhalb von 2 Sekunden den Linux-OOM-Killer aus. Das Kernel-Log bestätigt:

Out of memory: Killed process 24203 (python3) total-vm:8302276kB, anon-rss:7068012kB

Jede Anfrage weist über eine Listenkomprehension über range(1, resumableTotalChunks + 1) etwa 2,9 GB zu. Der Serverprozess wird beendet, und die Anwendung bleibt bis zu einem manuellen Neustart vollständig unverfügbar.

2. Dateikürzung (verifiziert)

Eine Datei mit 42 Byte Daten wurde durch eine einzige POST-Anfrage mit resumableTotalChunks=0 auf 0 Byte reduziert. Die Ursache ist Pythons all(), das für leere Iterablen True zurückgibt und den Upload-Handler dazu verleitet, null Chunks als abgeschlossenen Upload zu behandeln. Die vorhandene Datei wird per os.unlink() gelöscht und durch eine leere Datei ersetzt.

3. Ansammlung verwaister Uploads (verifiziert)

Es wurden 10 verwaiste temporäre Verzeichnisse mit Chunk-Dateien erstellt, die dauerhaft auf der Festplatte verbleiben. Eine codebasisweite Suche in allen Quelldateien nach cleanup, ttl, expire, garbage, purge, cron, schedule und periodic ergab null Ergebnisse. Der einzige Bereinigungsaufruf (shutil.rmtree) wird ausschließlich bei abgeschlossenen Uploads ausgeführt. Es gibt keinen Mechanismus, um Speicherplatz von unvollständigen Sitzungen zurückzugewinnen.

4. Umgehung von max_file_size (verifiziert)

Der Server akzeptierte einen 5-MB-Chunk für eine Datei, die resumableTotalSize=999999999999 (~999 GB) angab, mit HTTP 200. Der Parameter max_file_size wird nur an die React-JavaScript-Komponente übergeben. Der Server prüft weder Dateigröße noch Chunk-Größe, Content-Length oder Flask MAX_CONTENT_LENGTH. Ein Entwickler, der max_file_size=10 setzt, hat keinen serverseitigen Schutz.

Verwundbarer Code

# dash_uploader/httprequesthandler.py
def _post(self):
    resumableTotalChunks = request.form.get("resumableTotalChunks", type=int)   # attacker-controlled, no bounds
    ...
    chunk_paths = [
        os.path.join(temp_dir, get_chunk_name(resumableFilename, x))
        for x in range(1, resumableTotalChunks + 1)                              # unbounded; e.g. 30M -> ~2.9 GB -> OOM
    ]
    upload_complete = all([os.path.exists(p) for p in chunk_paths])              # all([]) is True -> truncation when chunks=0
    if upload_complete:
        target_file_name = os.path.join(temp_root, resumableFilename)
        if os.path.exists(target_file_name):
            os.unlink(target_file_name)                                          # existing file deleted
        with open(target_file_name, "ab") as target_file:
            for p in chunk_paths:                                                # empty list -> empty file written
                ...

Derselbe Codepfad erzeugt sowohl den OOM-Absturz (großes resumableTotalChunks) als auch die Dateikürzungs-Primitive (resumableTotalChunks=0).

Angriffsvektoren

Ein Angreifer sendet nicht authentifizierte POST-Anfragen an den Endpunkt /API/resumable.

• OOM-Absturz: 5 gleichzeitige Anfragen mit resumableTotalChunks=30000000 weisen jeweils ~2,9 GB zu und lösen den OOM-Killer aus.
• Speicherplatzerschöpfung: Uploads starten, aber niemals abschließen; verwaiste temporäre Dateien sammeln sich endlos an.
• Dateikürzung: resumableTotalChunks=0 senden; Python all([])=True verleitet den Server dazu, die Zieldatei mit leerem Inhalt zu überschreiben.
• Größenumgehung: Jedes vom Entwickler festgelegte Größenlimit wird nur im Client-JavaScript durchgesetzt, sodass eine direkte HTTP-Anfrage es vollständig umgeht.

Es sind keine Authentifizierung oder Berechtigungen erforderlich.

Auswirkungen

• Absturz des Serverprozesses durch den Linux-OOM-Killer, ausgelöst durch unbegrenzte Speicherzuweisung über einen einzelnen benutzergesteuerten POST-Parameter (resumableTotalChunks)
• Dauerhafte Speicherplatzerschöpfung durch verwaiste Upload-Sitzungen, die nie bereinigt werden (kein TTL, keine Garbage Collection und kein Ablaufmechanismus in der Codebasis)
• Erschöpfung der Dateisystem-Inodes durch Erstellung von Verzeichnissen mit beliebiger Tiefe mittels os.makedirs() und nicht bereinigtem resumableIdentifier
• Datenvernichtung durch Kürzung von Dateien auf null Byte, verursacht durch Pythons all(), das bei leeren Iterablen True zurückgibt, wenn resumableTotalChunks=0
• Umgehung aller Dateigrößenbeschränkungen, da max_file_size nur im clientseitigen JavaScript durchgesetzt wird, während der serverseitige Handler keinerlei Größenvalidierung durchführt und Flask MAX_CONTENT_LENGTH niemals setzt

Betroffene Komponenten

• dash_uploader/httprequesthandler.py (BaseHttpRequestHandler._post-Methode)
• dash_uploader/upload.py (Upload-Funktion, Parameter max_file_size)
• dash_uploader/configure_upload.py (fehlendes MAX_CONTENT_LENGTH)

Mitigation

⚠️ Es ist kein Patch verfügbar, und das Projekt ist archiviert

Optionen für derzeitige Installationen, in der Reihenfolge der Präferenz:

1. Migrieren Sie zu dcc.Upload, der offiziellen Upload-Komponente, die mit Plotly Dash ausgeliefert wird. Sie besitzt keinen Chunk-Anzahl-Parameter, keinen temporären Zustand auf der Festplatte und respektiert Flask MAX_CONTENT_LENGTH. Keines der vier hier genannten Probleme trifft zu. Am besten geeignet für kleine und mittlere Dateien. Für sehr große Uploads siehe Punkt 2.
2. Erstellen Sie einen kleinen Flask-Upload-Handler mit expliziter Größenbegrenzung pro Anfrage (MAX_CONTENT_LENGTH), Beschränkung der vom Client gelieferten Chunk-Anzahl und einer Allowlist für akzeptierte Dateinamen.
3. Wenn Sie dash-uploader weiterhin verwenden, setzen Sie Flask MAX_CONTENT_LENGTH auf Anwendungsebene (die Bibliothek tut dies nicht) und lehnen Sie Eingaben auf Anwendungs- oder Reverse-Proxy-Ebene ab, sofern einer der folgenden Punkte zutrifft:
   • resumableTotalChunks <= 0
   • resumableTotalChunks eine angemessene Obergrenze überschreitet (z. B. 10.000)
   • resumableTotalSize das vom Entwickler konfigurierte max_file_size überschreitet
4. Fügen Sie ein Ratenlimit am Upload-Endpunkt auf Reverse-Proxy- oder WAF-Ebene hinzu, um den OOM-Angriffsvektor durch gleichzeitige Anfragen abzuschwächen.
5. Bereinigen Sie verwaiste temporäre Verzeichnisse regelmäßig mithilfe eines externen Cron-Jobs, da die Bibliothek keine interne Bereinigung besitzt.

Offenlegungs-Timeline

Paketkontext

• Etwa 28.000 monatliche Downloads auf PyPI (27.756 in den 30 Tagen vor dem 2026-05-07, mit anhaltendem täglichem Volumen trotz Archivierung des Repositories). Quelle: pypistats.org.
• Neueste veröffentlichte Version: 0.6.1 (stabile Linie). Vorabversionen reichen bis 0.7.0a2.
• Erforderliche Abhängigkeit: dash. Optionale Abhängigkeit: pyyaml. Lizenz: MIT.
• 11 abhängige Pakete, 6 abhängige Repositories.
• 153 GitHub-Sterne.
• Repository am 2025-07-19 archiviert (Issue #153).
• Keine früheren CVEs (am 2026-03-19 gegen NVD, GitHub Advisory Database, Snyk und OSV verifiziert).

Referenzen

• https://www.cve.org/CVERecord?id=CVE-2026-38361
• https://nvd.nist.gov/vuln/detail/CVE-2026-38361
• https://github.com/fohrloop/dash-uploader
• https://github.com/fohrloop/dash-uploader/blob/stable/dash_uploader/httprequesthandler.py
• https://github.com/fohrloop/dash-uploader/issues/153
• https://pypi.org/project/dash-uploader/
• https://pypistats.org/packages/dash-uploader
• https://libraries.io/pypi/dash-uploader
• https://pepy.tech/project/dash-uploader
• https://cwe.mitre.org/data/definitions/400.html
• https://cwe.mitre.org/data/definitions/670.html
• https://docs.python.org/3/library/functions.html#all

Entdecker

Muhammad Fitri Bin Mohd Sultan