Most FDE vendors/projects don't consider vectors requiring repeated physical access as a vulnerability.

But there is another side to this: an HDD/SSD firmware backdoor (or a network attacker injecting arbitrary data into a disk image booted over the network) has a way to inject attacker-controlled data into an encrypted volume despite code integrity controls like Secure Boot and TPM-based unlocks (the "Implementation and Implications of a Stealth Hard-Drive Backdoor" paper told us the opposite).

In one MSRC case, Microsoft agreed to treat the data-only attack against BitLocker from the storage path as a vulnerability.

CVE-2024-13745 in EDK II (likely, "WONTFIX"): "what you measure is not what you use".

The story about firmware measuring bytes different from ones being used. It affects PCR[5], so the severity is low (nobody cares about PCR[5] by default).

https://www.openwall.com/lists/oss-security/2026/05/29/2

NotCVE-2026-0002: if you run two NetScalers in the high availability (HA/HA-INC) deployment, no SSH host key checks are performed between them, even when you followed every advice listed here: https://docs.netscaler.com/en-us/netscaler-adc-secure-deployment/configuration-guidelines/network-security (see: Set up secure communication between peer appliances)

The vendor reported that this issue has been fixed in 14.1-60.52.
No security advisory, CVE ID, release notes entry was published. Although this is a minor vulnerability, it is a vulnerability.

My long post about wide-block & AEAD modes in full-disk encryption: it cover threat models, vulnerabilities, and edge cases.

Key points:
- It's common for FDE implementations to fail outside of the encryption layer.
- Wide-block modes don't protect against CWE-636 (Failing Open), which can lead to things like CVE-2025-4382.
- AEAD modes vs. code that doesn't handle read errors correctly: even FS drivers can misbehave (e.g., validation errors get suppressed and also lead to missing directory entries).
- Defusing the Elephant diffuser: injecting a bunch of null bytes into the BitLocker-encrypted volume (AES-CBC with Elephant diffuser). An interesting but unexploitable bug present since Vista.
- BestCrypt Volume Encryption breaks many XTS mode guarantees (and the vendor doesn't care).

https://dfir.ru/2025/05/08/disk-encryption-wide-block-modes-authentication-tags-arent-silver-bullets/

Unfortunately, this paper from 2017 is still relevant.

https://github.com/MotherOfAllVoids/bachelor_thesis/blob/master/text/flaw.pdf

1. BestCrypt Volume Encryption (BCVE) allows watermarking attacks.
2. BCVE allows plaintext injection attacks.
3. BCVE allows forced decryption of some sectors.

It doesn't matter that AES-XTS is used, the vulnerability is in the function wrapping encryption/decryption routines.

Jetico is aware of this flaw, but they won't fix it.

The first two attacks aren't relevant if your threat model excludes users mounting encrypted volumes after an adversary had access to them. This is not the same as physical access, because remote access to unmounted encrypted volumes is possible in dual-boot scenarios, etc.

The third attack allows adversaries to remotely force the decryption of some sectors (like those belonging to a database used by a web-facing application) through spraying (repeatedly causing the INSERT operation of) a specific 16-byte pattern.

Do we really need XTS key scopes here?

According to Microsoft (MSRC), attacks involving symlinks stored on removable drives or in file system images (like VHDX) are not vulnerabilities.

If an unprivileged user manages to quickly replace a regular file in such a location with a symlink to another file (can point anywhere, even into the C:\Windows directory), this is okay.

This means that attackers can defeat existing symlink mitigations ("RedirectionTrust" plus "only privileged users can create symlinks to files") when they are capable of:

- attaching and mounting a removable drive (AV:P/PR:L), or

- mounting a VHDX image (AV:N/PR:N in the worst case, when a VHDX image is delivered via e-mail and then it gets double-clicked by a user, no code execution on the target machine required), or

- mounting a custom file-based container using disk encryption software like VeraCrypt (AV:L/PR:L, because anyone can mount a file-based container).

There is a small bonus: attackers win the race (against the program that follows symlinks when performing privileged operations) in almost every case, because the "replace a regular file with a symlink to another file" primitive comes from the NTFS driver, which performs "a more atomic" replace operation than any usermode application.

The secret is... This is about a crafted file system image, when the "\test\test.txt" file is opened/listed for the first three times (this number is attacker-controlled and can be tuned), it's a regular file; when this file is opened for the fourth time, it's a symlink (the actual replace is performed by the healing routines in the NTFS driver).

I'm attaching a screenshot demonstrating the "not-a-vulnerability".

Symlink attacks without code execution? Yes!