CVE-2022-41064

EUVD-2022-7282 · Published Nov 8, 2022

.NET Information Disclosure Vulnerability

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET, .NET Core and .NET Framework's System.Data.SqlClient and Microsoft.Data.SqlClient NuGet Packages.

A vulnerability exists in System.Data.SqlClient and Microsoft.Data.SqlClient libraries where a timeout occurring under high load can cause incorrect data to be returned as the result of an asynchronously executed query.

<a name="mitigation-factors"></a>Mitigation factors

If you are not talking to Microsoft SQL Server from your application you are not affected by this vulnerability.

<a name="how-affected"></a>How do I know if I am affected?

.NET has two types of dependencies: direct and transitive. Direct dependencies are dependencies where you specifically add a package to your project, transitive dependencies occur when you add a package to your project that in turn relies on another package.

For example, the Microsoft.AspNetCore.Mvc package depends on the Microsoft.AspNetCore.Mvc.Core package. When you add a dependency on Microsoft.AspNetCore.Mvc in your project, you're taking a transitive dependency on Microsoft.AspNetCore.Mvc.Core.

Any application that has a direct or transitive dependency on the  affected packages listed above are vulnerable.

<a name="how-fix"></a>How do I fix the issue?

If you are using System.Data.SqlClient on .NET Framework you must install the November update for .NET Framework
If you are using System.Data.SqlClient on .NET Core, .NET 5 or .NET 6 you must update the nuget package to an updated version as listed in the affected packages.
If you are using Microsoft.Data.SqlClient, anywhere (.NET Core, .NET 5/6, .NET Framework) and you are using a version that is vulnerable you must update as listed in the affected packages.

Additional Details

.NET and .NET Framework projects have two types of dependencies: direct and transitive. You must update your projects using the following instructions to address both types of dependency.

Additionally, .NET Framework users must also install the November 2022 security patch to be protected.

Direct dependencies

Direct dependencies are discoverable by examining your csproj file. They can be fixed by editing the project file or using nuget command line to update the dependency.

Transitive dependencies

Transitive dependencies occur when you add a package to your project that in turn relies on another package. Transitive dependencies can be discovered by searching the project.assets.json file for each of your projects. This file is produced on each build and is in the obj directory for each project.

The project.assets.json files are the authoritative list of all packages used by your project, containing both direct and transitive dependencies.

Fixing direct dependencies

Direct dependencies are nuget packages that have been specifically added to a project, rather than being pulled in because a nuget package added requires it. They can be seen in the solution explorer in Visual Studio or by opening the csproj for the project and examining the packageReference nodes for the package name, specified by the Include parameter, and its version, specified by the Version parameter.

For example, the following project file has a direct dependency on version 2.1.1 of Microsoft.Data.SqlClient.

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

  <PropertyGroup> 
    <TargetFramework>net6.0</TargetFramework> 
    <Nullable>enable</Nullable> 
    <ImplicitUsings>enable</ImplicitUsings> 
  </PropertyGroup> 

  <ItemGroup> 
    <PackageReference Include="Microsoft.Data.SqlClient" Version="2.1.1" /> 
  </ItemGroup> 

</Project>

Fixing direct dependencies with the nuget command line

Open a command line to the directory holding your project

Run the following command if you are using a version of Microsoft.Data.SqlClient between 2.0.0 and 2.1.1

dotnet add package Microsoft.Data.SqlClient --version 2.1.2

Run the following command if you are using a version of Microsoft.Data.SqlClient below 1.1.4

dotnet add package Microsoft.Data.SqlClient --version 1.1.4

Run the following command if you are using a version of System.Data.SqlClient below 4.8.4

dotnet add package System.Data.SqlClient --version 4.8.5

Fixing direct dependencies by editing the project file

Open projectname.csproj in your editor. If you're using Visual Studio, right-click the project and choose Edit projectname.csproj from the context menu, where projectname is the name of your project.

Look for PackageReference elements. The following shows an example project file:

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

  <PropertyGroup> 
    <TargetFramework>net6.0</TargetFramework> 
    <Nullable>enable</Nullable> 
    <ImplicitUsings>enable</ImplicitUsings> 
  </PropertyGroup> 

  <ItemGroup> 
    <PackageReference Include="Microsoft.Data.SqlClient" Version="2.1.1" /> 
  </ItemGroup> 

</Project>

The preceding example has a reference tone of the vulnerable packages as seen by the single PackageReference element. The name of the package is in the Include attribute.
The package version number is in the Version attribute.

To update the version to the secure package, change the version number to the updated package version as listed in the Affected software section of this document.

In this example, update Microsoft.Data.SqlClient to the appropriate fixed version for your major version. Save the csproj file. The example csproj now looks as follows:

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

  <PropertyGroup> 
    <TargetFramework>net6.0</TargetFramework> 
    <Nullable>enable</Nullable> 
    <ImplicitUsings>enable</ImplicitUsings> 
  </PropertyGroup> 

  <ItemGroup> 
    <PackageReference Include="Microsoft.Data.SqlClient" Version="2.1.2" /> 
  </ItemGroup> 

