Repository navigation
Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779
Description
Expected behavior
The encrypted VeraCrypt volume should remain securely locked, isolated, and completely unmounted after explicitly executing the dismount command. Any third-party application (like UTM) attempting to access files previously stored on that volume should fail, throwing an error that the paths or virtual machine images are completely inaccessible.
Observed behavior
A severe isolation failure occurs. After the volume is successfully unmounted via the VeraCrypt GUI and disappears from both the slot list and the Finder sidebar, it leaves "ghost" file descriptors behind in the macOS kernel.
When the UTM application is launched, it requests access to its recent VM paths. macOS recognizes the cached encryption keys still lingering in the system memory and instantly revives/remounts the active crypto-session. The VeraCrypt volume completely reappears as a mounted drive (/dev/disk4 / disk5) with full read/write privileges, bypassing all cryptographic checks, passwords, PIM, or keyfiles. Anyone with local access to the machine can manipulate, copy, or execute these files without restrictions.
Steps to reproduce
- Mount a VeraCrypt volume (Standard or Hidden) containing UTM virtual machine images (
.utm). - Run a virtual machine inside the UTM application located on this encrypted partition.
- Shut down the virtual machine completely and close the UTM application.
- Click "Dismount" inside the VeraCrypt GUI. Ensure the volume disappears from the active slots and the Finder sidebar.
- Launch the UTM application again.
- Run
diskutil listin the Terminal or check the Finder sidebar; the previously unmounted volume is completely back online and accessible without any password prompts.
Screenshots
1. State 1: VeraCrypt open, volume unmounted, UTM closed.
diskutil list shows only local storage (disk0 and disk3). No encrypted volumes are present in the system.
Refer to file: CleanShot 2026-06-16 at 18.39.25.jpg
2. State 2: Launching UTM without mounting anything in VeraCrypt.
Immediately after launching UTM, diskutil list reveals that the system automatically brought back the encrypted container as a ghost disk image without credentials:
Refer to file: CleanShot 2026-06-16 at 18.40.06.jpg
/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +47.2 GB disk4
/dev/disk5 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +47.2 GB disk5
Physical Store disk4
1: APFS Volume untitled 16.7 GB disk5s1
Your Environment
VeraCrypt version: 1.26.29
Operating system and version: macOS 26.5.1
System type: MacBook Pro M3 Pro
Activity
Christian-SC26 commentedon Jun 23, 2026
When trying to mount the disk to another slot - UTM completely stuck and throws an error -
"There was a problem connecting to the server "fuse-t-1".
The server may not exist or it is unavailable at this time. Check the server name or IP address, check your network connection, and then try again.
Furthermore, if we mount it back to the previous slot where it was before, UTM still retains full access to the encrypted files, even after they have been explicitly unmounted via VeraCrypt.
Christian-SC26 commentedon Jun 23, 2026
Here is the exact step-by-step scenario to reproduce the issue:
/Volumes/untitled/) appear in the Finder sidebar.tail -f /Volumes/untitled/anyfile.md/Volumes/.veracrypt_aux_mnt1/aux-device-info,control, andvolume.dmg.volume.dmg**like any standard macOS disk image — it mounts instantly, granting full, unrestricted access to all files inside the hidden VeraCrypt volume without requiring a password or any authentication.Conclusion:
It appears that if any process interacts with files inside an encrypted volume, the volume cannot be fully locked or purged from memory afterward. The decrypted cache and keys remain exposed in the system until a complete macOS reboot.
Christian-SC26 commentedon Jun 23, 2026
Update: Attempts to Manually Purge the Volume and Clear the Cache
I tried multiple ways to forcefully unmount the ghost volume and drop the unauthenticated access via the Terminal without a full system reboot. Surprisingly, none of them worked, and the core OS kernel continues to expose the decrypted data.
Here is what was verified:
Standard & Force Disk Unmounting:
sudo diskutil umount force /Volumes/.veracrypt_aux_mnt1returnsUnmount successful. However, the data remains fully accessible right after.sudo umount -f /Volumes/.veracrypt_aux_mnt1throws an error: “The operation can’t be completed because the original item for '.veracrypt_aux_mnt1' can’t be found.” Yet, the folder remains active and the files inside are readable.Killing the Background Processes:
ps ax | grep -i fusereveals that thefuse-tand VeraCrypt processes are already dead and completely gone from the process tree. No PID is actively holding the directory.Restarting Finder:
killall Findercauses Finder to restart, but it immediately initiates a re-scan of network sharepoints, reconnects to the kernel's cached VFS state, and fully restores unrestricted access to the files without a password prompt.Investigating the Network/NFS Stack:
fuse-tacts as a local NFS server, I checked the local RPC and network states:rpcinfo -preturns:rpcinfo: can't contact portmapper: RPC: Unable to send; errno = Broken pipe.netstat -an | grep 2049(default NFS port) returns absolutely nothing.sudo nfsd stopreports that the NFS daemon isn't even running.Conclusion:
This indicates a severe architecture issue on macOS where the virtual file system (VFS) kernel layer caches the decryption context/keys and refuses to flush them if any process touched the volume prior to dismounting. The system drops into a "zombie" state where the GUI thinks the volume is gone, but the raw decrypted volume image remains permanently exposed in kernel memory until a full system reboot.
PS: Every attempt to manually unmount the disk was made with an AI
Christian-SC26 commentedon Jun 25, 2026
The macFUSE version is working as expected. None of the above-described scenarios could be reproduced.
idrassi commentedon Jun 26, 2026
Thanks for the detailed follow-up and for testing the macFUSE build.
On macOS, the FUSE-T build uses an internal auxiliary mount named
.veracrypt_aux_mntX. This auxiliary mount exposes the already open VeraCrypt volume asvolume.dmg, and VeraCrypt then useshdiutilto attach it as the visible macOS disk.If the VeraCrypt GUI dismounts the visible volume but the FUSE-T auxiliary mount or its helper process remains alive, then opening
volume.dmgcan reattach the already open decrypted block device without asking for credentials again.So the issue is not that macOS cached the password or that VeraCrypt authentication was bypassed. The likely issue is that the FUSE-T auxiliary endpoint remains alive after VeraCrypt reports the volume as dismounted. That is still serious and I will investigate a fix so VeraCrypt verifies that the auxiliary FUSE-T mount and helper processes are actually gone before considering the dismount successful.
If you can reproduce again, please collect the following immediately after clicking Dismount in the VeraCrypt GUI, before launching UTM or manually opening
volume.dmg:ths256 commentedon Sep 13, 2026
I just reproduced the behavior with a test container.
I mounted the container and immediatelly unmounted it. Afterwards I could see fuse-t in the Network section with the .dmg file, which I could mount without entering a password.
The log only contains the mount and unmount