CVE-2026-26171: .NET EncryptedXml DoS Vulnerability Explained and How to Fix It

A high-severity denial-of-service vulnerability, CVE-2026-26171, was disclosed on April 14, 2026, as part of Microsoft's Patch Tuesday. The vulnerability exists in the EncryptedXml class within System.Security.Cryptography.Xml and affects all modern .NET versions. Microsoft issued patches for .NET 8, 9, and 10 the same day. However, .NET 6 which reached end of life (EOL) on November 12, 2024, will not have a patch issued for it. For teams still running .NET 6 in production, NES for .NET from HeroDevs provides a remediated package as a drop-in fix. NES for .NET 8 also resolves this vulnerability, giving enterprises on .NET with the approaching November 2026 EOL a clear path forward.

‍

What Is CVE-2026-26171?

CVE-2026-26171 is a denial-of-service vulnerability in the EncryptedXml class inside System.Security.Cryptography.Xml. The class fails to properly restrict the depth or size of XML transforms during the encryption and decryption process. By sending a specially crafted XML payload, an attacker can trigger recursive entity expansion, causing the application to enter an infinite loop or allocate excessive memory until it crashes or becomes unresponsive.

The attack requires no authentication and no user interaction. Any internet-facing application that processes XML encryption through this class is a potential target.

‍

CVSS 3.1 Score: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

The vector breaks down as follows:

• AV:N: Network-accessible. No local access required.
• AC:L: Low complexity. No special conditions required to trigger the crash.
• PR:N: No privileges required. An unauthenticated attacker can exploit this.
• UI:N: No user interaction required.
• A:H: Availability impact is High. A successful attack takes the application offline.

CWE-400 (Uncontrolled Resource Consumption) and CWE-611 (Improper Restriction of XML External Entity Reference) are both applicable. The root cause is the same issue that makes billion-laughs and XXE attacks effective: The absence of hard limits on recursive processing depth inside a trusted XML handling path.

‍

Why This Matters

Denial-of-service vulnerabilities are easy to underestimate relative to RCE or data-exfiltration bugs. That is a mistake when the attack vector is unauthenticated, low-complexity, and network-accessible.

A single crafted XML request to a vulnerable endpoint can bring down an application process. In containerized or auto-scaling environments, repeated requests can exhaust resources at scale before alerting thresholds fire. There are no secrets to steal and no sessions to hijack, but the application stops serving users.

For teams subject to compliance requirements, an unpatched CVSS 7.5 vulnerability in a production .NET application creates real exposure. Scanners including Snyk, Tenable, and Grype should flag affected versions of System.Security.Cryptography.Xml immediately. CI/CD pipelines with policy gates will block deployments. SOC 2, PCI DSS, and ISO 27001 auditors treating unpatched high-severity CVEs as findings will not accept explanations about upgrade timelines.

For teams running .NET 6, the compliance exposure is compounded. The scanner may or may not flag the CVE, because even though .NET 6 is affected, it is not in the affected version range on the CVE. The only remediation path for .NET 6 is migration to a supported .NET version or NES.

‍

Who Is Affected

‍

On .NET 8: Microsoft shipped a patch, and it is available now via NuGet and the April 2026 runtime update. With .NET 8's EOL date set for November 10, 2026, teams that cannot complete a migration to .NET 10 before that window closes face a gap. NES for .NET 8 covers CVE-2026-26171 and provides continuous remediation through and beyond EOL.

On .NET 6: The vulnerability is confirmed present. Microsoft will not issue a fix. This aligns with their documented policy: once a .NET version reaches end-of-life, security patches are no longer provided and EOL versions are not listed in CVE disclosures even when the underlying code is affected. The HeroDevs .NET team independently confirmed this CVE's presence in .NET 6 and has delivered a remediated package through NES.

This CVE does not affect .NET Framework (3.5, 4.x, 4.8.x). It is scoped to the System.Security.Cryptography.Xml NuGet package distributed with modern .NET Core.

‍

Why This Is Hard to Fix

The recommended path is straightforward for teams on supported .NET versions: update the System.Security.Cryptography.Xml package or apply the April 2026 runtime update. For supported versions, this is a package update, not an architectural change.

