Error NU1901: Package 'System.Security.Cryptography.Xml' 10.0.0 has a known low severity vulnerability

[aeirisch]

Describe the bug
We updated the System.ServiceModel.Http to v10.0.652802 NuGet package in our VS 26 solution on .NET 10 and during the build we got this warning from the transient package:

Warning NU1901: Package 'System.Security.Cryptography.Xml' 10.0.0 has a known low severity vulnerability

To Reproduce
Steps to reproduce the behavior:

1. Update in VS the NuGet System.ServiceModel.Http to v10.0.652802 and build the project.
2. In VS we called dotnet nuget why src/<project-folder>/<project-file.csproj> System.Security.Cryptography.Xml and got the following output
   Project '<project-file.csproj>' has the following dependency graph(s) for 'System.Security.Cryptography.Xml':
   [net10.0]
   └── System.ServiceModel.Http (v10.0.652802)
   └── System.ServiceModel.Primitives (v10.0.652802)
   └── System.Security.Cryptography.Xml (v10.0.0) // Should be v10.0.6

Expected behavior
We expected that the transient package System.Security.Cryptography.Xml v10.0.6 comes automatically with the update of System.ServiceModel.Http v10.0.652802
We would like not to add the package System.Security.Cryptography.Xml v10.0.6 explicit in our project file and use only the correct transient package of System.Security.Cryptography.Xml.

Screenshots

[manoharc1999]

Any estimate on time when the new version will be released with the fix?

[ldeluigi]

We have builds failing with warnings as errors turned on

[mconnew]

The good news is that the vulnerability that was fixed is in a code path that WCF does NOT use so you aren't vulnerable even when using the older package. Until we get a new package released, you can override the version in your own app. If you use central package management, any overrides you specify in your Directory.Packages.Props file apply to transitive packages without having a top level dependency. Basically you can add System.Security.Cryptography.Xml to your Directory.Packages.Props file specifying a later version without needing to add System.Security.Cryptography.Xml to your own app as a direct dependency.
In the past the dotnet policy was to not release new packages when a dependency has a vulnerability if the vulnerability wasn't exercised. This caused a lot of frustration previously because WCF depended on the latest version of a package which pulled in a vulnerable transitive dependency that was marked as vulnerable. The package we directly depended on didn't release a new version because they weren't using the vulnerable functionality, so there was nothing we could do.
Because of the amount of noise generated by that policy, as of .NET 10, every time there's a servicing release, all dotnet runtime packages are rereleased even if there's zero code change in order to update their dependencies.
The WCF team is a small team and we don't have the bandwidth to do a full product release every single month along with the dotnet runtime team, so when there's a dependent package (transitive or otherwise) that is marked vulnerable, if the vulnerability doesn't affect WCF, there might be some delay in releasing a new package. If the vulnerability does affect WCF, we will release a new package as a priority. Trying to keep up with releasing a new package every month would effectively halt all development in WCF, and we do want to keep releasing new features migrated from .NET Framework. For example, I recently added (not released yet) transactions support.
With the new features that have been recently developed for WCF Client, I expect a new package to be coming in the next month. The dependencies will be updated to the latest at that point.

[quails4Eva]

@mconnew It looks like there is now a high severity vulnerability (or 2) against the same package, do you know if WCF is vulnerable to this one?
Either way, does it affect the timescale for patching?

GHSA-37gx-xxp4-5rgx
GHSA-w3x6-4m5h-cxqf