CVE-2026-70174

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-70174) has been identified in Windows Presentation Foundation (WPF) XPS document navigation. Microsoft describes the issue as WPF XPS hyperlink navigation bypassing URI restrictions and reaching an attacker-controlled ObjectDataProvider, enabling remote code execution after user interaction.

Per CWE-358: Improperly Implemented Security Check for Standard, the weakness is a product that does not implement, or incorrectly implements, one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.

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 follow 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 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 High-severity vulnerability is found in the navigation paths WPF uses for XPS fixed documents in .NET 6. XPS pages are loaded through a restrictive XAML reader that refuses to construct dangerous types such as ObjectDataProvider. An earlier hardening marked navigation as unsafe when it started from a fixed-page shape or glyph run carrying FixedPage.NavigateUri, so that the target page was also loaded restrictively. A Hyperlink element inside a restrictively loaded FixedPage was not covered by that check, so NavigationService could load the link's target through the permissive reader and attacker-controlled markup there could run code in the application.

The fix records which element trees were loaded restrictively, through a new RestrictiveXamlContext attached property, and NavigationService now treats any navigation raised from inside such a tree as unsafe, whatever element raised it.

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

@bbznop, Aobo Wang (@m4x_1997), Rolf Zengafinnen, Muhammad Abdul Rehman, Kevin Schmidt, Leandro Batista, nono, kayiz with Lien Phat Technology Corporation (http://lp.com.vn/) and Ky0toFu (@ky0tofu), as credited in Microsoft's advisory.