What is the CVSS score of CVE-2026-54341?

CVE-2026-54341 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.4%.

Which versions of DragonflyDB are affected by CVE-2026-54341?

DragonflyDB in-memory database installations are vulnerable to unauthenticated remote denial of service, allowing any network-adjacent attacker to crash the entire server using a trivial 24-byte…. A patch is available.

How to fix or mitigate CVE-2026-54341?

Within 24 hours: identify all DragonflyDB instances in production environments and document current versions. Within 7 days: upgrade all instances to DragonflyDB 1.39.0 or later; if immediate patching is not feasible, restrict network access to the DragonflyDB port to trusted clients only. Within 30 days: complete validation that all systems are on patched versions and conduct availability testing.

DragonflyDB CVE-2026-54341

EUVD-2026-39811 HIGH

Out-of-bounds Read (CWE-125)

2026-06-26 GitHub_M

Denial Of Service Buffer Overflow Information Disclosure Dragonfly

7.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

Default no-auth network exposure gives AV:N/AC:L/PR:N/UI:N; single command crashes the whole process for A:H, with no confidentiality or integrity impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 26, 2026 - 19:02 EUVD

Source Code Evidence Fetched

Jun 26, 2026 - 17:52 vuln.today

Analysis Generated

Jun 26, 2026 - 17:52 vuln.today

DescriptionCVE.org

Dragonfly is an in-memory data store built for modern application workloads. Prior to 1.39.0, a crafted RESTORE payload triggers an out-of-bounds read in DragonflyDB's listpack collection loaders, crashing the entire server process (SIGSEGV). Because DragonflyDB requires no authentication by default and RESTORE is a normal keyspace command, an unauthenticated remote attacker can crash the server with a single ~24-byte command - a remote, repeatable denial of service. This vulnerability is fixed in 1.39.0.

AnalysisAI

Remote denial of service in DragonflyDB before 1.39.0 lets an unauthenticated attacker crash the entire server with a single ~24-byte RESTORE command carrying a malformed listpack payload, triggering an out-of-bounds read (SIGSEGV). Because Dragonfly ships with no authentication enabled by default and RESTORE is an ordinary keyspace command, any client that can reach the port can repeatedly kill the process. No CISA KEV listing exists, but the fixing pull request publishes the exact crash payloads as regression tests, so working trigger data is effectively public.

Technical ContextAI

DragonflyDB is a Redis/Memcached-compatible in-memory data store. The flaw lives in its RDB-style deserialization path: when a RESTORE payload encodes a collection (set, hash, sorted set, list/quicklist, or stream) using the compact 'listpack'/'ziplist' encoding, the loaders (SetFamily::LoadLPSetBlob, HSetFamily::LoadListpackBlob, ZSetFamily::LoadListpackBlob, and the stream/quicklist loaders) called lpValidateIntegrity with the 'deep' parameter set to 0 - a shallow header check only. A crafted listpack with a valid outer header but an interior 32-bit string entry declaring length 0x7fffffff passes shallow validation; the subsequent read walks past the buffer. This is a textbook CWE-125 out-of-bounds read rooted in trusting attacker-supplied length fields during structure parsing. The fix threads a 'deep' flag through every loader and sets config.deep_integrity = true for RESTORE, forcing full element-by-element listpack validation that rejects the payload with 'ERR Bad data format'.

RemediationAI

Vendor-released patch: upgrade to DragonflyDB 1.39.0 or later, which enforces deep listpack integrity validation on RESTORE payloads. Where immediate upgrade is not possible, the most effective compensating control is to remove untrusted network reachability: bind Dragonfly to localhost or a trusted private interface and use firewall/security-group rules to restrict the port to known application hosts only - this directly eliminates the unauthenticated remote attacker path at the cost of breaking any legitimate remote clients that are not allowlisted. Enabling authentication (requirepass) raises the bar so only credentialed clients can issue RESTORE, though it does not fix the underlying parsing bug and offers no protection against an authenticated or credential-holding attacker. If your application never uses DUMP/RESTORE, consider command renaming/disabling of RESTORE via configuration to block the trigger entirely, accepting that any tooling relying on RESTORE will fail. Reference the advisory at https://github.com/dragonflydb/dragonfly/security/advisories/GHSA-cwjr-j869-h8q9 and PR https://github.com/dragonflydb/dragonfly/pull/7502.