Allow to disable security.allowedUNCHosts

[weed-]

The new "security.allowedUNCHosts" in 1.78.1 setting breaks our workflow. We edit a lot of files on a lot of UNC hosts (around ~3k hosts per user, many users). How can the feature be disabled or all/regex hosts be allowed?

Alternatively, we could try to add all our UNC hosts. The list ist around 5mb (now) and changes on a hourly basis - editing this manually is nonsense, but neither security.allowedUNCHosts nor NODE_UNC_HOST_ALLOWLIST allows for centralized (and realtime) management.

Using a match pattern like \10.2.. or \(.).*.example.com would be our preferred method.

[bpasero]

We currently do not support glob patterns for UNC paths, specifically because of the security attack: every UNC host name must be added individually and explicitly. Every UNC path that is allowed exposes a risk of disclosing information as outlined by GHSA-mmfh-4pv3-39hr

[asherjvitek]

The current state of this is completely unmaintainable. Having to enter every single server to browse to is not realistic. I use VS Code multiple times a day to open to files on servers.

There should be a way to either provide a wildcard or disable this allowing people to accept the risk.

[FVolral]

For those unable to view the content of their folder in \\wsl$ . In JSON settings, I added :

"security.allowedUNCHosts": ["wsl$"],

This can be found in the following link: https://code.visualstudio.com/docs/setup/windows#_working-with-unc-paths.

After rebooting VSCode, the changes will take effect and the folder's content will be viewable again.

[Andy78DE]

I second @weed- 's comment. I have the same problem here.
Also, I tried to list the most used servers and IP addresses, but I still get the warning when opening a file. Is there a special format for the entries? Couldn't find any examples.
My settings file looks like this:
"security.allowedUNCHosts": [ "ABC", "10.1.2.3", "DEF" ]

EDIT:
Got it: I put server names like "ABC" (upper-case) into settings, but it seems it has to be like "abc" (lower-case) 🤦🏼‍♂️
Still just a temporary workaround...

[weed-]

@bpasero is right and we do understand the risk of this Information Disclosure Vulnerability. UNC retrieval and meta data access (... NTLM delegation ...) is a hot mess in Windows anyway.

We need a way to be able to "willingly accept this risk". In a closed environment like ours (telko stuff) the risk is more a theoretical one anyway. So a "disable" setting or "enable glob patterns", if global matching is "not enough", would be extremely helpful.

[jdonaldson-Lamar]

I am going to stop using VS Code if this issue is not resolved.

[marguz-wag]

Hello,

I did have a question here as to why the environment variable did not work "NODE_UNC_HOST_ALLOWLIST", but after making sure all running "Code.exe" process were killed, it worked.

So I guess, also make sure there are no running "Code.exe" process while one is making these changes to test.

So far.. all good now.

[jgilfoil]

I didn't really want to start a new issue just for this comment, but this really just breaks the WSL integration experience. I develop from my Windows OS on files inside my WSL2 VM. Previously, the experience was seamless in being able to open files from the WSL2 environment. Now instead of working by default, I have to allow wsl.localhost? That seems like an unnecessary security impediment for very little security gain. Please add wsl.localhost to the allowed list by default.

[sap2me]

this update broke everything

[FlushingBaseball]

This is absurd and completely broke our workflow, Microsoft you need to be better.

[SuperBartimus]

At the minimum, It would be good to see this as a button prompt like you get for specific workspaces. A button to Trust the location. Which, isn't that really the same thing?

[ThiconZ]

This has completely broken our workflow and required us to make an emergency change to another editor to continue working. While we would love to continue using VS Code, we cannot return to using it until something is changed with this implementation.

Ideally the option to disable this would work best, perhaps even an opt-in/out on first launch, but other means to mitigate it would be welcome in the short term at least. Seeing as this breaking change was implemented quickly, an update to the behavior can come just as swiftly.

[rwalle]

