error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc

[Aaron-Junker]

Describe the bug

Every project I tried to build using the current Visual Studio Preview version throws this error. System.Private.Uri is not a directly included project. I also tried clearing all nuget data, but it didn't help. In the stable Visual Studio version it works.

To Reproduce

1. Create a new c# project of any kind (.net 8)
2. Try to build it
3. It fails

Exceptions (if any)

1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848
1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1902: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g
1>K:\PowerToys\src\modules\FileActionsMenu\FileActionsMenu.Helpers\FileActionsMenu.Helpers.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc

Further technical details

• Dotnet --info output:

.NET SDK:
 Version:           8.0.303
 Commit:            29ab8e3268
 Workload version:  8.0.300-manifests.c915c39d
 MSBuild version:   17.10.4+10fbfbf2e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26257
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Users\aaron\AppData\Local\Microsoft\dotnet\sdk\8.0.303\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      8.0.7
  Architecture: x64
  Commit:       2aade6beb0

.NET SDKs installed:
  8.0.303 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.7 [C:\Users\aaron\AppData\Local\Microsoft\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

• Visual Studio 17.11 Preview 7.0

[martincostello]

This is due to changes to NuGet: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

The package will be a transient dependency of something in your dependency graph.

Using the .NET 9 preview 6 SDK you can use the new dotnet nuget why command to find its origin.

[Aaron-Junker]

This is due to changes to NuGet: https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/

The package will be a transient dependency of something in your dependency graph.

Using the .NET 9 preview 6 SDK you can use the new dotnet nuget why command to find its origin.

This does not work it just says Project '...' does not have a dependency on 'System.Private.Uri'.

[martincostello]

That's a different issue then if dotnet nuget why isn't finding it in the graph.

It will be a dependency of something in your dependency graph - trivy scan found it in various container images of mine prior to the NuGet updates, which I had to fix (e.g. martincostello/api@ff08bd2).

You can try looking in the .deps.json file of your published project to find what dependency is bringing it in.

[marcpopMSFT]

@aortiz-msft @JonDouglas for why dotnet nuget why didn't find the dependency. Should we ask the customer to file this in the nuget repo instead?
@richlander @agocke for guidance on how to track these down. In this case, I'd look in the deps.json file or the project.assets.json file looking for System.Private.Uri and try to trace back it's dependency tree.

[aortiz-msft]

@aortiz-msft @JonDouglas for why dotnet nuget why didn't find the dependency. Should we ask the customer to file this in the nuget repo instead?

Yes please.

[DanTravison]

IMHO: The tooling for this needs work!

Last night I upgraded VS Enterprise to 17.11.0 and VS Community Preview to 17.12.0 Preview 1.0 and hit this on the first Maui application I built.

I ended up running dotnet restore against a number of my solutions to find it impacted most of my Maui applications.

At first, I thought I needed to add a PackageReference to each application project to resolve it. In the end, the suggestion to search project.assets.json finally narrowed it down to one of my shared assembly's.

What I didn't see was the error for the shared assembly that was the root cause of the problem.

To me, there are two bugs:
1: dotnet restore should report the security vulnerability for the shared assembly.
2: the build should have an option to fail on security vulnerabilities. My builds succeeded.

Thanks.

[aortiz-msft]

@DanTravison - Thank you for the feedback!

For the first issue, would you mind opening an issue at https://github.com/NuGet/Home/issues/new/choose with reproducible steps? We'd be happy to take a look!

For the second issue, you can configure the SDK to treat all or certain warnings as errors: https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings. If you feel that the default for vulnerabilities should be error, let us know that too.

cc @zivkan

[DanTravison]

For the first issue, I created NuGet/Home#13708

For the second issue, I cannot get the build to fail for the vulnerability issue.

I've tried WarningsAsErrors, with Warning Level 1, 7, and All Warnings and don't see the warning promoted to an error.
VS is using Nuget 6.11.0.

Here's an example output I'm expecting to see promoted:
1>C:\git\travison\Maui.Core\Maui.Core\Maui.Core.csproj : warning NU1900: Error occurred while getting package vulnerability data: Unable to load the service index for source https://api.nuget.org/v3/index.json.
1>Done building project "Maui.Core.csproj".

As far as considering this an error, personally, I would prefer that so I don't have to change every project to enforce it.
I do expect others to disagree, though.

Is there any way to configure this system-wide instead of per-project?

[martincostello]

You could set TreatWarningsAsErrors=true as an environment variable, then it should be picked up by every build and cause the build to fail if there are vulnerable packages.

I set TreatWarningsAsErrors=true in Directory.Build.props in the root of each of my repos, and when the vulnerability in the System.Text.Json prior to 8.0.4 package was published a lot of my builds broke and I had to update it to fix them.

[zivkan]

For the second issue, I cannot get the build to fail for the vulnerability issue.

My guess is that you're using nuget.exe to restore the project. I'm not sure that NuGet.exe supports WarningsAsErrors and TreatWarningsAsErrors. You should use dotnet restore instead. If you have any projects in the solution that can't be restored & built with dotnet, then use msbuild -t:restore. If you have any old projects still using packages.config, use msbuild -t:restore -p:RestorePackagesConfig=true. NuGet.exe is an "old" way of doing things, since before PackageReference was added in 2016 (although restoring packages.config projects via msbuild was implemented months/years later)

However, if you are using dotnet restore or msbuild -t:restore, then it should work, and we'll need more details (preferably a sample solution with a sample command line) to investigate.

[DanTravison]

I am building in Visual Studio (Ent) 17.11.0 and the above warning was from the VS Output window.

Unfortunately, now I can't even get the warning to appear in the VS build output.

I typically run dotnet restore when I change NuGet dependencies because I find restore is unreliable when run as part of the VS build. In fact, I don't even see a warning when I remove the workaround from the shared assembly, clean the solution, and rebuild the solution in VS. The build output shows dotnet restore being run for each project with no warnings and the build completes even though project.assets.json for the Maui application references "System.Private.Uri": "4.3.0"

In comparison, if I clean the solution and run the command-line dotnet restore from the solution directory, I see three warnings for the application project both before and after building in VS.

PS C:\git\travison\Maui.Core> dotnet restore
Restore succeeded with 3 warning(s) in 11.8s
warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, GHSA-5f2m-466j-3848
warning NU1902: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, GHSA-x5qj-9vmx-7g6g
warning NU1903: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, GHSA-xhfc-gr8f-ffwc

[ProbablePrime]

I am also experiencing this.
dotnet --info

.NET SDK:
 Version:           9.0.100-rc.1.24452.12
 Commit:            81a714c6d3
 Workload version:  9.0.100-manifests.a7bf2b8f
 MSBuild version:   17.12.0-preview-24422-09+d17ec720d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
 [aspire]
   Installation Source: VS 17.11.35303.130
   Manifest Version:    8.1.0/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json
   Install Type:              Msi


Host:
  Version:      9.0.0-rc.1.24431.7
  Architecture: x64
  Commit:       static

.NET SDKs installed:
  2.1.403 [C:\Program Files\dotnet\sdk]
  6.0.401 [C:\Program Files\dotnet\sdk]
  7.0.101 [C:\Program Files\dotnet\sdk]
  8.0.100 [C:\Program Files\dotnet\sdk]
  8.0.400 [C:\Program Files\dotnet\sdk]
  9.0.100-rc.1.24452.12 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0-rc.1.24431.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0-rc.1.24452.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

And dotnet nuget why, reports the same as Aaron so dotnet nuget why .\<SolutionName>.sln System.Private.Uri -> does not have a dependency on 'System.Private.Uri'.

Perusing through the .deps.json as suggested I find a few references to it:

"runtime.any.System.Runtime/4.3.0": {
        "dependencies": {
          "System.Private.Uri": "4.3.0"
        }
      },
....
"runtime.unix.System.Runtime.Extensions/4.3.0": {
        "dependencies": {
          "System.Private.Uri": "4.3.0",
          "runtime.native.System": "4.3.0",
          "runtime.native.System.Security.Cryptography.OpenSsl": "4.3.0"
        }
      },

Both of these occurrences, initially seem beyond my control as they're located in stuff I've never really touched before, but I may be mistaken.

As it stands, this is a very confusing situation, however as I'm running on a RC, some jank is to be expected.

[zivkan]

Unfortunately there's a limitation in dotnet nuget why currently, it won't look at RID-specific sub-graphs in the assets file. The fix won't make it into .NET 9.0.100, but hopefully will for 9.0.200

• dotnet nuget why should check RID specific packages NuGet/Home#13718

Like any other transitive vulnerability, you can make this package a direct reference and then upgrade it to a version that does not have a known vulnerability. CPM with transitive pinning can automate this, and that way the package will automatically disappear as a direct package reference when you upgrade other packages and the package is no longer a transitive dependency in the graph.

For the specific case of the System.Private.Uri package version 4.3.0, looking at the package contents in NuGet Package Explorer, the package doesn't contain any dlls:

So, it's a good candicate to ignore with <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-5f2m-466j-3848;https://github.com/advisories/GHSA-x5qj-9vmx-7g6g;https://github.com/advisories/GHSA-xhfc-gr8f-ffwc" />.

I don't know why the GitHub advisory lists the package as vulnerable given it doesn't have any content, but this is what we're working with. We're also working on a feature called Supplied By Platform, which will automatically trim packages from the graph when the target framework you're using already provides the assemblies in the package. I hope that System.Private.Uri will be one of those packages that the .NET libraries team will advertise as supplied by platform. But the feature isn't done yet, so will only help in a future version of the .NET SDK once it's implemeneted.

[softlion]

@zivkan that means that specific warning about System.Private.Uri can be safely ignored ?

Note: That System.Private.Uri package comes from the Microsoft.WindowsAppSDK package.

[pregress]

it into .NET 9.0.100, but hopefully will for 9.0.200

Can this issue then be tagged with milestone: 9.0.200 ?
We can't adopt dotnet 9 since so many transitive dependencies have CVE's.

We rather not suppress it in csproj and solve the issues.

[martincostello]

That's not really "can't" - it's that you don't want to resolve it with explicit dependency upgrades. That is, it's not a hard blocker to any upgrade.

If you really want to use .NET 9 now, I would recommend adding the transitive dependencies to your project and clearly mark them as a temporary workaround with a comment, then later when the need for them is resolved you can remove it.

[softlion]

@pregress It looks like it's not even a transitive dependency, as the final binary used is an empty stub that redirects to the .NET 9 implementation. Not certain about that, I've read it in another thread.

[ZeldaJC]

I have same issue with .Net 6 project

Added these settings to *.csproj files does not solve the problem

[zivkan]

@ZeldaJC Can you reproduce on the command line?

Using the csproj below, when I do dotnet restore I don't get the warnings, but when I do dotnet restore -p:suppress=false (to use the condition I put in the csproj), I do get the warnings, so I can be confident it's working as expected

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>
    <NuGetAuditMode>all</NuGetAuditMode>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Runtime" Version="4.3.1" />
  </ItemGroup>

  <ItemGroup Condition=" '$(suppress)' != 'false' ">
    <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-5f2m-466j-3848;https://github.com/advisories/GHSA-x5qj-9vmx-7g6g;https://github.com/advisories/GHSA-xhfc-gr8f-ffwc" />
  </ItemGroup>

</Project>

[shainegordon]

strange thing is that this is happening in docker only, since updating to .NET 9 (mcr.microsoft.com/dotnet/sdk:9.0.100-alpine3.20)

building outside of docker, or in the IDE doesnt get this error

➜ dotnet clean                               

Build succeeded in 1.0s

➜ dotnet restore
Restore complete (0.7s)

Build succeeded in 0.8s

➜ dotnet build  
Restore complete (0.7s)
  Infrastructure succeeded (2.0s) → src/Infrastructure/bin/Debug/net9.0/Infrastructure.dll
  Infrastructure.Tests succeeded (0.8s) → tests/Infrastructure.Tests/bin/Debug/net9.0/Infrastructure.Tests.dll
  External succeeded (1.0s) → src/External/bin/Debug/net9.0/External.dll
  Model succeeded (1.2s) → src/Model/bin/Debug/net9.0/Model.dll
  Migrations.Console succeeded (0.3s) → tools/Migrations.Console/bin/Debug/net9.0/Migrations.Console.dll
  Features succeeded (2.0s) → src/Features/bin/Debug/net9.0/Features.dll
  Api succeeded (0.9s) → src/Api/bin/Debug/net9.0/Api.dll
  CodeGen.Console succeeded (0.5s) → tools/CodeGen.Console/bin/Debug/net9.0/CodeGen.Console.dll
  IntegrationTests succeeded (0.7s) → tests/IntegrationTests/bin/Debug/net9.0/IntegrationTests.dll

Build succeeded in 7.6s

➜ docker build --progress=plain -f src/Api/Dockerfile . 

//snipped

#17 [build-app  9/11] RUN dotnet restore src/Api --runtime linux-musl-x64
#17 0.597   Determining projects to restore...
#17 49.11   Restored /app/src/Infrastructure/Infrastructure.csproj (in 47.84 sec).
#17 49.11   Restored /app/src/Model/Model.csproj (in 47.84 sec).
#17 54.05   Restored /app/src/External/External.csproj (in 52.79 sec).
#17 59.41 /app/src/Features/Features.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848 [/app/src/Api/Api.csproj]
#17 59.41 /app/src/Features/Features.csproj : error NU1902: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g [/app/src/Api/Api.csproj]
#17 59.41 /app/src/Features/Features.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc [/app/src/Api/Api.csproj]
#17 59.51   Failed to restore /app/src/Features/Features.csproj (in 58.24 sec).
#17 69.30 /app/src/Api/Api.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-5f2m-466j-3848
#17 69.30 /app/src/Api/Api.csproj : error NU1902: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-x5qj-9vmx-7g6g
#17 69.30 /app/src/Api/Api.csproj : error NU1903: Warning As Error: Package 'System.Private.Uri' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-xhfc-gr8f-ffwc
#17 69.35   Failed to restore /app/src/Api/Api.csproj (in 1.13 min).
#17 ERROR: process "/bin/sh -c dotnet restore src/Api --runtime linux-musl-x64" did not complete successfully: exit code: 1

This dependency also does not exist in any of our *.deps.json files

[pregress]

I think this happens because of os= linux.
If you do it with the following command on windows: dotnet build --configuration Release --os linux

You get the same error, installing the latest version of System.Private.Uri with version 4.3.2 fixes this. But it's just a bandaid.
Seems like the internal dependencies should be fixed...

[shainegordon]

I think this happens because of os= linux. If you do it with the following command on windows: dotnet build --configuration Release --os linux

You get the same error, installing the latest version of System.Private.Uri with version 4.3.2 fixes this. But it's just a bandaid. Seems like the internal dependencies should be fixed...

Yes, for now I just added the lastest System.Private.Uri as an unused project dependency, which fixes the issue, but as you say, developers should not have to care about what dependencies MsBuild is using