CVE-2026-87697
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-87697) has been identified in Windows Presentation Foundation (WPF) XPS document handling. Microsoft describes it as WPF XPS synthetic hyperlinks, exposed through UI Automation, bypassing restrictive navigation checks and reaching attacker-controlled content, enabling remote code execution 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 document in a WPF application and activate a link in it. 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 the hyperlink handling of WPF fixed documents in .NET 6. WPF's document viewer exposes links in XPS content as logical hyperlinks so that they can be activated from the keyboard or through UI Automation as well as by mouse. When one of these synthetic hyperlinks is activated, the navigation request is raised from the page's root FixedPage rather than from the element that carries the link. NavigationService decided whether to load the target restrictively by looking for FixedPage.NavigateUri on the element that raised the request, and the root page does not carry it, so the target could be loaded through the permissive reader and run attacker-controlled markup.
The fix records which pages were loaded restrictively, through a new RestrictiveXamlContext attached property, and NavigationService now treats a navigation raised from a restrictively loaded root FixedPage as unsafe.
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.Navigation.OptOutOfRestrictiveXamlNavigationBlock 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
41ae55e9310ff27fa6f26af4727e5590, as credited in Microsoft's advisory.