macOS: core-service + fuse-t server processes persist after dismount (stale Bonjour/Finder entries); fuse-t backend hardcoded to SMB, FSKit unusable

Environment: macOS 26.6 (25G72), MacBook Air M1 (MacBookAir10,1),
VeraCrypt 1.26.29 (FUSE-T Build), fuse-t 1.2.7 (Homebrew cask).

Issue 1 - processes leak on dismount:
Each volume mount spawns root-owned "VeraCrypt --core-service" processes plus
one fuse-t server: /usr/local/bin/go-nfsv4 --namedattr=false --rwsize=262144
--dontbrowse=true --backend smb /private/tmp/.veracrypt_aux_mnt1
After dismounting the volume, these processes persist indefinitely. I observed
intact core-service + go-nfsv4 pairs from multiple earlier mount sessions
coexisting. Each surviving go-nfsv4 holds an SMB Bonjour registration, so each
new mount registers as fuse-t-1, fuse-t-2, etc., and Finder accumulates stale
"fuse-t" network entries. The leaked processes ignore SIGTERM (sudo pkill);
SIGKILL is required. Killing the core-service correctly tears down go-nfsv4,
consistent with fuse-t's documented design that the server exits when its
filesystem process dies - so the leak appears to be core-service not exiting
after the last dismount.

Repro: mount a file container, dismount it, repeat once, then run:
ps aux | grep -E 'go-nfsv4|core-service' | grep -v grep
dns-sd -B _smb._tcp local. (observe fuse-t, fuse-t-1, ...)

Issue 2 - backend hardcoded to SMB:
fuse-t 1.2.x supports a native FSKit backend on macOS 26+. With the FSKit
extension enabled (fskitd/fskit_agent running) and
/Library/Application Support/fuse-t/cfg/fuse-t.ini set to backend=fskit,
a fully fresh VeraCrypt start still launches go-nfsv4 with an explicit
"--backend smb", overriding both fuse-t's documented default (NFS) and the
ini. VeraCrypt resolves the system libfuse-t 1.2.7 at /usr/local/lib (verified
via otool -L / LC_RPATH), so this is not a stale bundled library. There is
currently no way for users to select the FSKit backend. Request: honor the
fuse-t.ini default or expose a backend setting.

Context: this setup produced repeatable kernel panics when sleeping with a
volume mounted: panic(...): busy timeout[1], (60s): multiple entries holding
the registry busy ... 'IOMediaBSDClient' @IOService.cpp:5986. Full panic log
available (can attach).

I'm only a regular VeraCrypt user and not a developer of the project, but I did some investigation after reproducing this issue on my Mac.

I investigated this further and was able to reproduce the process/device-hold problem independently with a physical VeraCrypt volume.

Environment

macOS 26.6.x
Apple Silicon (MacBook Air M4)
VeraCrypt built from commit b48e31f5b47da7d41025e3f0e02751675e15005a
FUSE-T 1.2.7
Physical VeraCrypt volume on a 1 TB USB SSD

What happens after VeraCrypt dismount

After dismounting the volume from the VeraCrypt GUI, the visible filesystem and auxiliary mount disappear normally.

For example:

mount | grep -Ei 'veracrypt|fuse-t|smbfs|veracrypt_aux'
# no output

and hdiutil info shows no attached image.

However, the FUSE-T/VeraCrypt processes remain alive.

In my reproduction, the remaining processes included:

VeraCrypt --core-service
go-nfsv4 ... --backend smb /private/tmp/.veracrypt_aux_mnt1
VeraCrypt --core-service

More importantly, lsof showed that the leaked processes still had the physical raw disk open:

$ sudo lsof -nP /dev/disk4 /dev/rdisk4

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
go-nfsv4- 96407 root    3u   CHR   1,20  0t65536 785 /dev/rdisk4
VeraCrypt 96408 root    3u   CHR   1,20  0t65536 785 /dev/rdisk4

Because /dev/rdisk4 was still open, macOS Disk Utility could not eject the physical SSD.

If I killed the remaining VeraCrypt/FUSE-T processes first:

sudo pkill -KILL -f 'VeraCrypt'
sudo pkill -KILL -f 'go-nfsv4.*veracrypt_aux_mnt'

the raw-device holders disappeared, and the disk could immediately be ejected:

