CVE-2026-83520
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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.
A remote code execution vulnerability (CVE-2026-83520) has been identified in Windows Presentation Foundation (WPF) fixed-document handling, where content in a crafted document can escape WPF's restricted loading mode and run code after user interaction.
Per CWE-502: Deserialization of Untrusted Data, the weakness is a product that deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. In WPF, loading XAML markup turns it into live objects, so markup an attacker controls is untrusted serialized data.
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 or fixed document in a WPF application. 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 packMicrosoft.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 High-severity vulnerability is found in RestrictiveXamlXmlReader, the reader WPF uses to load untrusted fixed-page content in .NET 6. The reader blocks types that can run code, such as ObjectDataProvider, but it still allowed elements that host their own navigation, such as Frame, WebBrowser and NavigationWindow. A fixed page could therefore embed a navigation host, and the content that host loaded did not inherit the restrictions placed on the page around it, which gave attacker-controlled markup a route out of the restricted mode.
The fix makes RestrictiveXamlXmlReader reject navigation and browser types in restrictively loaded content. PageContent now treats a page whose blocked element was removed as unloadable rather than failing, and navigation inside a frame hosted by restricted content is also loaded restrictively.
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.OptOutOfNavigationTypeRestrictiveXamlBlock 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
Dr.-Ing Ashar Javed (@soaj1664ashar) and Vincent55 Yang, as credited in Microsoft's advisory.