hackney: Unbegrenzte Pufferung und Dekomprimierung von Antwortkörpern im Erlang-HTTP-Client
Zusammenfassung
Der HTTP-Client hackney für Erlang und Elixir puffert vollständige HTTP-Antwortkörper ohne Grössenbegrenzung im Speicher. Bei aktiviertem auto_decompress werden komprimierte Körper zudem in einem Schritt entpackt, sodass eine kleine komprimierte Antwort sehr gross werden kann. Ein böswilliger HTTP-Server, mit dem der Client eine Verbindung aufbaut, kann den Speicher des Client-Prozesses oder Knotens erschöpfen und so einen Denial-of-Service auslösen; eine Authentifizierung ist nicht nötig.
Betroffen
- hackney ab 2.0.0-beta.1 bis vor 4.9.0
- Git-Bereich dc41b79339ca0c41e16d3f2dd17172bc2de855d6 bis vor 493e8bf83a391548e5101792276ab3fc428fa76c
Behoben in
- Behoben in hackney 4.9.0 (Fix-Commit 493e8bf83a391548e5101792276ab3fc428fa76c, zugehöriger PR #980)
- Möglicherweise existiert eine neuere 4.9.x-Version; vor dem Fixieren auf der Release-Seite prüfen
Umgehung
- auto_decompress deaktiviert lassen (Standard); dies schliesst den Verstärkungsteil durch Dekomprimierung
- Das unbegrenzte Lesen des rohen Antwortkörpers hat keinen Workaround
- URLs, die die Anwendung abruft, einschränken, insbesondere benutzerdefinierte URLs
Ausnutzung
- Keine Hinweise auf Ausnutzung in freier Wildbahn; nicht im CISA-KEV-Katalog
- CISA SSVC: Ausnutzung keine, automatisierbar ja, technische Auswirkung partiell
- Der CNA-Eintrag beschreibt eine Reproduktionsmethode; EPSS 0.00564
Unsere Empfehlung
- Erlang- und Elixir-Anwendungen sowie Lockfiles (rebar.lock, mix.lock) auf hackney-Versionen unter 4.9.0 prüfen, einschliesslich transitiver Abhängigkeiten wie HTTPoison
- Auf hackney 4.9.0 oder die neueste 4.9.x-Version aktualisieren und das neue Limit von 512 MiB für gepufferte Körper (max_body_size) testen
- Falls ein Update verzögert wird, auto_decompress dort deaktivieren, wo es nicht benötigt wird, und ausgehende Anfragen auf vertrauenswürdige URLs beschränken
- Speichernutzung der Anwendungen auf unerwartetes Wachstum überwachen
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- CNA record CVE-2026-97200 (EEF) cna.erlef.org
- OSV record EEF-CVE-2026-97200 osv.dev
- hackney 4.9.0 release github.com
- Fix commit 493e8bf github.com
- Introducing commit dc41b79 github.com
- Pull request #980 github.com
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 14:57.
Referenzen der NVD (6)
- https://cna.erlef.org/cves/CVE-2026-97200.html
- https://github.com/benoitc/hackney/commit/493e8bf83a391548e5101792276ab3fc428fa76c
- https://github.com/benoitc/hackney/commit/dc41b79339ca0c41e16d3f2dd17172bc2de855d6
- https://github.com/benoitc/hackney/pull/980
- https://github.com/benoitc/hackney/releases/tag/4.9.0
- https://osv.dev/vulnerability/EEF-CVE-2026-97200
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.