CVE-2026-84008 + 5 .NET Crypto CVEs: SAML, CMS DoS on .NET 6

CVE-2026-84008 and five related .NET vulnerabilities, fixed in Microsoft's October 13, 2026 Patch Tuesday, have no OSS fix available on .NET 6 or .NET 7. On .NET 8 and .NET 9, these patches arrive four weeks before both lines reach end of support on November 10, 2026. All six sit in System.Security.Cryptography.Pkcs and System.Security.Cryptography.Xml, the libraries .NET uses to check CMS (Cryptographic Message Syntax) signatures and validate signed XML such as SAML responses.

The headline bug, CVE-2026-84008 (High, 7.5, CWE-407), lets an unauthenticated attacker force quadratic CPU work in SignedCms.CheckSignature with one crafted message. Three more High (7.5) bugs do the same kind of damage to signed XML: CVE-2026-96958, CVE-2026-96959, and CVE-2026-96960. CVE-2026-70162 (Medium, 5.9) is a Windows-only variant in EnvelopedCms.Decode, and CVE-2026-96222 (High, 7.4) is a certificate validation flaw in KeyInfoX509Data that Microsoft tracks as an AD FS spoofing vulnerability. Upstream fixes shipped in the 8.0.32, 9.0.21, and 10.0.13 runtimes and matching package updates.

Affected and unsupported? See Never-Ending Support (NES) for .NET.

What are CVE-2026-84008 and the other October 2026 .NET cryptography CVEs?

The October .NET servicing release (8.0.32, 9.0.21, 10.0.13) carried 45 CVEs across the three supported lines. These six are the ones that live in the two cryptography packages that parse CMS/PKCS#7 messages and XML digital signatures. That is the code that runs when your application checks an S/MIME or AS2 signature, verifies an RFC 3161 timestamp, or validates a SAML response. In almost every one of those flows, the input comes from someone you have not authenticated yet, because checking the signature is how you authenticate them.

CVE-2026-84008: Quadratic CPU in SignedCms.CheckSignature

Per the upstream advisory, SignedCms.CheckSignature can repeatedly reparse attacker-controlled X.509 data, causing unauthenticated quadratic CPU exhaustion. Microsoft classifies it as CWE-407 (Inefficient Algorithmic Complexity) and scores it 7.5 High on Windows, Linux, and macOS.

The source diff between the 8.0.31 and 8.0.32 tags in dotnet/runtime shows the mechanism. Before the fix, SignerInfo.FindSignerCertificate() resolved each signer's certificate by reading SignedCms.Certificates, and that property decoded every certificate embedded in the message into a fresh X509Certificate2 on every call. CheckSignature walks every signer and then every counter-signer, so a message carrying many signers and many embedded certificates forces signers × certificates decode operations. The attacker controls both counts. The fix adds a cached CertificateList that decodes the certificate set once and switches to dictionary lookups by subject key identifier or issuer and serial number once a message carries more than 10 certificates.

CVE-2026-70162: Quadratic attribute processing in EnvelopedCms.Decode on Windows

On Windows, EnvelopedCms.Decode can perform quadratic work while processing attacker-supplied CMS or PKCS#7 attributes, causing pre-authentication CPU exhaustion (GHSA-2fmv-rv2c-59x7). It is CWE-405 (Asymmetric Resource Consumption), scored 5.9 Medium because Microsoft rates the attack complexity High. Microsoft lists Windows as the only affected platform and does not list .NET Framework.

The fix is a one-line change in the Windows-only HelpersWindows.cs. Before the fix, decoding converted each attribute of the native message into a CryptographicAttributeObject and added it with CryptographicAttributeObjectCollection.Add. That method loops over every attribute already in the collection to merge entries that share an OID, so a message with n attributes costs on the order of n² comparisons. The 8.0.32 fix switches the call to AddWithoutMerge, which appends directly. EnvelopedCms.Decode is the first step in decrypting an inbound CMS message, so the exposed population is anything that decrypts inbound encrypted messages: S/MIME mail processing and encrypted AS2/EDI payloads are the common cases.