$ diskutil eject disk4
Disk disk4 ejected

The leaked VeraCrypt process is still inside `fuse_main()`

I also sampled the remaining VeraCrypt process after the GUI dismount.

Its main thread remained blocked inside FUSE-T for the entire sample:

fuse_main_real_compat25
  fuse_main_common
    fuse_loop_mt
      fuse_session_loop_mt
        fuse_sem_wait
          _pthread_cond_wait
            __psynch_cvwait

A FUSE worker thread was also still waiting in the receive path:

fuse_session_receive_buf
  fuse_ll_receive_buf
    fuse_chan_recv
      fuse_kern_chan_receive
        ...
          recvfrom

This suggests that although the macOS-visible mount has disappeared, fuse_main() has not returned.

That matters because VeraCrypt releases the mounted volume from the FUSE destroy path:

static void fuse_service_destroy (void *userdata)
{
    try
    {
        FuseService::Dismount();
    }
    ...
}

and FuseService::Dismount() calls CloseMountedVolume().

If the FUSE session never terminates, the backing physical device can remain open.

A/B test: removing only the forced SMB backend

I then tested the backend=smb option specifically.

The current FUSE-T path contains:

#ifdef VC_MACOSX_FUSET
    args.push_back ("-o");
    args.push_back ("backend=smb");
    args.push_back ("-o");
    args.push_back ("nonamedattr");
    args.push_back ("-o");
    args.push_back ("rwsize=262144");
#endif

I removed only:

args.push_back ("-o");
args.push_back ("backend=smb");

while leaving nonamedattr and rwsize=262144 unchanged.

After rebuilding VeraCrypt with that minimal change, the same physical SSD could be:

mounted by VeraCrypt,
dismounted normally,
and then ejected normally from macOS Disk Utility.

So on this system:

forced backend=smb
    -> VeraCrypt/FUSE-T processes remain after dismount
    -> /dev/rdiskN remains open
    -> physical disk cannot be ejected

backend=smb not forced
    -> dismount completes
    -> raw device is released
    -> physical disk can be ejected normally

My test patch is here:

https://github.com/mimoex/VeraCrypt/tree/fix/macos-fuset-backend-selection

Commit:

mimoex@4fddeed

Why `backend=smb` was introduced

I also looked into the history of this option.

The forced SMB backend was introduced in:

250a488

as a workaround for #1667.

In #1667, the FUSE-T auxiliary mount sometimes failed to expose:

/tmp/.veracrypt_aux_mnt1/control

and VeraCrypt consequently failed during the early mount phase.

The maintainer stated that he could not reproduce the issue on his own M1 test machine. Based on source analysis and comparison with Cryptomator's FUSE-T integration, VeraCrypt was changed from FUSE-T's default NFS backend to an explicitly forced SMB backend.

However, the original reporter later reinstalled FUSE-T using Homebrew and reported that the problem disappeared and could no longer be reproduced.

So, as far as I can tell, the underlying cause of #1667 was never conclusively established.

This makes the current behavior particularly interesting:

#1667
default NFS backend
    -> intermittent auxiliary mount/control-file failure on one system
    -> root cause not conclusively established
    -> workaround: force SMB backend

current issue
forced SMB backend
    -> FUSE session may remain alive after VeraCrypt dismount
    -> raw backing device remains open
    -> physical disk cannot be ejected

Because FUSE-T now also supports backend configuration itself, I think it may be safer for VeraCrypt not to hardcode a particular backend and instead honor FUSE-T's configured/default backend.

That would also address the FSKit-selection problem described in this issue.

Possible relation to the sleep/wake kernel panic

I also observed a repeatable sleep/wake kernel panic with the physical disk in this stale state.

The panic contains:

busy timeout[1], (60s): 'IOMediaBSDClient'

The behavior I observed was:

VeraCrypt dismount
    -> raw device still held by leaked VeraCrypt/FUSE-T processes
    -> physical disk cannot be ejected
    -> sleep
    -> wake
    -> kernel panic

As a separate test, I killed the leaked VeraCrypt processes, successfully ejected the disk, and then put the Mac to sleep.

In that case, the Mac resumed normally without the crash.

After removing the forced backend=smb option, VeraCrypt also releases the disk sufficiently for Disk Utility to eject it normally after dismount.

