Transient high severity vulnerability (System.Text.Json) in Microsoft.Extensions.Configuration.Json

[ibruynin]

Description

Microsoft.Extensions.Configuration.Json 8.0.0 defines a dependency on System.Text.Json >=8.0.0
Microsoft.Extensions.Configuration.Json 8.0.0 on nuget.org

This package is flagged as highly vulnerable
System.Text.Json 8.0.0 on nuget.org
There is a fix available in version 8.0.4
System.Text.Json 8.0.4 on nuget.org

All other dependencies (usually >= 4.7.2) are upgraded to 8.0.0 as well because of the dependency above.
Azure.Identity on nuget.org is a good example, but is not aware of security issues since it relies on a version that is ok.
Cfr. System.Text.Json 4.7.2 on nuget.org

So, this is only an issue when Microsoft.Extensions.Configuration.Json is included in the nuget dependency tree.

Can the System.Text.Json dependency be upgraded to 8.0.4?

Reproduction Steps

Prereqs

winget install Microsoft.DotNet.SDK.8

Repro steps

1. Create a blank console app
   dotnet new console -n repro

2. Add Azure.Identity
   cd repro
dotnet add package "Azure.Identity"

3. Build the solution and publish
   dotnet build
dotnet publish -o app

4. Check the dependency on System.text.Json (-->4.7.2 not vulnerable ✅ )
   cat .\app\repro.deps.json

5. Add Microsoft.Extensions.Configuration.Json
   dotnet add package "Microsoft.Extensions.Configuration.Json"

6. Build the solution and publish
   dotnet build
dotnet publish -o app

7. Check the dependency on System.text.Json (-->8.0.0 vulnerable ❌ )
   cat .\app\repro.deps.json

Expected behavior

Step 5 should introduce a dependency on System.Text.Json 8.0.4 instead of 8.0.0.

Actual behavior

Step 5 introduces a dependency on System.Text.Json 8.0.0 instead of 8.0.4/4.7.2.

Regression?

No response

Known Workarounds

Manually including a dependency on System.Text.Json 8.0.4 solves this.
However, that's not manageable

Configuration

dotnet sdk check

Welcome to .NET 8.0!

SDK Version: 8.0.401

Telemetry

The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

---

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

---

Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli

.NET SDKs:
Version Status

6.0.425 .NET 6.0 is going out of support soon.
7.0.203 .NET 7.0 is out of support.
8.0.401 Up to date.

Try out the newest .NET SDK features with .NET 9.0.100-preview.7.24407.12.

.NET Runtimes:
Name Version Status

Microsoft.AspNetCore.App 6.0.33 .NET 6.0 is going out of support soon.
Microsoft.NETCore.App 6.0.33 .NET 6.0 is going out of support soon.
Microsoft.WindowsDesktop.App 6.0.33 .NET 6.0 is going out of support soon.
Microsoft.AspNetCore.App 7.0.5 .NET 7.0 is out of support.
Microsoft.NETCore.App 7.0.5 .NET 7.0 is out of support.
Microsoft.WindowsDesktop.App 7.0.5 .NET 7.0 is out of support.
Microsoft.AspNetCore.App 8.0.8 Up to date.
Microsoft.NETCore.App 8.0.8 Up to date.
Microsoft.WindowsDesktop.App 8.0.8 Up to date.

The latest versions of .NET can be installed from https://aka.ms/dotnet-core-download. For more information about .NET lifecycles, see https://aka.ms/dotnet-core-support.

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

[gregsdennis]

I've seen quite a few of these. Maybe building vulnerability checking with an auto-upgrade feature into Nuget would be a good thing.

[huoyaoyuan]

This is an exact duplicate of #104705 .

For this type of transitive vulnerable dependency, please use #105028 and #105120 for centralized discussion.

[ibruynin]

@huoyaoyuan Sorry for the duplicate. Thanks for the reference to the centralized discussion.

Apart from that discussion, is it possible for this particular case to

• or align with other libraries in the .net repo and rely on >=4.7.2
• or upgrade the 8.x based dependency to >=8.0.4

That will at least fix this problem at hand.

Thanks for considering.

[colejohnson66]

See the other issues. You need to update to 8.0.4 yourself with a dedicated PackageReference.

[ibruynin]

See the other issues. You need to update to 8.0.4 yourself with a dedicated PackageReference.

That can never be the intention or at least I sincerely hope so.

quote: "To fix this without requiring customers to take a dependency on a nested package that isn't directly referenced in their code (customers should not have to do that), Microsoft should publish a System.Security.Cryptography.Pkcs 8.0.1 package that has a dependency on System.Formats.Asn1 >= 8.0.1." in #105028

[colejohnson66]

This has been hashed out in those other issues. Microsoft is aware of how this is not a sustainable solution, and they're looking into it. But their policy, as much as I and you may disagree, is not to release new versions if the only change is package dependencies.