CVE-2026-96958, CVE-2026-96959, CVE-2026-96960: Unbounded signed XML processing

CVE-2026-96958, CVE-2026-96959, and CVE-2026-96960 share one fix. Microsoft published a single summary for all of them (GHSA-r955-8q5j-3h83, GHSA-c399-9853-6jmj, GHSA-7hqp-7c5m-4vq6): the signed XML fixes add input-depth and operation-count limits, prohibit DTD processing by default, validate entity references, bound encrypted-data candidate processing, and cap the attributes and namespaces used by C14N transforms. Each CVE carries a different weakness class, CWE-407 (Inefficient Algorithmic Complexity) for CVE-2026-96958, CWE-770 (Allocation of Resources Without Limits or Throttling) for CVE-2026-96959, and CWE-405 (Asymmetric Resource Consumption) for CVE-2026-96960, but Microsoft does not map individual limits to individual CVE IDs. All three affect System.Security.Cryptography.Xml and System.Private.Xml on every platform.

The 8.0.32 source makes the changes concrete:

• Where the library itself parses or re-parses XML (transform inputs and decrypted content), the reader moved from DtdProcessing.Parse to DtdProcessing.Prohibit. Before the fix, attacker-supplied content on those paths could carry a DOCTYPE with entity definitions and the library would expand them.
• Input documents are now rejected past a maximum nesting depth, 64 by default.
• Canonicalization now caps the attributes, and separately the namespace declarations, it renders for a single element at 512. The source comment is explicit about why: canonicalization scanned its pending render lists linearly for each candidate name, so unbounded lists made the work quadratic in the size of a single element, on a path that processes attacker-supplied documents.
• Decryption now stops after 256 encrypted elements by default.

SignedXml.CheckSignature canonicalizes the attacker-controlled SignedInfo element before it verifies the signature value. An attacker does not need a key, a certificate, or a valid signature to make your server do the expensive part.

CVE-2026-96222: KeyInfoX509Data accepts more than a certificate

Per GHSA-vrv5-2jg9-4mmr, KeyInfoX509Data can accept serialized certificate formats containing attacker-controlled chain metadata instead of requiring a plain X.509 certificate, contributing to certificate-forgery and token-spoofing paths. It is CWE-295 (Improper Certificate Validation), scored 7.4 High, and Microsoft's own title for it is "Active Directory Federation Services (AD FS) Spoofing Vulnerability."

The root cause is one constructor call. When KeyInfoX509Data loaded the <X509Certificate> elements of a signature's KeyInfo, the 8.0.31 code passed the base64-decoded bytes straight to new X509Certificate2(byte[]). That constructor sniffs the content type and accepts formats other than a bare X.509 certificate. XML Signature defines the X509Certificate element as a base64-encoded X.509 v3 certificate, nothing else. The 8.0.32 fix checks X509Certificate2.GetCertContentType and throws unless the blob is a plain certificate.

This is also why only the 8.0.x Xml package is listed. Starting in .NET 9, KeyInfoX509Data loads these elements through X509CertificateLoader.LoadCertificate, which accepts only X.509 certificate data. The .NET Framework implementation and AD FS on Windows Server are patched through the October Windows and .NET Framework updates.

Severity of the October 2026 .NET cryptography CVEs

All scores come from Microsoft as the assigning CNA. As of October 20, 2026, NVD lists CVE-2026-84008 and CVE-2026-70162 as awaiting analysis and has analyzed the other four without publishing a separate NVD score, so the Microsoft scores are authoritative.

The precondition for every CVE in this set is the same: your application hands untrusted input to SignedCms, EnvelopedCms, SignedXml, EncryptedXml, or KeyInfoX509Data. That is the normal use of these APIs. Microsoft's exploitability assessment for all six is "Exploitation Less Likely," none was publicly disclosed before release, and none appears in the CISA KEV catalog. CISA's SSVC enrichment does mark the four 7.5 denial-of-service CVEs as automatable, which matches the shape of the bugs: a single crafted message, sent repeatedly, with no session or credentials.