Not exactly related to the topic, but I think in any case this change regarding UNC path issue should be very carefully designed and visibly announced and notified to end users. I just spent an hour figuring out why many extensions that are critical to my workflow stopped working, including the built-in TypeScript language service (it keeps crashing). Turns out these extensions cannot access any UNC path in any way (whether introduced by user configuration, or because the text file itself is actually using UNC path). I only accidentally discovered the cause when I tried to explicitly open a text file on a UNC path and saw an "allowed host" warning and was able to track it down.

Even though there is a page that explains the issue, that is far from complete -- after adding our "main" host to the allowed host list, the TS server still keeps crashing, and there is nothing in the TS server log that says anything. I ended up finding that TS server tries to use the "real path" (also mentioned in #182196) for some files which end up having a hostname different from the "main" one. This is a hostname that user never directly interacts with on the daily basis. I got it from the console of developer tools by using "Toggle Developer Tools" (and alternatively log of "Extension Host" in "Output" window), and did it only because I had some experience there. Do you expect every developer to do this?

I consider myself an expert VSCode user and developer (I have explored a lot of the codebase, written several VSCode extensions and language clients/servers and have done a ton of customization), and if it takes me an hour to understand what is happening to resolve all the issues, it will only take other people a much longer time to figure this out.

[bramdier]

for those of you. still get message error. try to open your setting.json file from visual studio code. after that add code like this

"security.allowedUNCHosts": ["Kbgatewaytest$", "Kbdev$"]

for example i have two diffrent path:

1. Kbgatewaytest
2. Kbdev
   add symbol $ in the end of that path. after that save it.

[bramdier]

I second @weed- 's comment. I have the same problem here. Also, I tried to list the most used servers and IP addresses, but I still get the warning when opening a file. Is there a special format for the entries? Couldn't find any examples. My settings file looks like this: "security.allowedUNCHosts": [ "ABC", "10.1.2.3", "DEF" ]

EDIT: Got it: I put server names like "ABC" (upper-case) into settings, but it seems it has to be like "abc" (lower-case) 🤦🏼‍♂️ Still just a temporary workaround...

"security.allowedUNCHosts": ["ABC$", "DEF$"]

[AmansRevenger]

I am connecting remotly by default to //GIOVANNI but it still wont work even with the setting set on both ends (local VSCode and remote settings.json)

What am I doing wrong?

[rwalle]

Does GIOVANNI without the dollar sign work?

[AmansRevenger]

No it does not. Do i need to add something else like my local domain (fritz.box) or something? I also dont know how to access VSCode logs ...

[fozi]

This "fix" just complicated me life way too much. (and my coworkers)

Not the best solution. But it worked for us.

Roll back to 1.77.3, disable auto update and wait for MS to give us a working solution.

[Nick-HK]

Guess you will need a local mapping to the drive first to access to remote file server..

[bpasero]

We will push a change to disable UNC access restrictions. This will be behind a setting and/or a new environment variable.

[bencfreeman]

I'd love to see how many hits the 1.78.0 download link has gotten in the last 24 hours compared to a few weeks ago. This breaks our workflow as well since a lot of our code is on SMB file servers. Will be using 1.78 until this update gets pushed and documented.

[jdonaldson-Lamar]

Does anyone know if 1.78.2 fixed this issue or is it randomly happening to users? I have a Co-Worker using 1.78.2 and he can open files from the server with no issues. I am still on 1.77 and do not want to deal with the hassle of uninstalling 1.78.2 if the issues still persist for some users.

[marguz-wag]

1.78.2 does not "fix" the issue.

I do agree that the user should be given a button or something to opt-out of UNC security fix and accept "risk".

[Nick-HK]

I noticed that 1.78.2 do have a boolean configuration (security.restrictUNCAccess) to disable the UNCAccess

This issue can be closed then.

[bpasero]

We still need an upstream change before this will work. We plan for having it for our next stable release early June.

[ThiconZ]

I find it concerning that it is going to take so long for a proper fix for this issue to be implemented and make its way into the live environment. Though even the current changes appears to be only a half measure and not a true proper fix. After the relatively short turnaround time for a massive breaking change to have been implemented and pushed live, I would have hoped for a faster resolution here.

Being able to open a UNC path file is a basic feature that any file editor from Visual Studio down to even basic Notepad supports out of the box, but now VS Code seemingly can't support that by default? To me at least, it seems baffling that VS Code will not be able to do this anymore as the previously mentioned change will also still default to UNC being blocked.

This type of sudden breaking change with no warning has unfortunately eroded a significant amount of confidence we once had in VS Code for being a primary tool in our workflows.

[bpasero]

@ThiconZ the change for blocking UNC paths in VS Code is a response to a severe security vulnerability and was done after careful and long discussions in our team. Please see GHSA-mmfh-4pv3-39hr for more information.

[bencfreeman]

I just read the information disclosure vulnerability. If I understand correctly, one of my servers would have to be compromised, plus I would have to download and run an unknown/malicious EXE from one of my shares for this to be a thing. We are developers, and we're not careless enough not to run a random EXE that we don't recognize or trust. Not running an unknown application should be part of Internet common sense 101. If one of my servers are compromised I've got way bigger problems on my hands than whether or not VS Code will allow me to connect to my SMB shares. Come on guys, just remove this feature. Or at least show the user a dialog to let them decide whether or not they want you to hold their hand.

[jdonaldson-Lamar]

@bencfreeman I was thinking the exact same thing. We have an entire team devoted to security and servers. If there is something malicious on our servers we have much bigger problems than VS code. I can still open up files on my server with The Enterprise Version of Visual Studio. How come Visual Studio allows it but not VS Code? I can do way more Damage with Visual Studio than VS Code. This seems like a knee jerk reaction with VS Code.

[bpasero]

The fix for this change will go out at the end of this week in our insiders build [1] and early June in stable build.

A new setting security.restrictUNCAccess can be used to disable the UNC access checks.

[1] Insiders builds normally release every day but are currently on-hold given the MSBuild conference that takes place.

[XanderCyberLab]

allowedUNCHosts
It was solved with this:

1. Ctrl + Shift + p
2. Open settings (UI)
3. allowedUNCHosts
4. Add item
5. wsl.localhost
6. OK
7. restart

I hope you can solve your problem!

Thank you. This worked great.

[fmillion-mnsu]

Many settings in VS Code take effect immediately. Why do you have to restart (closing everything you already have open - remote connections, debug sessions...) in order to add a server to the allow list?

[isaacolsen94]

This setting is driving me crazy! Let us disable it please.

[isaacolsen94]

This "fix" just complicated me life way too much. (and my coworkers)

Not the best solution. But it worked for us.

Roll back to 1.77.3, disable auto update and wait for MS to give us a working solution.

Thank you this saved me tonight trying to find which version I had to go back to.

[Tzwcard]

It's already June, when will the update roll out?
I don't want to click "Yes" tens of times whenever I start VSCode anymore
Or anyone has suggestions of better tools that won't just break your workflow without any warning like this?

[bencfreeman]

Looks like the UNC security stuff is still enabled by default in 1.79.0. You'll have to manually go to settings on every VS Code install that you use and turn it off. I prefer VS Code's log file syntax highlighting over other text editors, and I have it installed on a bunch of machines just to view log files. 99% of the files we work with are on SMB shares. It's frustrating but at least we can disable the setting now. Find the "Security: Restrict UNCAccess" setting and uncheck it. And of course restart VS Code. Reminds me of the days of Win95 when you had to restart the whole machine every time you changed a setting. I hope future VS Code updates don't reset it back to default.

[dfloer]

Still broken in 1.79.1, neither setting "security.restrictUNCAccess": false or adding hostnames/IP addresses to "security.allowedUNCHosts" works.

It seems like having a working way to add allowed hosts should have been a pre-requisite to disabling UNC, even if it's a critical security issue, not being able to use VSCode with any UNC paths is also a big issue.

Edit: I have restarted several times, and tried various combinations of case for the hostnames, as well as adding $, etc.