CVE-2026-96229

Overview

.NET is a free, open-source, cross-platform framework for building modern apps and powerful cloud services. It consists of a runtime and a developer platform made up of tools, programming languages, and libraries for building many different types of applications.

An information disclosure vulnerability (CVE-2026-96229) has been identified in Windows Presentation Foundation (WPF) XPS document handling, which can expose a user's NetNTLMv2 credential hash to an attacker when a crafted XPS document is opened.

Per CWE-183: Permissive List of Allowed Inputs, the weakness is a protection mechanism that relies on a list of inputs explicitly allowed because they are assumed to be safe, where the list is too permissive and allows an input that is unsafe.

This issue affects WPF on .NET 6, including NES for .NET releases up to and including 6.0.46. WPF is Windows-only, and exploitation requires user interaction: a user must open a crafted XPS document in a WPF application. Code execution is not part of this issue; the impact is disclosure of the credential hash. Microsoft's advisory lists .NET 8.0, 9.0, 10.0 and the 11.0 previews as affected; .NET 6 is past end of life and is not assessed there, and HeroDevs confirmed that 6.0 carries the same code path.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Details

Module Info

• Product: Any NES for .NET 6 WPF application on Windows at version 6.0.46 or earlier.
• Affected packages: Windows Desktop shared framework (Microsoft.WindowsDesktop.App, runtime pack Microsoft.WindowsDesktop.App.Runtime.win-x64)
• Affected versions:
  
  • >= 6.0.0 <= 6.0.46
• Package manager: NuGet, Windows Installer
• GitHub repository: https://github.com/dotnet/wpf
• Published packages: Download .NET (Windows)
• Fixed in:
  
  • NES for .NET 6.0.47

Vulnerability Info

This Medium-severity vulnerability is found in RestrictiveXamlXmlReader, the reader WPF uses to load untrusted XPS and XAML content in .NET 6. Properties such as image and media sources are fetched as soon as the content is displayed. The restrictive reader accepted absolute external addresses and UNC network paths in those properties, so a document could make WPF contact an attacker-chosen server without the user clicking anything. On Windows, a request to a remote network share can carry an automatic NTLM authentication attempt, which hands the attacker a NetNTLMv2 hash of the user's credentials that can then be cracked or relayed.

The fix makes RestrictiveXamlXmlReader drop absolute non-pack URIs and UNC paths on auto-fetching properties. pack: URIs are accepted only when they point at the application's own resources or at a part of the same package being loaded. TextRange.Load now uses the restrictive reader as well.

CVE-2026-70035, CVE-2026-70174, CVE-2026-83520, CVE-2026-87697, CVE-2026-96229, CVE-2026-96232 and CVE-2026-96234 were reported separately and are addressed together by the same WPF restrictive-XAML and XPS security update in NES for .NET 6.0.47.

This vulnerability has been present since at least .NET (WPF) 6.0 and likely earlier.

Mitigation

.NET 6 is End-of-Life and will not receive any updates to address this issue. For more information see .NET and .NET Core official support policy.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected WPF applications to one of:
  • NES for .NET 6.0.47 or later
  • .NET Desktop Runtime 8.0.32 or later
  • .NET Desktop Runtime 9.0.21 or later
  • .NET Desktop Runtime 10.0.13 or later
• Leverage a commercial support partner like HeroDevs for post-EOL security support, including NES for .NET 6.0.47 or later.

The new protection is on by default. The Switch.System.Windows.Markup.OptOutOfRestrictiveXamlUriBlock AppContext switch turns it off for applications that cannot yet work with it, but doing so restores the vulnerable behavior and should only be a short-term compatibility measure.

Credits

Omar Khaleel (@omarkhalil1138), Ali Az and nono, as credited in Microsoft's advisory.