What changes when you install the October 2026 .NET patches

The XML fixes tighten defaults, and some legitimate inputs will now fail. Every new limit has an AppContext opt-out in the patched 8.0.32 code, which is worth knowing so that nobody on your team reaches for one under pressure:

• System.Security.Cryptography.Xml.CryptoXmlAllowDtdProcessing re-enables DTD processing on cryptographic XML input. SAML 2.0 already forbids DTDs in protocol messages, so a SAML flow that breaks here was accepting something it should not have.
• System.Security.Cryptography.Xml.CryptoXmlMaxInputDocumentDepth raises the 64-level nesting limit. Setting it to 0 removes the limit.
• System.Security.Cryptography.Xml.DangerousMaxCanonicalizationAttributesPerElement raises the 512 attribute and namespace cap. Setting it to 0 brings the quadratic behavior back.
• System.Security.Cryptography.Xml.DangerousMaxDecryptionCount raises the 256 encrypted-element cap.
• System.Security.Cryptography.Xml.AllowNonCertificateX509Data restores the pre-fix behavior for CVE-2026-96222 and accepts non-certificate blobs in X509Certificate elements again.

Each of these switches turns a fix back off. If a partner's documents trip a limit, raise that one limit to the smallest value that works, scope it to the service that needs it, and fix the document producer.

What an attacker can do with the October 2026 .NET cryptography CVEs

• Pin CPU on a SAML service provider by posting a crafted response to its assertion consumer service endpoint. Any ASP.NET Core or .NET Framework app that validates SAML with SignedXml.CheckSignature, directly or through a library built on System.Security.Cryptography.Xml, canonicalizes the attacker's XML before the signature check can reject it (CVE-2026-96958, CVE-2026-96959, CVE-2026-96960).
• Exhaust memory on endpoints that decrypt XML with EncryptedXml.DecryptDocument, such as encrypted SAML assertions, by sending documents with deep nesting, DTD-driven expansion, or large numbers of encrypted elements (CVE-2026-96959, CVE-2026-96960).
• Stall AS2/EDI receivers, S/MIME gateways, upload handlers that verify detached PKCS#7 signatures, and RFC 3161 timestamp verification (Rfc3161TimestampToken wraps SignedCms) with a message stuffed with signers, counter-signers, and embedded certificates (CVE-2026-84008).
• Do the same against Windows hosts that decrypt inbound CMS with EnvelopedCms.Decode by inflating the message's attributes (CVE-2026-70162).
• Smuggle a non-certificate blob into a signature's KeyInfo and steer which certificate data the verifier works with, which Microsoft identifies as a step toward certificate forgery and token spoofing against AD FS and other relying parties that trust the KeyInfo certificate (CVE-2026-96222).

Thread-pool starvation is the realistic failure mode for the DoS group. A handful of concurrent requests can occupy every worker, and the health checks that run on the same pool start failing next.

Which .NET versions are affected by CVE-2026-84008 and CVE-2026-96222?

CVE-2026-84008 and the related CVEs affect System.Security.Cryptography.Pkcs 8.0.0 through 8.0.1, 9.0.0 through 9.0.20, and 10.0.0 through 10.0.12, and System.Security.Cryptography.Xml 8.0.0 through 8.0.4, 9.0.0 through 9.0.20, and 10.0.0 through 10.0.12. CVE-2026-96222 affects only the 8.0.x Xml line. System.Security.Cryptography.Xml also ships inside the ASP.NET Core shared framework, both libraries ship inside the Windows Desktop shared framework, and five of the six CVEs (all but CVE-2026-70162) reach in-box .NET Framework 3.5 through 4.8.1.

You are affected if your application references either package directly or transitively, if it is an ASP.NET Core or Windows Desktop app running on an unpatched shared framework (both include System.Security.Cryptography.Xml whether or not you reference the package), or if it runs on .NET Framework. Run dotnet list package --include-transitive to find package references and dotnet --list-runtimes to check installed runtimes. Self-contained deployments carry their own copy of the libraries and must be rebuilt and redeployed.

