CVE-2026-50525: Denial of Service Vulnerability in Microsoft .NET XML Cryptography Stack

The System.Security.Cryptography.Xml library provides the core implementation for XML encryption, decryption, and digital signatures within the Microsoft .NET ecosystem. This component is commonly deployed in enterprise architectures to process Security Assertion Markup Language (SAML) assertions, WS-Security SOAP headers, and generic encrypted XML files. Because these endpoints are often exposed to untrusted external networks, they present a significant attack surface.

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). In vulnerable versions of the library, the parsing engine processed incoming XML elements without tracking recursion depths or validating the resource safety of applied cryptographic transforms. Unauthenticated attackers can exploit this lack of control to target application endpoints that automatically handle XML decryption.

The resulting impact is a total loss of application availability. Depending on the vector chosen, the target process will experience 100% thread pool CPU starvation, a process-terminating Out-of-Memory (OOM) exception, or a direct runtime crash via stack overflow.

The vulnerability stems from two independent implementation defects in the XML decryption process. First, during nested parsing and canonicalization processes handled by classes such as CanonicalizationDispatcher, EncryptedData, and EncryptedKey, the library recursively traversed elements without maintaining an explicit depth threshold. If a document contained multiple layers of nested encryption references, the execution stack would grow until a process-terminating StackOverflowException was thrown.

Second, the EncryptedXml engine supported arbitrary transforms defined within <CipherReference> elements. These transforms are applied to retrieve and reconstruct the ciphertext prior to decryption. In affected versions, the engine allowed powerful, highly expressive languages including XML Path Language (XPath) and Extensible Stylesheet Language Transformations (XSLT).

Because the XSLT processor was executed with default permissive configurations, it was susceptible to infinite loop patterns and exponential memory allocation models. Attackers could supply malicious XSLT stylesheets that execute recursive templates indefinitely or define recursively expanding variables. Since the parsing environment lacked resource enforcement thresholds, this directly led to system resource exhaustion.

The security patch introduced in .NET fixes these issues by implementing a thread-static recursion tracking limit and establishing a strict whitelist of safe transform algorithms.

To prevent stack exhaustion, the patch leverages a [ThreadStatic] recursion counter (t_depth) and validates execution depth against LocalAppContextSwitches.DangerousMaxRecursionDepth, which defaults to 64. Below is the patched implementation in CanonicalizationDispatcher.cs:

    internal static class CanonicalizationDispatcher
    {
+       [ThreadStatic]
+       private static int t_depth;
+
        public static void Write(XmlNode node, StringBuilder strBuilder, DocPosition docPos, AncestralNamespaceContextManager anc)
        {
-           if (node is ICanonicalizableNode)
+           int maxDepth = LocalAppContextSwitches.DangerousMaxRecursionDepth;
+           if (maxDepth > 0 && t_depth > maxDepth)
+           { 
+               // Enforce depth validation threshold
+               throw new CryptographicException(SR.Cryptography_Xml_MaxDepthExceeded);
+           }
+
+           t_depth++;
+           try
            {
-               ((ICanonicalizableNode)node).Write(strBuilder, docPos, anc);
+               if (node is ICanonicalizableNode canonicalizableNode)
+               { 
+                   canonicalizableNode.Write(strBuilder, docPos, anc);
+               }
+               else
+               { 
+                   WriteGenericNode(node, strBuilder, docPos, anc);
+               }
            }
-           else
+           finally
            {
-               WriteGenericNode(node, strBuilder, docPos, anc);
+               t_depth--;
            }
        }

Additionally, the patch restricts allowed transforms in <CipherReference> elements. The ReferenceUsesSafeTransformMethods helper matches incoming transform algorithms against a hardcoded whitelist (DefaultSafeTransformMethods). Safe algorithms include standard base64 decoding, license transforms, and official canonicalization algorithms (such as C14N). Dangerous transforms like XSLT or XPath are rejected immediately, preventing arbitrary code execution paths in the transformation layer.

An attacker targets this vulnerability by identifying endpoints that accept and process encrypted XML input. The attack does not require prior authentication or session privileges. The exploit payloads are typically delivered as HTTP POST requests containing crafted XML structures.

In an XSLT infinite loop attack, the payload defines a stylesheet inside the <CipherReference> node. This stylesheet contains a template that recursively references itself without a termination condition. When the application receives the payload and invokes EncryptedXml.DecryptDocument(), the execution flow hangs indefinitely on a single CPU thread. By sending multiple identical requests, an attacker can exhaust all threads in the application thread pool, freezing the server.

Alternatively, an attacker can construct an XML expansion attack (similar to the Billion Laughs format) inside the XSLT block. The transform uses nested string concatenations to exponentially expand a baseline string into gigabytes of memory buffer. The resulting allocation instantly triggers an uncatchable OutOfMemoryException, which causes the host operating system to terminate the .NET process.

The exploitation of CVE-2026-50525 leads directly to a Denial of Service. The vulnerability possesses high exploitability due to its low attack complexity and the absence of user interaction or privilege requirements.

The impact is concentrated on system availability. Because .NET process crashes often affect shared application pools (such as IIS Worker Processes or Kestrel host runtimes), a successful attack can disrupt adjacent, healthy services running on the same host.

There is no recorded compromise of confidentiality or integrity associated with this vulnerability. An attacker cannot use this bug to extract data or escalate privileges directly, making the overall impact score 3.6 on the CVSS scale. The National Vulnerability Database assigns a CVSS v3.1 base score of 7.5.

The primary remediation pathway is the installation of updated .NET runtimes and SDK assemblies released by Microsoft. Administrators should upgrade systems to .NET 10.0.6, 9.0.18, or 8.0.29. If using the NuGet dependency model, the System.Security.Cryptography.Xml package must be updated to version 8.0.1 or above.

Temporary workarounds are available for environments where immediate patching is not possible. Security administrators can restrict allowable XML schemas using Web Application Firewall (WAF) deep packet inspection. Rules should be configured to detect and drop incoming payloads containing the XSLT transform identifier (http://www.w3.org/TR/1999/REC-xslt-19991116) or unexpected nested <Transform> blocks.

Additionally, developers can adjust application configuration settings to control the recursion depth limits programmatically using AppContext switches. The System.Security.Cryptography.Xml.DangerousMaxRecursionDepth property can be set to a conservative value, such as 32, within the application's initialization routine to minimize the vulnerability window.