July 11, 2025 • 7 minutes to read

So Microsoft Deleted Some of Our Packages From NuGet.org Without Notice

An uncomfortable precedent that should not be repeated - even for CVEs.

“Software supply chain management” is one of those terms that sounds like Venture Capital-funded vendor marketing bullshit right up until it isn’t.

In 2016 the npm left-pad incident taught many of us in the software industry the importance of:

  1. The fragility of depending directly on central package management systems, such as npm or nuget.org, hence why artifact proxying tools like JFrog Artifactory became so important; and
  2. How centralized package management systems probably need to make stronger security and availability guarantees, such as not allowing hard deletes of packages in the first place.

One of the distinguishing features of nuget.org is they make it very, very hard for authors to delete their packages - only in exceptional cases, such as malware inclusion, will they allow the permanent deletion of packages.

Imagine my surprise yesterday, when I discovered that two of our Akka.NET packages were deleted1, by Microsoft, without any advanced notice. I only discovered that this was an issue when one of my own Akka.NET applications failed to build on CI/CD due to missing package versions.

Akka.Coordination.Azure deleted from NuGet.org

I’ll get into the reasons why they did this, but the bottom line is: this is a disturbing precedent that really should never be repeated.

In essence, Microsoft’s adjacent business units abused NuGet to deal with their own security vulnerabilities - getting a level of access that would never be granted to any other publisher on the platform.

Microsoft.Identity.Client Security Vulnerabilities

Yesterday we received the following email to our nuget.org addresses for the Akka.NET organization:

Microsoft.Identity.Client vulnerability disclosure email

The GitHub release they link to doesn’t actually mention the vulnerability at all, and version 4.72.1 of the Microsoft.Identity.Client NuGet package still has the vulnerability. So, we weren’t actually sure what to make of those directions.

Both of our impacted packages, Akka.Coordination.Azure and Akka.Discovery.Azure, don’t take a direct dependency on this package at all.

Rather Microsoft.Identity.Client is a transitive dependency of Microsoft’s Azure.Identity package, which we reference for authenticating these plugins’ access to Azure resources.

Immediately after receiving this email, which makes zero mention of our package versions being deleted, we investigated and found that:

  1. The “vulnerability” was just a typo in a public-facing XML-DOC comment that happens to point to a typo-squatting URL that is commonly used in phishing attacks. Sucks, but it’s not a “real” CVE in the sense of it impacting actual program execution - a user would have to manually do something with that information in order to be vulnerable.
  2. Azure.Identity’s developers had presumably been contacted by the AAD team already. Their most recent version of their plugin (at the time), 1.14.1, hadn’t been updated with a non-“vulnerable” version of Microsoft.Identity.Client.

Given both of those data points, we figured this was probably a nothing-burger and went about our business. “We’ll update our plugins once there’s a new version of Azure.Identity” was the decision.

It was only later when I tried to build one of my own Akka.NET applications that we discovered that the package versions had been deleted outright, which we fixed via a new update that took a direct dependency on Microsoft.Identity.Client2.

A Bad Precedent

The Microsoft Entra / Azure Active Directory people were trying to address a legitimate security concern. I totally get it. But there are new CVE disclosures on Microsoft packages virtually every month.

NuGet has a built-in system for remedying this:

  1. CVE and deprecation disclosures on the NuGet.org feed and
  2. Built in support for logging build warnings when vulnerable packages are restored.

This is the normal process by which we and every other active package author have resolved CVEs from upstream dependencies for years. Why was this a special case that merited the extreme step of deleting other people’s packages without notice?

This precedent bothers me for three reasons:

  1. Undermines confidence in indefinite package availability. Hard-deleting packages is supposed to be a giant no-no for the NuGet ecosystem. If criteria for deleting packages now includes “every time Microsoft makes a boo-boo”, that’s impossible for us to predict or mitigate as OSS vendors on the NuGet platform. Our only recourse there would be to host our own NuGet feed and push our users to that, which would have the affect of killing our distribution and the ability for other authors to derive our work.
  2. Unique access for Microsoft alone. Imagine if we had a major vulnerability in one of our Akka.NET packages that exposed all of our users to a severe CVE - would Petabridge be given permission to hard-delete any of the 200+ packages that depend on us to remediate it? Obviously not. If a bigger vendor like AWS or Google had a similar issue to Microsoft’s, do you think they’d get permission to delete any third party authors’ package versions? Probably not.
  3. The arbitrariness of it. Why did only our new package versions get deleted, and not the older ones that also transitively referenced the vulnerable version? Why did the email that was sent to us make zero mention of our packages being deleted? By what process was this decided and enforced by NuGet?

Microsoft trying to solve a vulnerability issue isn’t the problem - it’s the way they did it. If you look back at my post about the .NET Foundation back-dooring their own projects by abusing the Foundation’s administrative access, read this key paragraph:

But using that administrative access is a nuclear option - OSS foundations must have it but they must also never use it outside of these narrow cases. As soon as you make a move using this access without the maintainers’ consent the fallout is going to turn the relationship between foundation and maintainer radioactive, as the maintainer’s autonomy over the project is now compromised.

We trust NuGet as our distribution platform for our intellectual property and our customers trust it for being able to readily access it. If that trust in the perpetual availability of our IP can be disrupted any time a Microsoft organization fucks up and introduces a vulnerability, that’s a real problem for us and our users.

What’s the limiting principle here going forward? And why did this vulnerability need to be treated differently than any of the other hundreds of vulnerabilities disclosed in Microsoft packages over the past 10 years?

Update

A user on X reported that this also happened to their packages too:

  1. I didn’t even realize that Deleted was a possible status for a package version on NuGet. I’ve been publishing packages there for nearly 15 years! ↩

  2. Later on, after I bitched about it on Twitter, the Azure.Identity team also released a new update. ↩

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..