C# runs the back office of the modern economy. It powers Azure control planes, hospital records systems, and the SolarWinds Orion platform whose 2020 Sunburst breach hit roughly 18,000 customers through a single poisoned .NET assembly. That scale is exactly why "C# security" has become its own discipline rather than a subset of generic AppSec advice. NuGet now hosts more than 400,000 packages, .NET Framework and .NET (Core) still ship side by side in production, and legacy patterns like BinaryFormatter deserialization linger in codebases written a decade ago. Attackers know this. Between 2023 and 2024, researchers documented malicious NuGet packages using IL weaving to inject payloads directly into compiled binaries, Microsoft patched a certificate-validation bypass that could let attackers spoof trusted software, and Microsoft finally began removing BinaryFormatter by default. This post walks through what's actually happening in the C#/.NET threat landscape, with dates, CVE numbers, and real incidents.
What are the most common C# and .NET security vulnerabilities?
The most common C#/.NET vulnerabilities are insecure deserialization, SQL injection through raw query strings, and hardcoded secrets in configuration files. Insecure deserialization is the most C#-specific of the three: BinaryFormatter, NetDataContractSerializer, and LosFormatter all execute arbitrary type construction from untrusted byte streams, which is how gadget-chain exploits achieve remote code execution without ever touching a memory-safety bug. SQL injection persists because Dapper and raw ADO.NET calls make string concatenation the path of least resistance, even though Entity Framework's parameterized LINQ has existed since .NET 3.5. Secrets sprawl shows up constantly in appsettings.json and web.config connection strings committed to source control — GitGuardian's 2024 State of Secrets Sprawl report logged over 12.7 million hardcoded secrets across public GitHub repositories in 2023 alone, and .NET config files are a recurring pattern in that data set. None of these require a novel attack technique; they require someone to actually look. XML parsing is the fourth recurring offender: XmlDocument and XmlTextReader resolve external entities by default in older .NET Framework versions, which is how XXE injection lets an attacker read local files or pivot into internal network requests through a feature nobody remembers enabling.
How exposed is the NuGet package ecosystem to supply chain attacks?
The NuGet ecosystem is exposed enough that researchers have caught multiple live malicious-package campaigns since 2023, and package count alone makes manual review impractical. In November 2023, ReversingLabs disclosed a campaign of more than 60 malicious or suspicious NuGet packages, some using a technique called IL weaving to inject malicious logic directly into a package's compiled intermediate language rather than its source-visible code — a technique specifically designed to defeat manual code review of NuGet package pages. One package in that campaign, SqzrFramework480, impersonated an industrial camera SDK. Separately, in August 2023 the widely used mocking library Moq shipped version 4.20.0 bundled with SponsorLink, a closed-source binary that read and hashed developer email addresses from local git configuration without clear disclosure — not malware, but a real demonstration that a dependency you trust can change behavior silently in a minor version bump. NuGet.org responded by mandating package signing and, in 2023, tightening publisher 2FA requirements, but neither control stops a compromised maintainer account from pushing a "legitimate" update. Typosquatting compounds the problem: security researchers have repeatedly found NuGet packages with names like popular libraries misspelled by a single character, banking on a developer's dotnet add package typo to land malicious code inside a build with no further user interaction required.
Which .NET CVEs from the last two years should security teams prioritize?
Security teams should prioritize CVE-2024-0057, a .NET security feature bypass that Microsoft patched in its January 2024 Patch Tuesday release, because it allowed attackers to bypass X.509 certificate chain validation and potentially spoof trusted, signed software — a direct threat to any .NET app that relies on certificate pinning or code-signing checks. It carried a CVSS base score in the 8.1 range and affected .NET Framework and .NET 8 alike. Teams should also track CVE-2024-38095, an ASP.NET Core denial-of-service issue patched in Microsoft's July 2024 update batch, since ASP.NET Core underpins the majority of modern internet-facing C# services. And legacy .NET Framework shops shouldn't forget CVE-2017-8759, a SOAP WSDL parser code-injection vulnerability that FinFisher malware operators exploited in the wild before Microsoft's September 2017 patch — it's a reminder that unpatched .NET Framework 4.x installations, still common in regulated industries running line-of-business apps, remain exploitable years after disclosure. Reachability matters more than CVE count here: most environments run one or two of these paths, not all of them. It's also worth noting that Microsoft ships .NET security patches on a predictable monthly Patch Tuesday cadence, which means the real risk factor for most teams isn't discovery speed — it's the gap between "patch available" and "patch deployed" across every service still running an unsupported .NET Framework 4.x or an out-of-support .NET version — .NET 7 reached end of support in May 2024, and .NET 6 followed that November.
Why did Microsoft deprecate BinaryFormatter, and does it still put you at risk?
Microsoft deprecated BinaryFormatter because it cannot be made safe against insecure deserialization attacks, full stop — there is no allow-list or sandboxing mode that closes the gadget-chain risk entirely. Microsoft began marking it obsolete starting with .NET 5 in 2020, added build-time warnings (SYSLIB0011) in .NET 5 through 8, and removed it by default for most application types in .NET 9, released in November 2024. It still puts teams at risk because .NET Framework 4.x — which Microsoft continues to support and which millions of enterprise line-of-business apps still run on — never removed BinaryFormatter, and organizations migrating to .NET 8 or 9 can still explicitly re-enable it via a compatibility switch. If your CI pipeline doesn't flag BinaryFormatter.Deserialize() calls or the [Serializable] gadget-chain-prone types that feed them, an internal migration to a newer .NET version won't automatically close this gap.
What does the SolarWinds Sunburst attack teach us about .NET supply chain risk?
The SolarWinds Sunburst attack teaches us that a single compromised .NET build step can silently backdoor tens of thousands of downstream customers before anyone notices. Between March and June 2020, attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a legitimate signed .NET assembly, during SolarWinds' own build process — not by compromising a public package registry, but by compromising the build pipeline itself. The tampered DLL shipped through official, digitally signed software updates to an estimated 18,000 organizations, including US federal agencies, before FireEye discovered the intrusion in December 2020. The lesson for C#/.NET teams specifically: code signing verifies that a binary hasn't changed since signing, not that what was signed was trustworthy in the first place. An SBOM generated at build time, tied to the actual compiled assemblies rather than just the NuGet manifest, is what would have made that specific tampering detectable sooner.
How Safeguard Helps
Safeguard maps the real attack surface in C# and .NET codebases with reachability analysis, so a BinaryFormatter gadget chain or a vulnerable NuGet transitive dependency only pages your team when it's actually reachable from an entry point — not every CVE match in a lockfile. Griffin, Safeguard's AI reasoning engine, reads the call graph and the vulnerable package's actual code path to explain, in plain language, whether a given finding like CVE-2024-0057 or a flagged deserialization sink is exploitable in your specific service. Safeguard generates and ingests SBOMs at build time across .NET Framework and .NET (Core) targets, giving you the asset-level visibility that would have caught a Sunburst-style build tampering event faster than a signature check alone. When a fix is available, Safeguard opens an auto-fix pull request with the patched NuGet version and the exact diff, so remediation ships in minutes instead of sitting in a backlog.