This does not by itself prove that the SMB backend or the leaked FUSE session is the direct cause of the kernel panic, but the persistent raw-device hold and the IOMediaBSDClient busy-timeout panic appear to be related and warrant further investigation.

@mimoex

Thank you @mimoex - fully reproduced on my system, with one variant worth
noting: my volume is device-hosted on a partition (an SD card via USB reader,
volume on /dev/rdisk4s1), and after a GUI dismount with veracrypt -t -l
reporting no volumes and mount showing nothing, the leaked processes from
two separate mount sessions all hold the slice node open:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
go-nfsv4- 1541 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
VeraCrypt 1542 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
go-nfsv4- 1587 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
VeraCrypt 1588 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1

So the leak applies to partition-hosted volumes as well as whole-disk ones.
SIGKILL on the leaked processes releases the device and the disk then ejects
normally.

This also explains a data point from my original report: I added a pre-sleep
hook that force-dismounts all volumes before every sleep, and the
IOMediaBSDClient busy-timeout panics continued anyway (e.g. hook fired 16:38,
lid wake 17:34:39, panic 17:37:11). Dismounting doesn't release the raw
device, so a dismount-based mitigation cannot work. I've now added a
kill-the-leaked-processes step to the pre-sleep hook and will report back on
whether the sleep/wake panics stop.

Environment: macOS 26.6 (25G72), MacBook Air M1, VeraCrypt 1.26.29
(FUSE-T Build), fuse-t 1.2.7.

Hello,

I found exactly the same issue, MacBook Pro M4 Pro macOS 26.6.1, my OS had a refresh on 27 June 2026, and I installed Veracrypt with fuse-t by the veracrypt-fuse-t brew package around that date.

After unmount Veracrypt each volume is keeping 2 processes alive (one parent and a child of it), even when GUI is killed, and they are dissallowing the fuse-t network share to close.

Force killing the parent Veracrypt process (the one with all the threads not just 1 threaed) does then allow for the fuse-t network share to close properly.

I also notice the go-nsfv4 processes (one per volume) and killing the parent Veracrypt process per volume (SIGKILL not SIGTERM as pointed out by you guys) is also allowing those processes to end and they disappear.

Purge of Veracrypt and Fuse-t with a reinstall does not resolve for me.

I have logged security incident in the security tab here, unsure if others also have.

Not sure why it is ignored, it is very big security issue, someone with no credentials get full access to an "unmounted" volume.

@mimoex

Follow-up with results, confirming @mimoex's analysis on my system.

Environment: macOS 26.6 (25G72), MacBook Air M1, VeraCrypt 1.26.29
(FUSE-T Build), fuse-t 1.2.7, device-hosted volume on a USB-attached SD card
(volume on the partition node, /dev/rdisk4s1).

Summary of the causal chain, now verified end to end on my machine:

After a GUI dismount, with veracrypt -t -l reporting no volumes and
mount showing nothing, leaked processes from multiple mount sessions
held the raw partition node open:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
go-nfsv4- 1541 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
VeraCrypt 1542 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
go-nfsv4- 1587 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1
VeraCrypt 1588 root 4u CHR 1,21 0t131072 725 /dev/rdisk4s1

So the leak affects partition-hosted volumes as well as the whole-disk
case @mimoex reproduced. SIGKILL on these processes releases the device
and the disk then ejects normally (SIGTERM is ignored).
Dismount alone is not a sufficient mitigation. I had a pre-sleep hook
(sleepwatcher) running veracrypt -t -d --force before every sleep, and
the panics continued anyway (example: hook fired 16:38, lid wake
17:34:39, panic 17:37:11, identical panic string:
busy timeout[1], (60s): 'IOMediaBSDClient' @IOService.cpp:5986).
This is fully consistent with the finding that the leaked processes keep
the raw device open after dismount.
I then extended the pre-sleep hook to, after a successful dismount, kill
the leaked holders:

sudo pkill -9 -f 'go-nfsv4.veracrypt_aux_mnt'
sudo pkill -9 -f 'VeraCrypt.--core-service'

In the week since, across many mount/dismount cycles and sleep/wake
cycles (lid-close and idle) with the same SD card attached, there have
been zero kernel panics. Previously the panic reproduced within minutes
of nearly every wake that followed a sleep in the stale state.