CVE-2026-70162 applies only on Windows in every row where it appears.

AD FS is affected separately through Windows itself. Microsoft's CVE record for CVE-2026-96222 lists Windows Server 2012 R2, 2016, 2019, 2022, and 2025, plus Windows 10 versions 1607 and 1809. Windows Server 2012 R2 left extended support on October 10, 2023, which makes it the AD FS host most likely to still be running unpatched. On the supported versions, the fix ships in the October 2026 Windows security updates. Microsoft also lists Visual Studio 2022 17.14 and Visual Studio 2026 18.10 for CVE-2026-84008, CVE-2026-70162, and CVE-2026-96222, fixed in 17.14.42 and 18.10.4.

Is .NET 6 affected by CVE-2026-84008 and the October 2026 .NET cryptography CVEs?

Yes. Microsoft's advisories only assess supported versions, so .NET 6 and .NET 7 do not appear in them, and scanners keyed to those advisories will not flag them. But the final .NET 6 and .NET 7 sources (tags v6.0.36 and v7.0.20) contain the same pre-fix code the October patch replaced:

• SignerInfo resolving certificates through the re-decoding SignedCms.Certificates property (CVE-2026-84008)
• HelpersWindows.cs adding decoded attributes with the merging CryptographicAttributeObjectCollection.Add (CVE-2026-70162, Windows only)
• DtdProcessing.Parse on the cryptographic XML ingestion paths, with none of the depth, canonicalization, or decryption-count limits the October patch introduced (CVE-2026-96958, CVE-2026-96959, CVE-2026-96960)
• KeyInfoX509Data loading X509Certificate elements with the content-sniffing X509Certificate2 constructor (CVE-2026-96222)

.NET 6 reached end of support on November 12, 2024, and .NET 7 on May 14, 2024, per endoflife.date. Neither will get a Microsoft fix for any of these.

How to fix CVE-2026-84008 and the related .NET cryptography CVEs

To fix CVE-2026-84008 and the related CVEs, install .NET runtime 8.0.32, 9.0.21, or 10.0.13, update any explicit System.Security.Cryptography.Pkcs and System.Security.Cryptography.Xml package references, and apply the October 2026 Windows and .NET Framework updates. .NET 6 and .NET 7 have no OSS fix.

Related .NET CVEs

The same 8.0.32/9.0.21/10.0.13 release fixed two ASP.NET Core Kestrel vulnerabilities, CVE-2026-88092 and CVE-2026-70188, covered in our Kestrel breakdown, and a MessagePack-CSharp denial of service in SignalR, CVE-2026-92707.

This is the third round of signed XML hardening in 2026. In April, CVE-2026-26171 fixed a denial of service in EncryptedXml in the same package; see CVE-2026-26171 explained. In July, five more Patch Tuesday CVEs targeted the same XML stack, part of the fourteen July CVEs that also affect .NET 6. Each round has reached .NET 6 with no Microsoft fix.

Taking action

If you run .NET 10, install 10.0.13 and bump your package references. It is a servicing update, though the new XML limits deserve a test pass on your SAML and signed-document flows before you ship it.

If you run .NET 8 or .NET 9, patch to 8.0.32 or 9.0.21 this week. Then look at the calendar. Both lines reach end of support on November 10, 2026, and every CVE disclosed after that lands on them with no OSS fix. A move to .NET 10 is the long-term answer, but it is a migration with its own testing cycle, not a patch. For where that leaves your fleet, see preparing for the .NET 8 and 9 end-of-life security event.

If you run .NET 6, you are already in that position. All six CVEs (CVE-2026-84008, CVE-2026-70162 on Windows, CVE-2026-96958, CVE-2026-96959, CVE-2026-96960, and CVE-2026-96222) target code that is still present in the final .NET 6 release, and Microsoft will not ship a fix.

NES for .NET delivers drop-in, security-patched releases for .NET 6, .NET 8, and .NET 9, so you stay on the version your application was built against while you migrate on your own schedule. HeroDevs is a member of the .NET Security Group.