July 2026 .NET Patch Tuesday: 14 CVEs Also Affect .NET 6

On July 14, 2026, Microsoft's combined .NET servicing release fixed seventeen CVEs across .NET 8, .NET 9, and .NET 10, shipping in versions 8.0.29, 9.0.18, and 10.0.10. Microsoft's advisory table lists exactly three affected product lines: .NET 10.0, .NET 9.0, and .NET 8.0. What the table does not list is .NET 6, which reached end of life on November 12, 2024 and is no longer assessed in Microsoft's applies-to column. HeroDevs assessed the July disclosures against the .NET 6 codebase: fourteen of the seventeen affect .NET 6, spanning authentication bypass, signature forgery, code execution, and denial of service. All fourteen are remediated in NES for .NET 6.0.43. The remaining three carry no .NET 6 security advisory.

Affected and unsupported? See NES for .NET.

‍

The CVE metadata problem, in one advisory

Before the list, one CVE from this batch is worth a closer look, because it is a live example of why you should track vulnerabilities by identifier and CVSS vector rather than by title.

CVE-2026-50646 is a WPF XAML parsing flaw. Microsoft's own published records describe it three different ways. NVD's entry describes a protection mechanism failure (CWE-693) that permits an unauthorized attacker to execute code locally. Microsoft Support's Windows update documentation for the same July release, including KB5100998, classifies it as an elevation of privilege vulnerability. And third-party vulnerability feeds reproduce an MSRC-facing ".NET Framework Remote Code Execution Vulnerability" title. The scored vector settles it: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, a 7.8 High with a local attack vector and required user interaction. There is no network attack path, whatever the title implies.

The practical consequence: a scanner or ticketing workflow keyed on advisory titles can misclassify this CVE, misroute its priority, or confuse it with CVE-2026-50649, the adjacent WPF CVE that Microsoft Support consistently does label remote code execution. When the vendor's own metadata disagrees with itself on a current advisory, the identifier and the vector are the only stable handles. That principle applies to every entry below.

The same batch contains a second divergence worth flagging. For CVE-2026-47304, the XML signature forgery flaw, Microsoft's CNA assessment scores 8.1 High (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), while NVD's independent analysis scores 9.8 Critical, differing only on attack complexity. If your risk tooling pulls from NVD, this one lands in your Critical queue.

‍

The fourteen CVEs that affect .NET 6

Every CVE below affects .NET 6 and is fixed in NES for .NET 6.0.43. Microsoft's CVSS 3.1 assessments are shown; the WPF entries require a local attack vector with user interaction, and the two ASP.NET Core Negotiate entries and the SMTP entry require an authenticated attacker (PR:L).

Four component families account for all fourteen.

‍

ASP.NET Core Negotiate authentication

CVE-2026-47300 and CVE-2026-47303 both live in the opt-in Microsoft.AspNetCore.Authentication.Negotiate package when LDAP role-claim resolution is enabled. In 47300, the internal LdapAdapter builds an LDAP search filter from the authenticated principal name without validating the Kerberos realm or escaping LDAP metacharacters, so an attacker presenting a bare or foreign-realm principal whose account name matches a privileged domain account can inherit that account's group memberships as role claims. In 47303, nested group resolution matches a group's CN against another group's sAMAccountName, two independently settable Active Directory attributes, so an authenticated attacker who can influence a group name can attach a privileged group's role claims to the wrong object. Both are role-based authorization compromises against Windows-authenticated intranet applications, exactly the kind of internal line-of-business app most likely to still be running ASP.NET Core 6.

System.Security.Cryptography.Xml

Five CVEs (47302, 47304, 50525, 50527, 50648) target the XML Encryption and XML Signature stack. The standout is CVE-2026-47304: when a signature is verified with a keyed hash algorithm, the library compares only as many bytes as the attacker-supplied signature contains, so a truncated or zero-length HMAC can match a prefix of the real value and pass verification. That is signature forgery against anything consuming signed XML, including SAML-style assertions. The other four are resource-exhaustion flaws: unbounded transform chains, unbounded EncryptedData elements, per-transform state accumulation, and recursive type-name resolution that exhausts the call stack. On .NET 6 this component ships as the opt-in System.Security.Cryptography.Xml NuGet package rather than in the shared framework, so exposure depends on your dependency graph, not just your runtime version. Versions 6.0.0 through 6.0.1 of the package are affected.

WPF XAML parsing

CVE-2026-50646, CVE-2026-50649, and CVE-2026-50650 were reported separately but share one root cause: certain embedded-XAML load paths, such as ink clipboard content and TextTree undo, never opt into WPF's restrictive XAML reader and instead parse attacker-controllable markup with the permissive reader. Because XAML instantiates object graphs as it parses, a crafted payload can construct types like ObjectDataProvider that invoke arbitrary methods, executing code with the privileges of the host application. Exploitation is local and requires a user to open or load the crafted content. All three are resolved by a single restrictive-reader hardening in NES for .NET 6.0.43.

Runtime networking and cryptography

The remaining four sit in the shared framework itself, so every .NET 6 application carries them regardless of package references. CVE-2026-50528 lets an attacker bypass a required Extended Protection channel-binding check in server-side NegotiateStream on non-Windows hosts and relay authenticated Negotiate/NTLM credentials. CVE-2026-50651 lets a malicious or compromised HTTP/2 server exhaust the memory of a client application through SocketsHttpHandler: a flaw in the outbound client stack, not Kestrel. CVE-2026-57108 crashes applications that read a UPN from an attacker-supplied X.509 certificate on Linux and macOS (Windows uses the CNG backend and is unaffected). And CVE-2026-50659 lets an authenticated sender smuggle a message-terminating sequence past System.Net.Mail's outbound dot-stuffing encoder to inject SMTP commands or a second spoofed message.

‍

Who is affected?

.NET 6 reached end of life on November 12, 2024, per the official .NET support policy. It receives no upstream fixes for any of these CVEs, and it will receive none for whatever August discloses.

‍

Mitigation guidance

Migration timelines rarely bend to Patch Tuesday. ViTel Net faced the same tension between a compliance-driven security posture and a disruption-averse product roadmap; their decision framework is a useful template for regulated teams weighing the same call. A global financial enterprise made the equivalent decision for its EOL Spring infrastructure: patch the estate you have while migrating on your own schedule.

‍

Related CVEs

This batch continues two threads from earlier in 2026. CVE-2026-26171 was a prior denial-of-service flaw in the same EncryptedXml stack now carrying five new CVEs, and CVE-2026-32178 was a prior SMTP injection in System.Net.Mail, the same component as CVE-2026-50659. If those components are in your .NET 6 estate, July's disclosures widen an attack surface you were already exposed to.

For the broader timeline pressure, see The Clock Is Ticking: Preparing for the .NET 8 and 9 End-of-Life Security Event.

‍

Taking action

The July release is a preview of the next two years of .NET security economics. Microsoft fixed seventeen CVEs for supported versions; fourteen of them also live in .NET 6, where the only things standing between your estate and the advisory list are your migration schedule and your patch source. And on November 10, 2026, .NET 8 and .NET 9 join .NET 6 on the wrong side of that line.

If you run .NET 6 in production, inventory which of the four component families above your applications actually touch, prioritize the network-reachable authentication and signature flaws, and get patched: either by completing a migration to .NET 10, or with NES for .NET 6.0.43, which remediates all fourteen CVEs today with a drop-in replacement runtime. HeroDevs is a member of the .NET Foundation and publishes a full advisory for every patched CVE in the vulnerability directory, so your security team can verify every claim above against the same primary sources we used.