Dragonfly: Unbegrenzte Speicherallokation über negativen COUNT in Zufallsbefehlen

Zusammenfassung

Dragonfly bis Version 2.0.2 erlaubt es nicht authentifizierten Clients, eine unbegrenzte Speicherallokation auszulösen, indem sie HRANDFIELD, ZRANDMEMBER oder SRANDMEMBER mit einem grossen negativen COUNT-Wert senden. Ein einzelner Befehl kann den Arbeitsspeicher des Hosts erschöpfen, woraufhin der OOM-Killer des Betriebssystems die Dragonfly-Instanz beendet und alle Clients trennt. Die Schwachstelle betrifft nur die Verfügbarkeit, und das Risiko hängt davon ab, ob die Instanz aus unvertrauenswürdigen Netzen erreichbar ist.

Betroffen

• Dragonfly bis Version 2.0.2 (dragonflydb/dragonfly), gemäss CVE-Eintrag
• Vom Hersteller bestätigte korrigierte Version: Unbekannt.

Behoben in

• Unbekannt. Es gibt keine Herstellerwarnung und kein Release, das eine korrigierte Version für diese CVE nennt.
• Ein vorgeschlagener Fix (PR #8653) fügt ein Limit --max_rand_count hinzu; der Status der Zusammenführung ist unbekannt.
• Ein Upgrade auf 2.0.2 behebt das Problem nicht, da 2.0.2 im betroffenen Bereich liegt.

Umgehung

• Dragonfly-Ports nicht gegenüber unvertrauenswürdigen Netzen oder dem Internet exponieren; Zugriff mit Firewall-Regeln oder Kubernetes NetworkPolicies einschränken.
• Authentifizierung für alle Clients erzwingen, damit der nicht authentifizierte Angriffspfad geschlossen wird.
• Die Instanz mit Speicherlimit und automatischem Neustart betreiben, um die Auswirkungen eines OOM-Kills zu begrenzen (Neustarts verhindern den Absturz nicht).
• Hinweis: Dies sind Empfehlungen, keine Herstellervorgaben.

Ausnutzung

• Technische Details sind öffentlich verfügbar (GitHub-Issue #8578).
• Die Ausnutzung ist einfach, sobald der Dienst-Port erreichbar ist: Ein einzelner Befehl genügt.
• Es wurden keine Hinweise auf eine Ausnutzung in freier Wildbahn gefunden; die CVE ist soweit bekannt nicht im CISA-KEV-Katalog aufgeführt.
• CISA SSVC: Ausnutzungsstatus poc, automatisierbar ja, technische Auswirkung partiell.

Unsere Empfehlung

• Alle Dragonfly-Instanzen inventarisieren, auch solche, die sich hinter Redis-kompatiblen Verbindungszeichenfolgen verbergen.
• Jede direkte Exposition gegenüber unvertrauenswürdigen Netzen entfernen und Authentifizierung erzwingen.
• Speicherlimits und automatischen Neustart einrichten sowie auf unerwartete Neustarts und OOM-Ereignisse überwachen.
• Den upstream Fix verfolgen und NVD- sowie Herstellerstatus erneut prüfen, da der NVD-Status Deferred ist.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• GitHub issue #8578 (technical description) github.com
• Fix PR #8653 github.com
• VulnCheck advisory www.vulncheck.com
• VulDB entry vuldb.com
• Dragonfly releases github.com
• NixOS tracker github.com
• Vulnrichment affected range (OffSeq Radar) radar.offseq.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 02:25.