CVE-2026-116729 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_0x001a() caused by an unbounded strlen on embedded XML plist data. Attackers can supply a crafted FileVault 2 volume with non-NUL-terminated plist data, causing libfvde_volume_open() to read past the heap block buffer.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in libfvde versions up through 20260923 represents a critical memory safety flaw within the library's handling of encrypted metadata structures for FileVault 2 volumes. This issue is specifically located in the function libfvde_encrypted_metadata_read_type_0x001a, which processes specific types of embedded XML property list data used during volume decryption initialization. The core technical defect stems from an unbounded execution of the strlen function on plist data that lacks a proper null terminator. In standard C programming practices, string functions like strlen rely on encountering a zero byte to determine the length of a character array. When this assumption is violated by malformed input where the expected terminating NUL character is absent or misplaced, the function continues reading memory sequentially beyond the intended buffer boundaries until it eventually encounters an arbitrary null byte elsewhere in the heap allocation space.
This lack of bounds checking allows for a heap out-of-bounds read vulnerability that can be exploited through crafted FileVault 2 volume images. An attacker who possesses access to construct or modify such volumes, potentially via physical access or compromised backup sources, can embed plist metadata with intentionally missing termination characters. When libfvde_volume_open is invoked to process this maliciously constructed image, the library attempts to parse the encrypted metadata and triggers the flawed strlen operation. Consequently, the application reads sensitive data from adjacent memory regions that are not part of the designated buffer for the plist content. This behavior exposes internal state information, potentially including pointers or other security-critical structures residing in nearby heap allocations, which could lead to further exploitation vectors such as information disclosure or denial of service conditions if the read access triggers a segmentation fault due to unmapped memory pages.
From an operational impact perspective, this vulnerability primarily affects systems relying on libfvde for forensic analysis or data recovery from encrypted volumes. While direct remote code execution is not immediately evident without additional context regarding how the returned string length is utilized downstream, the exposure of heap contents poses significant risks in security-sensitive environments. Forensic tools and automated scanning utilities that process large numbers of volume images are particularly susceptible to this issue if they do not implement strict input validation prior to invoking libfvde functions. The ability to read arbitrary memory locations can facilitate side-channel attacks or aid attackers in bypassing other mitigations by leaking cryptographic keys or authentication tokens stored in adjacent heap blocks, thereby compromising the confidentiality guarantees provided by FileVault encryption at rest.
To mitigate this vulnerability, developers must enforce strict input validation and length checks before processing any plist data within libfvde_encrypted_metadata_read_type_0x001a. The implementation should verify that string inputs are properly null-terminated or use bounded string functions such as strnlen with explicit maximum limits derived from the allocated buffer size rather than relying on implicit termination characters. Additionally, integrating fuzzing tests into the continuous integration pipeline can help detect similar off-by-one errors and boundary violations early in the development lifecycle. Users of libfvde should ensure they are running patched versions that address this specific memory safety issue and avoid processing untrusted or potentially tampered volume images without prior sanitization. This aligns with industry standards such as CWE-126, which covers buffer over-read conditions, and ATT&CK technique T1005 for data from local system memory, emphasizing the need for robust defensive coding practices in security libraries handling sensitive cryptographic metadata.