Addressing security vulnerability in System.Text.Json 4.X version

[avanigupta]

Is there any plan to release a new 4.X version of System.Text.Json due to the security vulnerability reported here: #49377

The latest 4.X version of System.Text.Json is v4.7.2 but that version still depends on System.Text.Encodings.Web v4.7.1, which has the security vulnerability: https://www.nuget.org/packages/System.Text.Json/4.7.2

We have a dependency on System.Text.Json v4.6.0 and we cannot introduce breaking changes by upgrading to 5.X version.
What would be the best way to address this issue?

[ghost]

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

Issue Details

---

Is there any plan to release a new 4.X version on System.Text.Json due to the security vulnerability reported here: #49377

The latest 4.X version of System.Text.Json is v4.7.2 but that version still depends on System.Text.Encodings.Web v4.7.1, which has the security vulnerability: https://www.nuget.org/packages/System.Text.Json/4.7.2

We have a dependency on System.Text.Json v4.6.0 and we cannot introduce breaking changes by upgrading to 5.X version.
What would be the best way to address this issue?

Author:	avanigupta
Assignees:	-
Labels:	area-System.Text.Json
Milestone:	-

[huoyaoyuan]

We have a dependency on System.Text.Json v4.6.0 and we cannot introduce breaking changes by upgrading to 5.X version.

The supported framework is the same for 5.0.X. Do you mean any behavioral breaking change that's unacceptable?

I believe you can add a direct reference of System.Text.Encodings.Web in your project and select a non-vulnerable version.

[eiriktsarpalis]

Is there any plan to release a new 4.X version of System.Text.Json due to the security vulnerability reported here: #49377

Most likely not, the suggested workaround is to explicitly increment the version number of the impacted package.

Echoing @huoyaoyuan's question, are there any specific breaking changes blocking your transition to the v5 package?

[avanigupta]

We use System.Text.Json v4.6.0 in our Microsoft.Extensions.Configuration.AzureAppConfiguration package. If we decide to upgrade System.Text.Json to 5.X version, we'll have to bump up the major version of our library. Since this is a security vulnerability, we were hoping to release the fix quickly as a minor version upgrade so that users can start using the new version without worrying about breaking changes.

[eiriktsarpalis]

Can't the Microsoft.Extensions.Configuration.AzureAppConfiguration package explicitly list System.Text.Encodings.Web v4.7.2 as a dependency?

[avanigupta]

We can do that, but that's more of a workaround than a real solution.
Is the 4.X train of System.Text.Json out of support now? If not, it seems like this vulnerability should be addressed for anyone using the 4.X versions.

[eiriktsarpalis]

cc @ericstj

[jimmyca15]

@eiriktsarpalis @ericstj

Is the 4.x package versions of System.Text.Json still being supported / still receiving any possible security updates?

[eiriktsarpalis]

.NET Core 3.1 will be supported until December this year, so any servicing updates should surface as 4.x package updates.

[jimmyca15]

@eiriktsarpalis

I see thanks. Doesn't the package being supported mean that it should release an update if it has a dependency on a vulnerable package?

[ericstj]

4.6.0 is from the release wave of .NET Core 3.0 and is out of support. 4.7.2 is from .NET Core 3.1 and is still serviced.

We don't currently force updates transitively when one component is updated. We don't consider it a security vulnerability in System.Text.Json that its dependency System.Text.Encodings.Web had a security vulnerability. System.Text.Json does not redistribute the vulnerability, it references a package which can be updated. At the limit -- we don't expect the entire NuGet ecosystem to churn when one component has an update.

If System.Text.Json 4.7.x happens to ship again for other servicing it should update the dependency at that time, but there is no planned update for this that I am aware of.

The fix, which should not be considered a workaround, is to reference the newer version of System.Text.Encodings.Web in any project which might transitively reference it and execute code.

[jimmyca15]

@ericstj

Thank you for clarifying.

[GrabYourPitchforks]

Generally speaking, the position of the .NET team has been that we do not issue patches for non-vulnerable packages. The package System.Text.Json itself is not vulnerable and does not consume vulnerable functionality. The package System.Text.Encodings.Web was the vulnerable package, and a patch has been issued for it. The solutions we have been promoting are solutions where the application itself upgrades the version of the vulnerable package, since the application is the ultimate arbiter of what gets packaged as a single unit of deployment.

The NuGet team has been considering gestures which allow applications to self-remediate. This is the preferred mechanism from our perspective, since it does not require re-shipping the entire ecosystem and invalidating existing packages every time a single dependency updates. See NuGet/Home#11549 for further discussion on this.

[eiriktsarpalis]

Closing as answered.

[ericstj]

@ViktorHofer just shared this new feature with me and I think it really helps in this scenario: https://devblogs.microsoft.com/nuget/introducing-central-package-management/#transitive-pinning

Have a look at this gist https://gist.github.com/ericstj/1b9aab17e6701cda6e7f054a53fed9e3
You can see that by centrally managing your packages you can control the version of the transitive dependency without having to mention it in the project that uses it's parent. Nuget also will automatically list it in the nuspec so that folks consuming your package get the same behavior regardless of if they use that feature or not. Nice work @jeffkl!