The problem is .NET 6. A significant portion of enterprise .NET applications still run on it in production. It was an LTS release, it was widely deployed, and the upgrade path to .NET 8 or .NET 10 is not a version bump. It often involves runtime changes, dependency resolution across the entire dependency graph, and regression testing across application surfaces that teams may not have adequately documented.

That migration takes months on a real production system. Security teams do not have months. They have the 30- or 90-day SLA windows that appear in most enterprise AppSec policies for high-severity findings. Those windows are not negotiable, and "we're working on the upgrade" does not satisfy an auditor.

This is the gap that exists for every .NET 6 team right now: a confirmed high-severity CVE, no vendor patch, and a migration timeline that extends past any reasonable remediation SLA.

‍

Technical Breakdown

The EncryptedXml class in System.Security.Cryptography.Xml processes XML documents that may contain references to transforms applied during encryption or decryption. XML transforms can themselves reference other transforms, and without enforced depth or resource limits, a crafted document can trigger recursive processing that does not terminate within finite resource bounds.

This is structurally similar to the XML entity expansion class of attacks (CWE-611), extended into the transform processing path of the XML encryption specification. The application does not need to be receiving data from an untrusted source in the obvious sense. Any endpoint that accepts XML input and passes it through the EncryptedXml decryption path, including internal APIs, message queues, or document processing pipelines, is a valid attack surface.

Detection requires checking whether the application references EncryptedXml directly or through a dependency, and verifying the package version:

grep -r "EncryptedXml" --include="*.cs"

dotnet list package | grep "System.Security.Cryptography.Xml"

Applications not using this class or package are not affected.

‍

The HeroDevs Solution

HeroDevs NES for .NET delivers remediated packages for EOL .NET versions as drop-in replacements. No migration required, no code changes, no regression risk from a version upgrade. Your application runs on the same .NET version it is on today, with the vulnerability resolved.

For .NET 6 teams, NES closes the gap that Microsoft's EOL policy leaves open. The remediated package is available now. The fix resolves CVE-2026-26171 and will continue to address subsequent CVEs as they are disclosed, on the version you are already running.

For .NET 8 teams approaching the November 2026 EOL, NES provides continuity. CVE-2026-26171 is already resolved in NES for .NET 8. When Microsoft's support window closes, the CVE remediation coverage does not.

HeroDevs is a member of the .NET Security Group, which provides advance disclosure of CVEs coordinated with Microsoft. Remediated packages are released in alignment with Patch Tuesday, so coverage is current and continuous.

‍

How to Fix It

Option 1: Upgrade

For teams on .NET 8, 9, or 10, the fix is an update to the System.Security.Cryptography.Xml NuGet package or the April 2026 runtime update. Apply the update, recompile, and redeploy.

Update via .NET CLI:

dotnet add package System.Security.Cryptography.Xml

Or apply the April 2026 cumulative .NET update through Windows Update or your package manager to pick up the patched runtime alongside the NuGet fix.

Verify runtime version after update:

‍dotnet --info

‍

Option 2: HeroDevs NES (EOL versions and .NET 8 continuity)

For teams on .NET 6, no OSS fix exists. NES for .NET delivers a remediated package as a drop-in replacement. Implementation is a package source swap, not an upgrade. The application continues running on .NET 6 with CVE-2026-26171 resolved and ongoing coverage for future CVEs.

For teams on .NET 8 planning for the November 2026 EOL, NES for .NET 8 provides the same drop-in remediation model so coverage does not lapse when Microsoft's support window closes.

‍

Taking Action

If your application is on .NET 8, 9, or 10: Apply the April 2026 update or update the System.Security.Cryptography.Xml package directly. This is a straightforward package update.

If your application is on .NET 6: There is no upstream patch and none is coming. NES for .NET is the available remediation path that does not require a full migration. It resolves CVE-2026-26171 today, satisfies scanner and audit requirements, and gives your team the runway to migrate on a timeline that reflects your actual engineering capacity.

Learn more about NES for .NET and get immediate protection for your EOL .NET applications.