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?

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.