WSL ships with convenient defaults: Windows drives are mounted under /mnt, Linux can launch Windows programs, and Windows PATH entries are added. Each convenience widens what a compromised Linux process can reach. The wsl.conf and .wslconfig files let you narrow that where your work allows.
Two files, two scopes
Per Microsoft's configuration page, wsl.conf applies per distribution and lives at /etc/wsl.conf inside it. The .wslconfig file applies globally to all WSL 2 distributions and lives in your Windows user profile folder. The .wslconfig file does not exist by default, and it affects only WSL 2.
Changes only take effect after WSL fully stops and restarts. Microsoft calls this the 8 second rule. The command wsl.exe with the shutdown option is the fast path, and it stops all running distributions.
For what WSL 2 isolates and shares in general, see /resources/blog/wsl2-isolation-what-it-isolates-and-what-it-shares.
Settings to review in wsl.conf
Automount: by default, fixed Windows drives mount through DrvFs under /mnt, so your C drive is at /mnt/c. That means a Linux process can read and write your Windows files, subject to Windows permissions of the signed in user. The enabled key can turn automounting off, and you can mount only what you need through fstab. Options such as umask, fmask and dmask exist, but the page notes they only apply when the drive is mounted with metadata, which is off by default.
Interop: two keys, both true by default. The enabled key controls whether WSL can launch Windows processes. The appendWindowsPath key controls whether Windows path elements are added to the Linux PATH. Microsoft's example sets both to false, which blocks launching Windows processes and blocks adding those PATH entries.
Why that matters: with interop on, a script running in Linux can call a Windows executable. With the Windows PATH appended, a binary named like a common Linux tool can be picked up from a Windows folder. Turning both off is a sound default for a distribution used only for Linux builds.
Boot: the boot section can run a command as root when the instance starts, and can enable systemd. Anything placed in the boot command runs with root rights on every start, so review who can edit that file.
Network: the generateHosts and generateResolvConf keys control whether WSL writes the hosts and DNS configuration files. Turning them off means you maintain those files yourself.
An example that tightens a build only distribution:
[automount]
enabled=false
[interop]
enabled=false
appendWindowsPath=false
Settings to review in .wslconfig
Networking mode: the default is NAT, with mirrored, none and others available. A value of none disconnects the WSL network. The firewall key, true by default on supported builds, lets Windows Firewall and Hyper-V rules filter WSL traffic. Leave it on.
Localhost forwarding is true by default, so ports bound inside the WSL 2 VM are reachable from Windows through localhost. A dev server bound to all interfaces inside WSL is therefore reachable from the host, and in some network modes from the network, so check what you bind.
Other keys, such as a custom kernel path and nested virtualization, change the trust base of the VM. Only set a kernel you built or can verify.
Practical rules
- Use separate distributions for separate trust levels, for example one for client work and one for experiments with unknown code.
- Turn off interop and PATH sharing on distributions that handle untrusted code.
- Keep secrets out of the Windows drive mounts, since Linux processes can read them.
- Keep WSL itself updated through the Store version, so fixes arrive.
Safeguard has a command line scanner that installs on Linux with a curl installer, so you can scan dependencies inside a WSL distribution the same way as anywhere else. Read the installer before you run it.
Quick check
Where do I put per-distribution WSL settings?
In /etc/wsl.conf inside that distribution. Global WSL 2 settings go in the .wslconfig file in your Windows user profile.
How do I stop Linux from launching Windows programs?
Set enabled to false under the interop section of wsl.conf, then shut WSL down and restart it. Setting appendWindowsPath to false also removes Windows folders from PATH.
Sources
Last reviewed: 19 October 2026.
