CVE-2026-104192 in Dragonfly
Summary
by MITRE • 10/13/2026
Dragonfly is an in-memory data store built for modern application workloads. Prior to 1.40, OpaqueObjLoader::CreateStream in src/server/rdb_load.cc can associate one streamNACK with a consumer group's global PEL and a consumer-local PEL, then free the shared object when a duplicate consumer entry is rejected. Cleanup subsequently frees the same object again. In the default configuration, where Dragonfly ships with authentication disabled, an unauthenticated client can trigger the double-free by sending a crafted serialized stream to RESTORE, causing allocator corruption, denial of service, and potentially attacker-controlled code execution as the Dragonfly service account. The source fix has not yet been mapped to a published release.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/13/2026
Dragonfly is an in-memory data store designed for modern application workloads that supports various Redis-compatible commands including RESTORE which allows clients to restore serialized data into the database. A critical vulnerability exists within the OpaqueObjLoader::CreateStream function located in src/server/rdb_load.cc, specifically affecting versions prior to 1.40. This flaw involves a double-free memory corruption issue triggered during the processing of stream data structures associated with consumer groups and consumers. The vulnerability arises from improper handling of shared objects when duplicate consumer entries are rejected within the serialization logic.
The technical mechanism of this vulnerability begins when an OpaqueObjLoader::CreateStream operation associates one streamNACK with both a consumer group's global Pending Entry List PEL and a consumer-local PEL. This dual association creates a reference to a single underlying object that is managed by multiple logical structures within the Dragonfly memory model. When the system encounters a duplicate consumer entry during processing, it rejects the new entry but fails to properly adjust the reference counts or ownership semantics of the shared streamNACK object. Consequently, subsequent cleanup routines proceed to free this same object twice because both the global PEL and local PEL attempt to release their respective references without recognizing that they point to the identical memory allocation.
This double-free condition leads directly to allocator corruption within Dragonfly's internal memory management subsystem. In C++ based systems like Dragonfly, freeing a pointer more than once results in undefined behavior as described by CWE-415 Double Free. The immediate operational impact is typically a denial of service where the server process crashes due to heap metadata inconsistency or segmentation faults. However, because this occurs within an in-memory data store that processes untrusted input from network clients, the consequences extend far beyond simple availability loss. An attacker who can trigger this condition may achieve arbitrary code execution with the privileges of the Dragonfly service account by carefully crafting the serialized stream payload to manipulate heap structures and overwrite function pointers or other critical memory locations during the second free operation.
The severity of this vulnerability is significantly amplified by default configuration settings in many deployments where authentication is disabled for ease of use in development environments. This means that an unauthenticated remote attacker can interact directly with the RESTORE command endpoint without needing valid credentials to exploit the flaw. The ability to send a crafted serialized stream allows external actors to trigger the double-free condition remotely, making this a high-risk vulnerability for any Dragonfly instance exposed to untrusted networks or running with default security settings that lack access controls.
From an industry standard perspective, this issue aligns with CWE-416 Use After Free which is closely related to double free scenarios where memory state becomes inconsistent after deallocation. It also maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter if the exploitation leads to code execution, or more broadly to initial access vectors that leverage misconfigured services for privilege escalation within the host environment. The vulnerability represents a classic example of how complex object lifecycle management in high-performance data stores can introduce severe security risks when reference counting logic is flawed.
Mitigation strategies must prioritize immediate patching as the source fix has not yet been mapped to a published release, requiring users to compile from source or wait for an official update if available through their distribution channels. In the interim, organizations should enforce strict network segmentation to ensure Dragonfly instances are only accessible by trusted clients and applications. Enabling authentication is critical even in production environments where it might be considered optional, as this vulnerability specifically targets unauthenticated access paths. Additionally implementing input validation on serialized data before processing can help mitigate some risks although relying solely on application layer defenses against memory corruption bugs is not recommended given the low-level nature of the flaw. Regular security audits and static analysis tools focused on C++ memory management practices should be employed to detect similar issues in custom builds or forks of Dragonfly.