CVE-2026-111279 in Dragonflyinfo

Summary

by MITRE • 10/16/2026

Dragonfly through 2.0.2 contains an unbounded memory allocation vulnerability that allows unauthenticated clients to exhaust memory by passing a negative COUNT to HRANDFIELD, ZRANDMEMBER or SRANDMEMBER. Attackers can send a single command against a one-element key with a huge negative COUNT to trigger the OOM killer, terminating the instance for all clients.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/16/2026

The vulnerability identified in Dragonfly versions through 2.0.2 represents a critical unbounded memory allocation flaw that directly impacts the stability and availability of database instances. This issue stems from improper input validation within specific set-related commands, namely HRANDFIELD, ZRANDMEMBER, and SRANDMEMBER. These commands are designed to return random elements from hash, sorted set, or regular set data structures respectively. In a secure implementation, these functions should strictly validate the COUNT parameter provided by the client to ensure it falls within acceptable bounds relative to the size of the target collection. However, in this vulnerable version, the system fails to adequately check whether the COUNT argument is negative before proceeding with memory allocation logic.

When an unauthenticated or authenticated attacker sends a command such as HRANDFIELD key -1000000 against a key containing only one element, the server attempts to allocate memory for a result set that exceeds available resources by orders of magnitude. The underlying code interprets the negative count in a way that triggers an excessive allocation request rather than returning an error or limiting the output size. This behavior leads directly to rapid and uncontrolled consumption of system RAM. As the operating system detects this abnormal resource usage, it invokes the Out-Of-Memory (OOM) killer mechanism to protect the rest of the system from total collapse. The OOM killer terminates the Dragonfly process to reclaim memory, resulting in an immediate denial of service for all connected clients and any dependent applications relying on that database instance.

From a security architecture perspective, this flaw is classified under CWE-789: Uncontrolled Memory Allocation, which describes situations where software allocates more memory than expected or needed without proper bounds checking. The attack vector aligns with ATT&CK technique T1499: Endpoint Denial of Service, specifically the sub-category of resource exhaustion via application layer attacks. Because the vulnerability can be triggered by a single crafted packet from an unauthenticated source if network access is not strictly controlled, it poses a severe risk to environments where Dragonfly is exposed to untrusted networks or lacks robust authentication mechanisms at the transport level. The impact extends beyond simple downtime; frequent OOM events can lead to data corruption if write operations are interrupted mid-execution and require significant operational overhead for recovery and restart procedures.

Mitigation strategies must focus on both immediate patching and architectural hardening. The primary remediation is to upgrade Dragonfly to version 2.0.3 or later, where the input validation logic has been corrected to reject negative COUNT values with an appropriate error response instead of attempting memory allocation. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict access to the database port exclusively from trusted application servers using firewall rules or security groups. Additionally, deploying a Web Application Firewall (WAF) or reverse proxy capable of inspecting Redis-compatible protocol commands can help filter out malformed requests containing suspiciously large negative integers before they reach the database engine. Regular monitoring for high memory usage spikes and OOM killer events should also be established to detect potential exploitation attempts in real-time.

Responsible

VulnCheck

Reservation

10/15/2026

Disclosure

10/16/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!