CVE-2026-116728 in libfvde
Summary
by MITRE • 10/26/2026
libfvde through 20260923 contains a heap out-of-bounds read vulnerability in libfvde_encrypted_metadata_read_type_0x0024() because xml_plist_data_size is not checked against the source metadata block. Attackers can supply a crafted FileVault 2 Core Storage volume that makes libfvde_volume_open() copy past the heap block buffer, crashing the application.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in libfvde versions up to and including release 20260923 represents a critical memory safety flaw within the library's handling of encrypted metadata for FileVault 2 Core Storage volumes. This specific issue resides in the function libfvde_encrypted_metadata_read_type_0x0024, which is responsible for parsing and processing metadata blocks associated with volume encryption structures. The root cause of this vulnerability is a failure to perform adequate bounds checking on the xml_plist_data_size variable relative to the actual size of the source metadata block provided by the input data. In secure software design, any value derived from external or untrusted sources must be validated against the allocated buffer limits before being used for memory operations such as copying or reading. The absence of this validation allows an attacker who controls the content of a FileVault 2 Core Storage volume image to manipulate these size parameters effectively bypassing standard safety checks inherent in the parsing logic.
From a technical perspective, when libfvde_volume_open is invoked with a crafted malicious input file, it triggers the metadata reading routine that contains the flaw. Because the xml_plist_data_size value exceeds the actual allocated heap block buffer but passes internal validation due to the missing check against the source metadata block size, subsequent memory copy operations proceed without boundary verification. This results in a heap out-of-bounds read where the application attempts to access memory locations beyond the end of the allocated heap segment. Such an operation violates fundamental principles of memory isolation and can lead to immediate process termination or crash due to segmentation faults or illegal memory access violations enforced by modern operating systems. The vulnerability is classified under CWE-125, which describes out-of-bounds read errors that occur when software reads data from a buffer beyond its allocated boundaries.
The operational impact of this vulnerability primarily manifests as a denial of service condition for applications relying on libfvde to parse or mount FileVault 2 encrypted volumes. An attacker can exploit this flaw by constructing a specially crafted Core Storage volume image where the metadata headers contain inflated size fields that do not correspond to the actual data payload length. When security tools, forensic analysis software, or automated mounting utilities process such an image, they are likely to crash upon encountering the malformed metadata during the opening phase of the volume. This disruption prevents legitimate users from accessing encrypted data and can hinder incident response efforts if critical evidence is stored on compromised volumes that cannot be safely opened due to this instability in the underlying library.
In terms of threat modeling and industry standards, this vulnerability aligns with ATT&CK technique T1490, which involves Inhibit System Recovery, as crashing security or forensic tools can impede recovery operations from disk images. Furthermore, it reflects common patterns found in CWE-20 regarding improper input validation where external data is not sufficiently verified before use. The lack of rigorous boundary checks on integer values derived from file headers is a recurring issue in C-based libraries that handle complex binary formats like those used by Apple's FileVault encryption scheme.
To mitigate this risk, developers must implement strict bounds checking within the libfvde_encrypted_metadata_read_type_0x0024 function to ensure that xml_plist_data_size does not exceed the size of the source metadata block before any memory operations are performed. This includes validating that all length fields in the header structures are consistent with the actual file sizes and allocated buffers. Updating to a patched version of libfvde where this validation logic has been corrected is essential for maintaining system stability. Additionally, security teams should employ fuzzing techniques targeting binary parsers like libfvde to identify similar out-of-bounds issues across other metadata types beyond just 0x0024. Regular code audits focusing on memory management practices and the integration of static analysis tools can further reduce the likelihood of such vulnerabilities persisting in future releases, ensuring robust handling of potentially malicious inputs from untrusted sources.