So on this system: leaked processes holding the raw device across
sleep/wake is the panic trigger, and clearing them before sleep eliminates
it. This upgrades the "possible relation to the sleep/wake kernel panic"
in the comment above to a confirmed chain, at least on this hardware.

One caution for anyone using a kill-based workaround: scope the pkill
pattern to VeraCrypt's server (the veracrypt_aux_mnt match above). An
unscoped pkill -9 -f go-nfsv4 also kills other FUSE-T applications'
servers (e.g. Cryptomator); killing one under a live mount left the
kernel smbfs client wedged badly enough on my machine to require a
reboot, with Finder hanging in uninterruptible sleep on the dead mount.

Given all this, I'd support the direction of @mimoex's patch: not
hardcoding backend=smb and honoring FUSE-T's own configured default would
both fix the dismount/leak behavior their A/B test isolated and make the
FSKit backend reachable on macOS 26+ (per my original report, the fuse-t.ini
setting is currently overridden by the hardcoded option). Happy to test a
build or provide further logs.

Same root cause, adding the confidentiality impact with a repro.

Environment: macOS 26.6.2 (25G83), VeraCrypt 1.26.29 (FUSE-T Build),
fuse-t 1.2.7, file container (not device-hosted).

Because the leaked core-service keeps the FUSE session alive, the guest
SMB share stays registered after dismount. Any stale bookmark triggers
macOS NetFS reconnect and the volume is remounted with no passphrase:

Mount, open a file from the volume in Preview.
Dismount. mount shows no smbfs entry, /Volumes is clean.
ps -> go-nfsv4 still running; lsof -> TCP 127.0.0.1:52200 (LISTEN)
Preview > Open Recent > that file
-> volume remounted, file opens, no password prompt.
SIGKILL the leaked processes -> same action fails with a fuse-t
connection error, confirming the leaked session is the access path.

So dismount does not revoke access: any local process running as the
user can cause a remount without knowing the passphrase, and the keys
remain in memory after the UI reports the volume as dismounted. This
seems worth calling out separately from the eject/panic symptoms, since
it affects the security property the dismount is supposed to provide.

@theophieln

Apologies for the delay in verifying this.

I was able to reproduce the behavior reported by @theophieln, where a previously opened file could be accessed again via the "Open Recent" feature in the "Preview" app. Using the same reproduction steps, I also tested a fix regarding the FUSE-T service lifecycle.

Reproduction with the official VeraCrypt 1.26.29 FUSE-T build

With the official VeraCrypt 1.26.29 FUSE-T build, I reproduced the issue using the following steps:

Mount a VeraCrypt volume.
Open an image from the mounted volume in "Preview," then close the image.
Unmount the volume via the VeraCrypt GUI.
Select the same image from "Preview's" "Open Recent" menu.

Performing these actions allowed access to the previous image without being prompted for the VeraCrypt password.

For comparison, I forcibly terminated any remaining VeraCrypt/FUSE-T-related processes after unmounting via the GUI but before using "Open Recent."

With the remaining processes terminated, performing the same actions did not allow access to the previous image.

These results suggest that even though the VeraCrypt GUI indicated the volume was unmounted, an old FUSE-T session persisted, allowing access to the decrypted volume to be restored through that session.

Testing with explicit FUSE-T shutdown

Next, I tested a patch that explicitly shuts down the corresponding FUSE-T service when unmounting in VeraCrypt and waits for the service process to terminate.

mimoex@000bcf4

This patch adds an authenticated shutdown endpoint to the auxiliary FUSE file system. Upon unmounting, the system now requests the corresponding service instance to shut down and waits for the FUSE service to actually terminate before completing the teardown process.

Using this build, I repeated the same test involving "Preview" as before.

After unmounting, it is no longer possible to access the previously opened image via the old entries remaining in "Preview."

Revision of Previous Hypothesis

With the previous patch, stopping the forced use of the SMB backend eliminated the session leak (a phenomenon where related processes persist) in my environment. Consequently, I initially suspected that forcing backend=smb was the primary cause.

However, with this new patch—despite continuing to use the SMB backend—explicitly shutting down the FUSE-T service successfully prevented the issue where previous files could be accessed via "Preview's" "Open Recent" list.

