Security issue in dependency Microsoft.Identity.Client

[ckadluba]

After releasing MSSQL sink 8.2.1 I received the following alert from nuget.org via email.

Hello,
We are reaching out to inform you of a critical update requirement for the Microsoft.Identity.Client package referenced in your project.
A previous version of this package contained a typo in a comment URL that inadvertently pointed to a typosquatting phishing site:
🔗 hXXps[:]//login[.]microsfoftonline[.]com/common
This URL has been flagged as ConfirmedMaliciousURL by multiple security vendors, including Avira, Sophos, and Bitdefender.
To address this, the team released a fix in version 4.72.1, published on May 20, as documented in their https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/releases/tag/4.72.1.
🚨 Required Action:
Please update to version 4.72.1 or later of Microsoft.Identity.Client immediately on your below packages:

Serilog.Sinks.MSSqlServer 8.2.2-dev-00134, 8.2.1, 8.2.1-dev-00132

We appreciate your prompt attention to this matter to help maintain a secure and trustworthy ecosystem.
If you have any questions or need assistance, feel free to reach out.
Best Regards,
NuGet Admin
(tracking: 80c2ec86)

[jonorossi]

@ckadluba Am I missing something, but Azure.Identity 1.14.1 (latest version) uses Microsoft.Identity.Client >= 4.71.1. Nothing we could change?

[ckadluba]

I just seen it in Rider. Seems we have already version 4.71.1 as a transient dependency.

Could this be false positive? Let me do some checks. If so, I'll close this one again.

[ckadluba]

Indeed it seems that Microsoft.Data.SqlClient 5.2.3 which we reference does have a reference to Microsoft.Identity.Client 4.61.3.

SqlClient 5.2.3 is the newest with major version 5 yet.

SqlClient 6.0.2 no longer seems to have a direct dependency on Microsoft.Identity.Client (https://www.nuget.org/packages/Microsoft.Data.SqlClient/6.0.2#dependencies-body-tab), only on Azure.Identity 1.11.4, which references Microsoft.Identity.Client 4.71.1. So updating to SqlClient 6.0.2 would fix the issue.

So we can either update to SqlClient 6.0.2 and possibly introduce breaking changes, which would require bumping MSSQL sink version to the next major of 9 or accept the risk until Microsoft hopefully fixes this issue in the SqlClient 5 branch.

Need to do some more research:

• how critical the issue really is
• if Microsoft plans a fix for SqlClient 5 and
• which breaking changes SqlClient 6 has and how they would affect MSSQL sink

[ckadluba]

Breaking changes in SqlClient 6.0

• Removed support for .NET Standard. Remove support for .NET Standard 2.0 and 2.1 dotnet/SqlClient#2386
• Removed support for .NET 6 Drop net6 support dotnet/SqlClient#2927
• Removed UWP (UAP) references. Remove UWP (uap) references and special cased code dotnet/SqlClient#2483
• Removed SQL 2000 client-side debugging support for .NET Framework Remove SQL 2000 client-side debugging support dotnet/SqlClient#2981, Remove SQLDebugging class dotnet/SqlClient#2940

(See: https://github.com/dotnet/SqlClient/releases?page=1)

Most of these points are not relevant for MSSQL sink but the removal of .NET Standard support is a blocker for us since we need to target .NET Framework too. But there is already a preview version SqlClient 6.1.0-preview2.25178.5 which was released recently (2025-06-27). It seems to bring back .NET Standard support:

Revived .NET Standard 2.0 target support
What Changed:

• Support for targeting .NET Standard 2.0 has returned. (Re-introduce .NET Standard 2.0 DLLs dotnet/SqlClient#3381)
• Support had previously been removed in the 6.0 release, with the community voicing concerns.

(See: https://github.com/dotnet/SqlClient/releases/tag/v6.1.0-preview2)

Security Risk Assessment

The security problem reported by nuget.org is concerning a documentation comment on a public method in Microsoft.Identity.Client which points to a mistyped Microsoft website URL (AzureAD/microsoft-authentication-library-for-dotnet@4.72.0...4.72.1). This could for instance be abused when developers click on the link in their IDEs when using the library. As far as I can tell, this problem cannot lead to a security risk while executing code from the library.

Additionally, the problem only seems to affect developers which directly work with the library Microsoft.Identity.Client which is not the case when working with the MSSQL sink code because we have no direct dependency on that library. It is only referenced transiently via Microsoft.Data.SqlClient.

Suggested Action

I suggest that we accept the potential risk for a brief period and upgrade to SqlClient 6.1.0 as soon as a stable release is available. Does that sound reasonable? Please comment!

[jonorossi]

Suggested Action

I suggest that we accept the potential risk for a brief period and upgrade to SqlClient 6.1.0 as soon as a stable release is available. Does that sound reasonable? Please comment!

Completely agree, especially with it being a non-production security issue!

It's also only in the remarks of the XML comment for WithOidcAuthority, pretty unlikely someone is going to find it and NuGet should be picking up a newer version anyway.
AzureAD/microsoft-authentication-library-for-dotnet@68ae955

[ckadluba]

The affected MSSQL sink releases (8.2.1, and some -dev pre releases) were delisted by nuget.org as reported in issue #625.

As a temporary workaround we could add Microsoft.Identity.Client 4.71.1 as a direct sink dependency until SqlClient 6.1.0 is released.

[jonorossi]

The affected MSSQL sink releases (8.2.1, and some -dev pre releases) were delisted by nuget.org as reported in issue #625.

Nuget.org delisted the version after sending me an alert via email. After assessing the risk, we figured out that it is probably not critical for the MSSQL sink and we can wait until Microsoft publishes a fix. But that was before I learned that they would delist the version.

@ckadluba Was that a separate email to the one the 2 of us were sent titled "Immediate Action Required: Update Microsoft.Identity.Client Package for NuGet Account serilog-mssql to Address Security Risk"? There is no mention of delisting any package in that email, let alone the MSSQL sink package.

It seems like a completely silly way of operating a package registry, there was no vulnerability in the MSSQL sink package and this package didn't even pull in the XML docs providing someone access to the bad URL. I'd have thought that the vulnerable package could be delisted, which shouldn't have affected this library's users as the NuGet CLI/tools should have been pulling the newer version from the version range anyway.

[ckadluba]

Yes, it was that email which you mention. And I totally agree with you.

Maybe we should reply and make them aware of this fact. I'll do that later today.