</Project>

If you're using Visual Studio and you save your updated csproj file, Visual Studio will restore the new package version.

You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.

If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore the updated dependencies.

Now recompile your application. If after recompilation you see a Dependency conflict warning, you must update your other direct dependencies to versions that take a dependency on the updated package.

Discovering and fixing transitive dependencies

Rebuild your solution and then open the project.assets.json file from in each of your project’s obj directory in your editor. We suggest you use an editor that understands JSON and allows you to collapse and expand nodes to review this file. Both Visual Studio and Visual Studio Code provide JSON friendly editing.

Search the project.assets.json file for the vulnerable packages above using the format packagename/ for each of the package names from the preceding table. If you find the assembly name in your search:

Examine the line on which they are found, the version number is after the /.

Compare to the vulnerable versions

For example, a search result that shows "Microsoft.Data.SqlClient": "2.1.0" is a reference to version 2.1.0 of Microsoft.Data.SqlClient If your project.assets.json file includes vulnerable versions of the nuget packages then you need to fix the transitive dependencies.

If you have not found any reference to any vulnerable packages, this means either

None of your direct dependencies depend on any vulnerable packages, or

You have already fixed the problem by updating the direct dependencies.

If your transitive dependency review found references to the vulnerable package, you must add a direct dependency to the updated package to your csproj file to override the transitive dependency.

Editing projects to fix transitive dependencies

Open projectname.csproj in your editor. Look for PackageReference nodes, for example:

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

  <PropertyGroup> 
    <TargetFramework>net6.0</TargetFramework> 
    <Nullable>enable</Nullable> 
    <ImplicitUsings>enable</ImplicitUsings> 
  </PropertyGroup> 

  <ItemGroup> 
    <PackageReference Include="IndirectDependency" Version="1.0.0" /> 
  </ItemGroup> 

</Project>

You must add a direct dependency to the updated, matching major/minor version of the vulnerable by adding it to the csproj file. This is done by adding a new line to the dependencies section, referencing the fixed version. For example,

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

  <PropertyGroup> 
    <TargetFramework>net6.0</TargetFramework> 
    <Nullable>enable</Nullable> 
    <ImplicitUsings>enable</ImplicitUsings> 
  </PropertyGroup> 

  <ItemGroup> 
    <PackageReference Include="IndirectDependency" Version="1.0.0" /> 
    <PackageReference Include="Microsoft.Data.SqlClient" Version="2.1.2" /> 
  </ItemGroup> 

</Project>

After you've added the direct dependency reference, save your csproj file.

If you're using Visual Studio, save your updated csproj file and Visual Studio will restore the new package versions. You can see the restore results by opening the Output window (Ctrl+Alt+O) and changing the Show output from drop-down list to Package Manager.

If you're not using Visual Studio, open a command line and change to your project directory. Execute the dotnet restore command to restore the new dependencies.

Using the nuget command line to fix transitive dependencies

Open a command window and change directory to your project directory.

Run the following command if you have an indirect dependency on Microsoft.Data.SqlClient between versions 2.0.0 and 2.1.1

dotnet add package Microsoft.Data.SqlClient --version 2.1.2

Run the following command if you have an indirect dependency on Microsoft.Data.SqlClient below 1.1.4

dotnet add package Microsoft.Data.SqlClient --version 1.1.4

Run the following command if you have an indirect dependency on System.Data.SqlClient below 4.8.4

dotnet add package System.Data.SqlClient --version 4.8.5

Execute the dotnet restore command to restore the new dependencies.

Rebuilding your application

Finally, you must rebuild your application, test, and redeploy.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions

V1.0 (November 8, 2022): Advisory published.

Version 1.0

Last Updated 2022-11-08

Technologies

Microsoft Windows 7Microsoft Windows Server 2008Microsoft Windows Server 2012Microsoft NugetMicrosoft Windows Rt 8.1Microsoft .Net FrameworkMicrosoft Windows 10Microsoft Windows 8.1Microsoft Windows Server 2019Microsoft Windows 11Microsoft Windows Server 2016Microsoft Windows Server 2022System.Data.Sqlclient System.Data.SqlclientMicrosoft.Data.Sqlclient Microsoft.Data.Sqlclient

CVSS scores

v3.15.8CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N

References

Potentially impacted assets

See if this affects your attack surface

Latest trending attack

Criticalyesterday

Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)

This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it. Why a second control CVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli ("br") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution. Any server that decompresses request bodies sent with "Content-Encoding: br" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library. The flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support. What this control checks Patrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service. How to read the result Potentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside. This check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification. Affected and fixed versions Google Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution. Recommendations Update every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library. Reduce the exposure until the update is deployed. Reject requests with "Content-Encoding: br" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as "gzip, br". On Envoy and Istio, disable request decompression for Brotli. Review outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.