Therefore, I believe the root cause likely lies not in the SMB backend itself, but in the fact that the lifecycle of the auxiliary FUSE-T service continued even after unmounting.

I consider the most reliable fix to be ensuring that VeraCrypt does not treat the unmount process as complete until the corresponding auxiliary FUSE-T service has actually terminated and fully released access to the decrypted volume.

@mimoex

Status summary for anyone triaging, since this thread has moved a lot since
the original report:

Root cause, revised: per @mimoex's later testing, the confirmed defect is
that the auxiliary FUSE-T service outlives the dismount. The earlier
"forced backend=smb" theory has been superseded: a patch that keeps SMB but
explicitly shuts the service down on dismount and waits for it to exit
(macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866) fixes the behavior.
Security impact, reproduced twice on the official 1.26.29 FUSE-T build:
after a normal dismount, the leaked session still serves the decrypted
volume, and macOS Open Recent remounts it and opens a file with no
passphrase prompt (@theophieln, confirmed by @mimoex). Since that repro is
public here, dismount-does-not-revoke-access should be treated as
disclosed.
Also reproduced: raw device held open after dismount (whole-disk and
partition-hosted), device not ejectable until the leaked processes are
killed, and a repeatable sleep/wake kernel panic (IOMediaBSDClient busy
timeout) that stopped entirely once the leaked processes are killed before
sleep. The cross-reference from TimeOut at VeraCrypt::FuseService::Mount:727 #1785 suggests the mount timeouts there
may be a downstream effect of stale auxiliary servers; worth checking.
At least two of us have filed reports through the Security tab; mine is
GHSA-f3px-f8h2-fm4c.

@idrassi when you're back, could you triage the advisory and review #1866?
I can test candidate builds on macOS 26.6 / Apple Silicon (M1) with both file
containers and a device-hosted volume.

At least two of us have filed reports through the Security tab; mine is
GHSA-f3px-f8h2-fm4c.

Mine is GHSA-3p8m-hrc7-cw3h

It is concerning that such a security issue is left to fester.

@idrassi

Where this stands, what FUSE-T users should do, and requests for @idrassi

Several people are watching this issue and waiting, so here is the picture
in one place, including history this thread was missing until yesterday.
The full timeline is collapsed at the bottom; credit to everyone named in
it, this has been collective work.

Where this stands

This vulnerability was first reported publicly in #1779 around June 16
(Christian-SC26), and independently on the SourceForge forum on June 22
(Stephan Weisgerber), who first identified the surviving go-nfsv4 and
VeraCrypt background processes as the cause. @idrassi acknowledged it on
both channels around June 26-27, diagnosed the mechanism (the FUSE-T
auxiliary mount exposing volume.dmg survives the GUI dismount, so the
decrypted block device can be reattached without credentials), called it
serious, and described the intended fix: verify that the auxiliary mount and
helper processes are actually gone before treating a dismount as
successful. PR #1866 (@mimoex) implements essentially that approach.

