CVE-2026-54073 in VeraCrypt
Summary
by MITRE • 08/21/2026
VeraCrypt provides disk encryption with strong security based on TrueCrypt. From 1.26.6 until 1.26.29, file-hosted hidden volume creation forces quick format and the FormatNoFs function in src/Common/Format.c and FormatFat function in src/Common/Fat.c use WriteFile to place raw zeroed sectors at predictable 128 MiB intervals. These writes bypass the normal EncryptDataUnits formatting path, leaving deterministic plaintext markers in an area expected to resemble random ciphertext. The markers can weaken plausible deniability during forensic inspection, although they do not disclose hidden-volume content or reduce the strength of VeraCrypt encryption. This issue is fixed in version 1.26.29.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
VeraCrypt is a widely used open-source disk encryption software that provides strong security based on the TrueCrypt architecture. In versions ranging from 1.26.6 through 1.26.29, a specific implementation flaw affects the creation of file-hosted hidden volumes. This vulnerability stems from how the formatting process handles initial sector writes during volume initialization. Specifically, the FormatNoFs function located in src/Common/Format.c and the FormatFat function in src/Common/Fat.c utilize standard Windows API calls such as WriteFile to place raw zeroed sectors at predictable intervals of 128 MiB throughout the container file. This approach bypasses the normal EncryptDataUnits formatting path, which is designed to ensure that all data written to the volume appears cryptographically random and indistinguishable from noise.
The core technical flaw lies in the generation of deterministic plaintext markers within areas of the encrypted volume that are expected to resemble random ciphertext due to encryption padding or initialization vectors. By writing predictable zeroed blocks at fixed intervals, the software introduces statistical anomalies into what should be a uniformly distributed byte stream. While these markers do not disclose the actual content of the hidden volume nor reduce the mathematical strength of the underlying encryption algorithms like AES or Serpent, they significantly weaken plausible deniability during forensic inspection. An adversary performing deep analysis on the encrypted container file could potentially identify these regular patterns as indicators that the file is a VeraCrypt volume rather than random data, thereby undermining one of the primary security benefits of hidden volumes which rely on obscurity and indistinguishability from noise to protect against coercion or targeted attacks.
From an operational impact perspective, this vulnerability primarily affects users who require high levels of plausible deniability for their sensitive data storage. In scenarios where legal pressure is applied to reveal encryption keys, the ability to prove that a file contains encrypted data rather than random garbage can be critical. The presence of these deterministic markers allows forensic analysts to distinguish VeraCrypt containers from other types of files with higher confidence than if the volume were truly indistinguishable from noise. However, it is important to note that this does not constitute a direct compromise of confidentiality or integrity for the stored data itself; an attacker cannot decrypt the contents without the correct password and key material. The risk is strictly related to metadata leakage regarding the existence and nature of the encrypted container.
This issue aligns with CWE-209, which describes the generation of an error message that reveals sensitive information, although in this context it manifests as structural patterns rather than explicit text errors. It also relates to CWE-358, improper handling of internal state or data structures leading to predictable outputs where randomness is expected. In terms of MITRE ATT&CK framework relevance, while not a direct attack vector for exploitation by an external adversary without prior access, it impacts the defense-in-depth strategy related to anti-forensics and evidence tampering prevention techniques often categorized under T1562 Impair Defenses or specifically regarding data obfuscation. The vulnerability highlights the importance of ensuring that cryptographic implementations maintain statistical uniformity in their output even during initialization phases.
The recommended mitigation is straightforward: users must upgrade VeraCrypt to version 1.26.29 or later, where this formatting behavior has been corrected to ensure that all sectors are processed through the proper encryption routines without leaving predictable plaintext markers at fixed intervals. For organizations relying on VeraCrypt for sensitive data protection, verifying the installed version and applying updates promptly is essential to maintain the intended security posture regarding plausible deniability. Additionally, administrators should review their software update policies to ensure timely patching of cryptographic tools used across endpoints, as even minor deviations in implementation can have significant implications for threat modeling and forensic resilience.