CVE-2026-50646: .NET WPF XAML Parser Remote Code Execution
Certain internal XAML load paths in Windows Presentation Foundation skip the type-safe reader, letting a crafted XAML document instantiate dangerous types like ObjectDataProvider and execute…

The problem
WPF ships a RestrictiveXamlXmlReader that blocks dangerous type instantiation from untrusted markup. Several internal load paths, including ink clipboard deserialization and TextTree undo replay, bypass this guard entirely and call the permissive XamlXmlReader instead.
Because those paths accept attacker-controllable markup, an adversary can embed a crafted XAML payload inside content that reaches one of those paths. No exploit requires elevated privileges. The victim only needs to open or interact with a document, pasted content, or any WPF surface that triggers the vulnerable load path.
Proof of concept
A working proof-of-concept for CVE-2026-50646 in Microsoft.WindowsDesktop.App.Runtime.win-x64, with the exact payload below.
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="clr-namespace:System.Diagnostics;assembly=System"
xmlns:c="clr-namespace:System.Collections;assembly=mscorlib">
<ObjectDataProvider x:Key="rce" ObjectType="{x:Type d:Process}" MethodName="Start">
<ObjectDataProvider.MethodParameters>
<x:String>cmd.exe</x:String>
<x:String>/c calc.exe</x:String>
</ObjectDataProvider.MethodParameters>
</ObjectDataProvider>
</ResourceDictionary>ObjectDataProvider is a WPF binding helper that calls an arbitrary method on an arbitrary type during XAML object graph construction. When the permissive XamlXmlReader processes the payload above, it instantiates System.Diagnostics.Process and calls Start with attacker-supplied arguments, achieving code execution before the application ever touches the result.
The patch forces all previously-unguarded internal XAML load paths (ink clipboard, TextTree undo, and similar embedded-markup flows) through RestrictiveXamlXmlReader, which enforces a type allowlist and refuses to construct types like ObjectDataProvider or Process.
The root cause is CWE-693: a protection mechanism (the restrictive reader) existed and worked correctly on explicit loads, but internal paths silently opted out of it.
The fix
Update to .NET 8.0.29, .NET 9.0.18, or .NET 10.0.10. Self-contained applications must be recompiled against the patched SDK and redeployed. Run dotnet --info to confirm the installed runtime version. If your application processes untrusted XAML, always pass useRestrictiveXamlReader: true to XamlReader.Load/Parse as a defense-in-depth measure even after patching.
Reported by Kevin Gosse, 41ae55e9310ff27fa6f26af4727e5590, Ky0toFu.
Related research
- high · 7.8CVE-2026-50650CVE-2026-50650: WPF XAML Code Injection Elevation of Privilege
- highCVE-2026-48502CVE-2026-48502: MessagePack-CSharp ReadDateTime Stack Overflow via Oversized Extension Length
- high · 8.8CVE-2026-69522: Microsoft.DiaSymReader.Native Heap-based Buffer Overflow RCE
- critical · 9.8CVE-2026-62815CVE-2026-62815: MsQuic (Microsoft QUIC) Use After Free Remote Code Execution