Since then it has been independently reproduced by [five / six] people on
the official 1.26.29 FUSE-T build , including me, across file containers,
partition-hosted volumes, and whole-disk volumes. There is no patch
release, no CVE, no published advisory, and as far as I can see no warning
on the download page, so FUSE-T users continue to install a build whose
dismount does not revoke access to the decrypted volume. #1845 and both
private advisories (GHSA-f3px-f8h2-fm4c, mine, and GHSA-3p8m-hrc7-cw3h,
@techfoxactual's) are duplicates of #1779.

What FUSE-T users should do right now

The maintainer's own recommendation: switch to the macFUSE build of
VeraCrypt, which Christian-SC26 confirmed is unaffected. On Apple Silicon
this requires enabling third-party kernel extensions in Recovery
(Reduced Security), a real trade-off, but it is the configuration the
maintainer considers robust.
If you stay on FUSE-T: after every dismount, and only when no volumes
are mounted, verify and kill the leaked processes (the workaround
Stephan Weisgerber identified in June), because dismount alone does not
release the volume:
```
ps aux | grep -E 'go-nfsv4|core-service' | grep -v grep
sudo pkill -9 -f 'go-nfsv4.*veracrypt_aux_mnt'
sudo pkill -9 -f 'VeraCrypt.*--core-service'
```
Scope the first pattern exactly as shown; an unscoped pkill -f go-nfsv4
also kills other FUSE-T apps' servers (e.g. Cryptomator) and can wedge
the kernel smbfs client under a live mount. If you use removable media,
run this before sleeping the machine to avoid the kernel panic.
Treat a volume as unlocked until those processes are gone. Note that in
Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779, Christian-SC26 reported access persisting until a reboot even
after the processes appeared to be gone (the process check used there
may have been incomplete, but the safe reading is that a reboot is the
only fully verified lockdown). If in doubt, reboot.

Requests for @idrassi

I want to be careful about tone, because what you described in June is
real: this project runs on your unpaid time, and the people in this thread
are among the many who depend on it. But this is disk encryption software,
the defect defeats its core security promise on one platform, it has been
public for three months, and the fix you described in #1779 has now been
implemented in #1866. I think that combination obligates the following,
and I'd ask for them in this order:

An acknowledgment, ideally by September 30: a comment here and on
the two advisories confirming you've seen them, even if the substance is
"reviewing macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866, no ETA yet."
An interim notice, before any code work: a pinned issue here, a line
on the macOS download page, or a note on veracrypt.fr telling FUSE-T
users that dismount currently does not revoke access, and pointing them
to the macFUSE build or the process cleanup above. This protects users
who will never find this thread.
A review of macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866, and either a merge or a specific statement of
what's wrong with it. I will test any build you produce on Apple Silicon
with file and partition-hosted volumes, and others in this thread have
offered to as well.
Triage of the advisories: merge GHSA-3p8m-hrc7-cw3h and
GHSA-f3px-f8h2-fm4c, set the affected version (1.26.29 FUSE-T build),
and request a CVE through GitHub's CNA so the issue enters vulnerability
databases and Homebrew users are notified. I've set out a disclosure
timeline in the advisory.
A point release for the macOS FUSE-T build once macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866 (or your own
fix) is verified, rather than holding it for the next feature release.

Thank you for VeraCrypt. This thread is long because people care about it.

Full timeline, June to September 2026

~June 16: Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779 opened (Christian-SC26), titled by the reporter
"Critical Security Flaw: Unmounted volume automatically remounts without
credentials..." Relaunching UTM after a dismount brought the encrypted
volume back with full read/write access and no password prompt.
~June 22-24: Independent SourceForge report (Stephan Weisgerber),
"1.26.29 VeraCrypt Mounts Without Password (macOS)": TextEdit's
recent-files list remounted a dismounted volume with no password. He
traced it to go-nfsv4 and a VeraCrypt background process surviving
dismount, and showed that killing go-nfsv4 (SIGKILL required) made the
reopen fail. The first working diagnosis of this bug.
~June 26-27: @idrassi replied on Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779 and SourceForge with the
diagnosis and intended fix described above, and recommended the macFUSE
build as interim mitigation (Christian-SC26 confirmed it is unaffected).
He also explained that his time on VeraCrypt is constrained by paid work.
July 15: Most recent maintainer activity I can find on GitHub (a
merged translation PR). Most recent SourceForge activity: June 27.
August 1: This issue opened (process leak after dismount, stale
Bonjour/Finder entries, hardcoded SMB backend, sleep/wake kernel panic).
Nobody here, including me, had found Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779 or the SourceForge thread.
August 10: @mimoex reproduced the leak, showed with lsof that the
leaked processes hold the raw device open, traced the forced backend=smb
to commit 250a488 (a workaround for [macOS / Apple Silicon] FUSE-T version fails with "no such file in directory /tmp/.veracrypt_aux_mnt1/control VeraCrypt::FilesystemPath::GetType:48" #1667 whose root cause was never
established), and showed that a build without the forced backend releases
the device.
Mid-August: I reproduced the device hold on a partition-hosted
volume. @techfoxactual reproduced on an M4 Pro and filed a private
security report. I confirmed the kernel panic chain: leaked processes
holding the raw device across sleep/wake cause the IOMediaBSDClient
busy-timeout panic, and killing them before sleep eliminated it.
~August 20: @theophieln posted the confidentiality repro in this
thread (Open Recent remounts the volume with no passphrase; the kill test
confirms the leaked session is the access path). Advisories
GHSA-f3px-f8h2-fm4c (mine) and GHSA-3p8m-hrc7-cw3h (@techfoxactual) filed.
Late August: @mimoex reproduced the Open Recent access on the official
1.26.29 build, then built a patch that explicitly shuts down the auxiliary
FUSE-T service on dismount and waits for it to exit. It closes the access
path while keeping the SMB backend, showing the root cause is the service
lifecycle, not the backend. Opened as PR macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866.
Early September: @rmuit cross-referenced this thread from TimeOut at VeraCrypt::FuseService::Mount:727 #1785; the
mount timeouts reported there may be a downstream effect of stale
auxiliary servers.
September 23: No maintainer response on this issue, on macOS/FUSE-T: Terminate auxiliary FUSE service on dismount #1866, or on
either advisory. The advisories have been in Triage for about five weeks.
Criticalic Security Flaw: Unmounted volume automatally remounts without credentials upon launching UTM Virtual Machine on macOS 26.5.1+ (Apple Silicon) #1779 has been open for over three months with the fix acknowledged but
not delivered.

Scope the first pattern exactly as shown; an unscoped pkill -f go-nfsv4 also kills other FUSE-T apps' servers (e.g. Cryptomator) and can wedge the kernel smbfs client under a live mount.

Or use the following (script, or maybe you can wrangle it into a long alias...) which you can run at any time.

#!/bin/sh
ps ax | grep -F /go-nfsv4 | grep -v grep | \
sed  -e 's/^ *\([0-9]*\).*--backend smb \(.*\)$/\1 \2/' | \
while read -r pid file; do
  if [ -e "$file" ] ; then
    echo $file exists, leaving process $pid alone
  else
    echo $file is gone, killing process $pid; kill -9 $pid
  fi
done

(This assumes the Veracrypt processes go away when go-nfsv4 are killed. For me, that was the case.)

@idrassi

At my submission, MITRE has assigned and published CVE-2026-108982
for this vulnerability:vhttps://www.cve.org/CVERecord?id=CVE-2026-108982

First, this is not a judgment on @idrassi, and I'd ask that nobody read it
as one. VeraCrypt is one person's unpaid work, maintained for over a decade
in the time left over from his actual work that actually pays him, and this year
on top of a signing-account crisis that wasn't his fault. Everyone in this
thread depends on that work to protect things that matter to them, and
most of us never think about what it costs him. A bug that waited a few
months is what happens when critical software rests on a single volunteer
and the rest of us take that for granted. If this thread prompts any action
beyond patching, I'd suggest it be a donation:
https://veracrypt.jp/en/Donation.html

I filed the CVE because the vulnerability has been public since June, it
defeats the core promise of the software on one platform, and the people
installing the FUSE-T build today had no way to find out. A CVE is how they
find out. I also tried to make it useful to the maintainer rather than a
burden: it credits the original reporters, it points at the fix he himself
described and that @mimoex implemented in #1866, and it can be attached
directly to the GitHub advisory when he publishes it, so nothing needs to
be redone. Whatever makes the fix easier from here, I'm glad to help with.

The record: CWE-459, CVSS 4.0 7.2 High, affected: VeraCrypt 1.26.29
FUSE-T build on macOS; macFUSE build unaffected. References #1779, the
SourceForge thread, this issue, and #1866 as the available fix. CVE records
don't carry credits, so for the record: the finding and analysis belong to
@Christian-SC26 (#1779), Stephan Weisgerber (SourceForge), @mimoex
(#1866), @theophieln, @techfoxactual, and myself.

For FUSE-T users: the interim guidance in my September 23 comment
stands: use the macFUSE build, or clear the leaked processes after every
dismount, and treat a volume as unlocked until they're gone. For the
cleanup, the script @rmuit posted above is a better tool than my
blanket pkill: it kills only go-nfsv4 instances whose mountpoint no
longer exists, so live mounts from other FUSE-T apps are untouched, and
killing the server (rather than the VeraCrypt helper) lets VeraCrypt's own
FUSE teardown path run. Two notes: run it with sudo, since VeraCrypt's
servers are root-owned, and it keys on the --backend smb argument, so a
server launched without that flag won't parse and would be killed
regardless. A variant that handles both is below. Either way, verify once
on your own machine with sudo lsof -nP /dev/rdiskNsM after running it
that nothing still holds the raw device.

Hardened variant of the cleanup script

#!/bin/sh
# Kill fuse-t servers whose mountpoint has disappeared (leaked after dismount).
# Run with sudo. Leaves servers with a live mountpoint alone.
ps -axo pid=,command= | grep -F '/go-nfsv4' | grep -v grep |
while read -r pid cmd; do
  case "$cmd" in
    *"--backend "*) mnt=$(printf '%s' "$cmd" | sed -e 's/^.*--backend [a-z]* //') ;;
    *) echo "skipping $pid (no --backend argument, cannot determine mountpoint)"; continue ;;
  esac
  if [ -e "$mnt" ]; then
    echo "$mnt exists, leaving process $pid alone"
  else
    echo "$mnt is gone, killing process $pid"; kill -9 "$pid"
  fi
done

@idrassi, whenever you're back: #1866 is ready for review, and several of
us will test any build you produce.

@morin-andrew

@morin-andrew #1866 was merged in 2 weeks ago, stop hallucinating

@Wilkolicious

No hallucination, @Wilkolicious, just a lack of any kind of response on the threads
where this was reported. However, I should have been more diligent about keeping up
with the other threads: #1866 was merged on September 25 (d7bc65b),
and @idrassi followed it with a solid run of FUSE-T teardown hardening on
September 26-28 (1b9be65, ff81ade, aedb2ef, 596beb8, 83cb247, 41bc8e5).
Credit to @mimoex and @idrassi for that; it's the outcome this thread was
asking for.

There's still no point release, so 1.26.29 is what everyone installs today,
and the CVE is the only thing that tells them. I'm updating the record to
point at the merged fix and will add the version number when a release
ships. Until then: macFUSE build, or clear the leaked processes after each
dismount.

18. @morin-andrew #1866 was merged in 2 weeks ago, stop hallucinating

I like it when person with no contribution to the long comments issue comes to insult one who does lots of things to help others. Maybe next time just add comment 2 weeks ago about merge. Don't need insults from non-contributor. I too am waiting on fix.

Navigation Menu

Repository navigation

macOS: core-service + fuse-t server processes persist after dismount (stale Bonjour/Finder entries); fuse-t backend hardcoded to SMB, FSKit unusable #1845

Environment

What happens after VeraCrypt dismount

The leaked VeraCrypt process is still inside `fuse_main()`

A/B test: removing only the forced SMB backend

Why `backend=smb` was introduced

Possible relation to the sleep/wake kernel panic

Reproduction with the official VeraCrypt 1.26.29 FUSE-T build

Testing with explicit FUSE-T shutdown

Revision of Previous Hypothesis

Where this stands, what FUSE-T users should do, and requests for @idrassi

Where this stands

What FUSE-T users should do right now

Requests for @idrassi

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

macOS: core-service + fuse-t server processes persist after dismount (stale Bonjour/Finder entries); fuse-t backend hardcoded to SMB, FSKit unusable #1845

Description

Activity

mimoex commented on Aug 11, 2026

Environment

What happens after VeraCrypt dismount

The leaked VeraCrypt process is still inside fuse_main()

A/B test: removing only the forced SMB backend

Why backend=smb was introduced

Possible relation to the sleep/wake kernel panic

morin-andrew commented on Aug 14, 2026

techfoxactual commented on Aug 16, 2026

techfoxactual commented on Aug 21, 2026

morin-andrew commented on Aug 22, 2026

theophieln commented on Aug 23, 2026

mimoex commented on Aug 28, 2026

Reproduction with the official VeraCrypt 1.26.29 FUSE-T build

Testing with explicit FUSE-T shutdown

Revision of Previous Hypothesis

morin-andrew commented on Sep 11, 2026

techfoxactual commented on Sep 11, 2026

techfoxactual commented on Sep 22, 2026

morin-andrew commented on Sep 23, 2026

Where this stands, what FUSE-T users should do, and requests for @idrassi

Where this stands

What FUSE-T users should do right now

Requests for @idrassi

rmuit commented on Oct 10, 2026

morin-andrew commented on Oct 12, 2026

Wilkolicious commented on Oct 12, 2026

morin-andrew commented on Oct 12, 2026

persimon-cme commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

The leaked VeraCrypt process is still inside `fuse_main()`

Why `backend=smb` was introduced