SEATTLE — July 6, 2026. Safeguard's Research Team today published its mid-year analysis of the NuGet ecosystem, and the numbers are not flattering for the .NET supply chain. Across more than 41,000 production repositories scanned between January and June 2026, Safeguard found that 68% of .NET applications ship at least one NuGet package with a known critical or high-severity vulnerability, and a small cluster of just eleven packages account for nearly half of all flagged findings. The report — compiled from Safeguard's SBOM ingestion pipeline, its Griffin AI reachability engine, and cross-referenced against the National Vulnerability Database and GitHub Security Advisories — is the clearest picture yet of where risk concentrates in the .NET ecosystem, and it arrives as enterprise .NET adoption in regulated industries (finance, healthcare, government contracting) continues to climb.
The headline finding is not that .NET has more vulnerabilities than other ecosystems — npm and PyPI both post higher raw advisory counts — but that .NET's vulnerability concentration is unusually high. A small number of foundational packages sit so deep in the dependency graph (serialization, cryptography, image processing, XML/config parsing) that a single unpatched version can propagate into thousands of downstream applications without any direct developer action. That structural reality is what makes a "most vulnerable .NET libraries" ranking useful: it's less a scoreboard of bad actors and more a map of where remediation effort will have outsized impact.
Methodology: how the report was built
Safeguard's dataset combines two sources. First, SBOMs generated or ingested from customer and open-source .NET projects (CycloneDX and SPDX formats, spanning .NET Framework, .NET 6/8, and early .NET 9 targets). Second, advisory data pulled from NVD, GHSA, and the OSV database, matched against exact package-version ranges rather than package names alone — a distinction that matters, since several of the libraries below have had vulnerabilities fixed and reintroduced across major version lines. Griffin AI, Safeguard's reachability and exploitability engine, was then run against a sample of 6,200 repositories to determine what fraction of "vulnerable" findings actually involved code paths an attacker could reach at runtime. That reachability layer is what separates this report from a raw CVE count, and it's the detail that should most change how .NET teams prioritize.
The most flagged .NET libraries, by finding volume
Based on aggregate scan volume across the sample set, the packages generating the most vulnerability findings in .NET codebases in H1 2026 were:
-
Newtonsoft.Json (Json.NET) — Still the most-installed serialization library in the .NET ecosystem despite Microsoft's push toward
System.Text.Json. The recurring risk class isTypeNameHandling-based insecure deserialization (tracked across GHSA-5crp-9r3c-p9vr and related downstream advisories), which underAutoorAllsettings allows an attacker who controls JSON input to instantiate arbitrary types and, with the right gadget chain, achieve remote code execution. Safeguard found this configuration still present in 22% of scanned repositories using the library. -
System.Drawing.Common — Formally deprecated for cross-platform use, but still widely referenced in legacy Windows services. CVE-2021-24112, a remote code execution vulnerability tied to unsafe GDI+ image decoding, remains the most-cited historical finding, and Safeguard's scans show the vulnerable pattern persisting in older internal tooling and reporting services that were never migrated to
SixLabors.ImageSharpor containerized Windows-only builds. -
BouncyCastle.Cryptography (.NET port) — The May 2024 disclosure cluster — CVE-2024-29857 (RSA key generation weakness enabling DoS), CVE-2024-30171 (side-channel timing issue in AES-GCM), and CVE-2024-30172 (infinite loop DoS in X9EC point validation) — continues to show up in scans two years later, largely because BouncyCastle is a transitive dependency of higher-level TLS, signing, and PDF libraries that application teams never directly vet.
-
log4net — The .NET port of Apache's log4j sees far less attention than its Java counterpart post-Log4Shell, but CVE-2018-1285, an XML external entity and injection flaw in
XmlConfiguratorthat can lead to remote code execution when configuration files are loaded from untrusted sources, is still detected in production configurations that predate the fix. -
YamlDotNet — Deserialization of untrusted YAML into strongly typed .NET objects remains a recurring finding class, structurally similar to the Newtonsoft.Json
TypeNameHandlingproblem: permissive type resolution during deserialization creates an object-instantiation primitive that's difficult to detect with static analysis alone. -
SixLabors.ImageSharp — Ironically the recommended replacement for
System.Drawing.Common, ImageSharp has had its own denial-of-service advisories tied to malformed image decoding (uncontrolled resource consumption when parsing crafted GIF/PNG headers), which Safeguard's scans flagged in image-upload and thumbnail-generation services. -
Microsoft.IdentityModel.Tokens / JsonWebTokens — Token validation libraries underpinning much of ASP.NET Core's authentication stack showed elevated finding rates tied to algorithm-confusion and signature-validation edge cases, a pattern consistent with the broader JWT ecosystem's recurring "none algorithm" and key-confusion issues.
-
RestSharp — Older versions with permissive default certificate validation behavior and inconsistent handling of redirect headers appeared frequently in service-to-service HTTP client code, often installed years ago and never revisited.
Rounding out the list: Npgsql, AutoMapper (indirectly, via unsafe reflection-based mapping configurations), and IdentityServer4, whose end-of-life status (superseded by Duende IdentityServer) means it now receives no security patches at all — a slow-burning risk for any organization still running it in production identity infrastructure.
Why these libraries keep reappearing
Three structural patterns explain the persistence of this list. First, transitive depth: packages like BouncyCastle and Newtonsoft.Json are rarely installed directly by application developers — they arrive bundled inside higher-level packages (PDF generators, cloud SDKs, message-queue clients), which means the team that could actually bump the version often has no visibility into the fact that it's vulnerable at all. Second, serialization and parsing surfaces are inherently high-risk: any library whose job is turning untrusted bytes into typed objects — JSON, YAML, XML, images — is a natural target for deserialization and memory-safety bugs, and .NET's ecosystem leans heavily on a small number of libraries to do that work everywhere. Third, long-lived legacy targets: a meaningful share of enterprise .NET code still targets .NET Framework 4.x or early .NET Core versions, where upgrading a vulnerable package can mean cascading breaking changes across an entire dependency tree, so teams defer the update indefinitely.
The reachability gap: not all findings are equal
This is where the report's Griffin AI analysis produces its most actionable number: of the vulnerability findings tied to the eleven libraries above, only 31% involved code paths that were actually reachable from an entry point an attacker could realistically trigger — an exposed API endpoint, a message handler, a file upload path. The remaining 69% were present in the dependency tree but never invoked in a way that would expose the vulnerable function to attacker-controlled input. That doesn't mean those findings are safe to ignore — dependency trees shift, and code that's unreachable today can become reachable after a refactor — but it does mean that treating every CVE hit with equal urgency is the single biggest source of wasted remediation effort Safeguard observes in .NET security programs. Teams drowning in a queue of hundreds of "critical" NuGet findings are, in practice, usually facing a much smaller set of genuinely exploitable issues.
What this means for enterprise .NET teams
The practical takeaway from this report is not "avoid these libraries" — most of them are, in patched versions, safe and well-maintained. It's that .NET organizations need visibility into two things they currently lack in most tooling: which vulnerable packages are transitive versus direct dependencies, and which vulnerable code paths are actually reachable at runtime. Without both, security teams end up either ignoring SCA output entirely (alert fatigue) or burning engineering time patching libraries that were never exploitable in the first place. Given that .NET's risk concentrates so heavily in a handful of foundational packages, the fix is also concentrated: a focused effort on the top ten libraries in this report, prioritized by reachability rather than raw CVSS score, would eliminate the large majority of real exploitable risk in a typical .NET estate.
How Safeguard Helps
Safeguard was built to close exactly this gap. Our platform generates and ingests SBOMs across .NET, Java, JavaScript, and Python codebases, giving teams a single accurate inventory of direct and transitive NuGet dependencies — including the BouncyCastle and Newtonsoft.Json instances buried three layers deep that most SCA tools miss. Griffin AI then performs reachability analysis on every flagged CVE, tracing call graphs from application entry points to vulnerable functions so teams can see, in minutes, whether a finding is theoretical or exploitable — the same methodology behind the 31% reachability figure in this report. For confirmed exploitable issues, Safeguard automatically opens pull requests with version bumps and compatibility notes, cutting remediation time from weeks to hours. And because the platform continuously re-scans as code changes, a library that's unreachable today gets flagged the moment a refactor makes it exposed. For .NET teams tired of triaging hundreds of low-signal NuGet alerts, that combination — accurate SBOMs, real reachability, and auto-fix PRs — is the difference between a vulnerability report and an actual reduction in risk.