Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft BitLocker image with inflated dataset/datum sizes
-
ExploitInduce victim to open or mount with dislocker
-
ExecutionTrigger out-of-bounds read in get_next_datum()
-
ImpactCrash process or leak adjacent heap memory
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to open or mount an attacker-crafted BitLocker volume image whose metadata announces dataset or datum sizes larger than the allocated metadata buffer; the flawed get_dataset() and get_next_datum() paths then walk past the allocation. There is no special dislocker configuration needed - any default use of a vulnerable build (≤0.7.3) that parses the malicious image is affected. Limiting factors that reduce real-world risk: the attack vector is LOCAL (the attacker cannot reach the parser over a network - a malicious file must be delivered and processed), and it requires user interaction (UI:P) in that a victim must actually invoke dislocker on the crafted image, typically in forensic, incident-response, or disk-recovery workflows that handle untrusted BitLocker volumes. |
| Impact | This is a genuinely Medium-severity, lower-priority issue rather than an urgent one. The authoritative CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:H) scores 6.9 and tells a consistent story: exploitation is LOCAL (the attacker must get dislocker to process an attacker-supplied BitLocker image) and requires passive user interaction (the victim opening or mounting that image). It is unauthenticated (PR:N) but not remotely reachable. Impact is an availability hit (VA:H, crash/DoS) plus limited confidentiality loss (VC:L, disclosure of adjacent heap memory via CWE-125 out-of-bounds read); no integrity impact. No EPSS probability, CISA KEV listing, or public POC was provided in the input, so there is no signal of active or widespread exploitation - neither KEV nor POC is present, meaning no public exploit is identified at time of analysis. Combined with a local attack vector, mandatory user interaction, and a niche product footprint, real-world risk is well below what a raw 'High' label might suggest. The one caveat: this parses untrusted, attacker-controlled forensic/volume images, which is exactly the threat model where a memory-safety bug matters, so it should still be patched. A vendor patch is available and this is the recommended action. |
| Exploit ScenarioDerived | An attacker crafts a malicious BitLocker volume image declaring inflated dataset or datum sizes and delivers it to a victim (e.g., a USB drive, downloaded disk image, or forensic artifact submitted for analysis). When the victim opens or mounts the image with a vulnerable dislocker (≤0.7.3), the datum-walking code reads past the metadata heap allocation, either crashing the process or leaking adjacent heap memory into output. No public POC is identified, and the local vector plus required user interaction (UI:P) mean the attacker must socially engineer or otherwise induce the victim to process the file. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
Denial of service and heap memory disclosure in Dislocker 0.7.3 and earlier: a crafted BitLocker volume image whose metadata announces inflated dataset or datum sizes pushes the parsing routines get_dataset() and get_next_datum() past the end of the allocated metadata buffer, crashing the tool or leaking adjacent heap memory through the volume-parsing output. Any default build of Dislocker at or below 0.7.3 that opens the malicious image is affected, which is of practical concern mainly to forensic, incident-response, and disk-recovery workflows that routinely process untrusted BitLocker volumes. Exploitation is local and requires the victim to actually open or mount the crafted image (UI:P), and no public exploit code has been identified at time of analysis; an upstream fix commit is available. This is a genuinely Medium-severity, lower-priority issue rather than an urgent one, and it is not noted as confirmed actively exploited (CISA KEV).
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - the corrective change is commit 9158e9e41dd669b360cbc53cc18ccae729b67b48 in Aorimn/dislocker (https://github.com/Aorimn/dislocker/commit/9158e9e41dd669b360cbc53cc18ccae729b67b48), which adds the missing dataset/datum bounds validation; rebuild Dislocker from a revision at or after that commit, or upgrade to a tagged release that contains it once one is published, since the fix is not yet tied to a numbered version in the available data. Where rebuilding or upgrading is not immediately possible, the most effective compensating control is to treat every BitLocker image as untrusted input: never run the vulnerable parser directly on evidence acquired from third parties, and instead pre-validate or sanitize volume metadata in a disposable, unprivileged sandbox (container, VM, or restricted user account with no access to host data) so that a crash or heap read cannot reach sensitive adjacent memory or interrupt an investigation - the trade-off is added workflow overhead and the need to re-run extraction in the sandbox. Avoid mounting or decrypting untrusted images with elevated privileges, since the disclosed heap contents may include other data resident in the process, and restrict the use of dislocker to images with a verified chain of custody; disabling the mount path and limiting parsing to trusted, internally produced volumes removes the attack surface entirely at the cost of abandoning the untrusted-volume use case. Monitoring for abnormal dislocker crashes or segfaults on crafted images provides a useful detection signal while the commit-based fix is being rolled out, and the VulnCheck advisory (https://www.vulncheck.com/advisories/dislocker-through-0.7.3-heap-out-of-bounds-read-via-bitlocker-metadata-dataset-size) should be tracked for any subsequently published fixed version.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Dislocker is a FUSE-based utility that reads BitLocker-encrypted volumes, and the vulnerable code lives in its BitLocker metadata parser (src/metadata/metadata.c and src/metadata/datums.c). A BitLocker volume's metadata buffer carries an information header (bitlocker_information_t) followed by an embedded bitlocker_dataset_t containing a chain of datums; both the dataset and each datum carry self-declared size fields. The allocation itself is sized in get_metadata() from information->size, and for the V_SEVEN layout that field is expressed in 16-byte units (shifted left by 4). The bug is rooted in CWE-125 (out-of-bounds read): get_dataset() computed the dataset pointer but only sanity-checked header_size and copy_size, never verifying that dataset->size fit within the remaining metadata buffer, and get_next_datum() built its loop limit as (char*)dataset + dataset->size using that unvalidated, attacker-controlled field. The commit 9158e9e41dd669b360cbc53cc18ccae729b67b48 corrects this by recomputing metadata_size the same way get_metadata() did, deriving a max_dataset_size from offsetof(bitlocker_information_t, dataset), rejecting datasets whose size, header_size, or copy_size are inconsistent, and adding 'defense in depth' limit clamping plus nested-datum containment checks so that no datum or nested datum can be walked past its parent's end. The composite impact reflected in the assessed CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H vector is low-confidentiality impact from the heap read combined with high availability impact from the crash.
Know when Dislocker gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N
AV:L because a malicious image must be fed to the parser, UI:R because the victim must open/mount it, PR:N as no auth is needed; impact is a crash (A:H) plus limited heap disclosure (C:L), no integrity effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Dislocker through 0.7.3 contains a heap out-of-bounds read vulnerability in get_dataset() and get_next_datum() that never validate dataset and datum sizes against the metadata allocation. Attackers can craft a BitLocker volume image with inflated dataset or datum sizes that, when opened or mounted, crashes dislocker or discloses adjacent heap memory.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-95021
GHSA-gj99-98mp-m7r6
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB