CVE-2026-62871: .NET WPF Heap Overflow Enables Local Code Execution

On August 11, 2026, Microsoft disclosed CVE-2026-62871, a High-severity .NET vulnerability: a heap-based out-of-bounds write in Windows Presentation Foundation (WPF), the desktop UI framework that ships in the .NET Windows Desktop runtime. Microsoft, the assigning CNA, scores it 7.8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). The bug (CWE-787, Out-of-bounds Write, and CWE-122, Heap-based Buffer Overflow) lives in WPF's native TrueType font subsetting code: a crafted font drives several unsigned 16-bit loop counters past their last valid index, wrapping the increment back to zero and writing outside the allocated heap buffer. Affected are .NET 8.0.0 through 8.0.29, .NET 9.0.0 through 9.0.18, and .NET 10.0.0 through 10.0.10, fixed in 8.0.30, 9.0.19, and 10.0.11 respectively. The advisory does not assess end-of-life lines. HeroDevs has: .NET 6 is confirmed affected from 6.0.0 through 6.0.43 with no OSS fix available, and the vulnerability is already resolved in NES for .NET 6.0.44.

‍

Affected and unsupported? See NES for .NET.

‍

What is CVE-2026-62871?

CVE-2026-62871 is a memory-corruption vulnerability in WPF, disclosed through the dotnet/wpf security advisory GHSA-vg44-h755-9hw7 and the MSRC update guide as part of the .NET August 2026 servicing release. Microsoft credits three researchers with the report: an anonymous finder, Ky0toFu, and kai63001.

‍

The weakness classification tells you the shape of the bug, and the HeroDevs vulnerability directory analysis tells you where it lives. The flaw is in WPF's native TrueType subsetting code, the component that rewrites font tables when a font is embedded in or extracted from a document. Several table walks in that code use unsigned 16-bit counters that are incremented without first checking headroom against the table's real extent. A hostile font supplies counts and offsets that push a counter past its last valid index, the increment wraps back to zero, and the subsequent write lands outside the allocated buffer, on the heap (CWE-122 via CWE-787). Microsoft's advisory identifies the component only as Windows Presentation Foundation, and the fix shipped in the Microsoft.WindowsDesktop.App.Runtime packages rather than as a public source commit.

‍

The reachability condition follows directly from the mechanism: the subsetter runs whenever a document embeds or subsets a font. Any WPF application that opens, renders, or prints untrusted documents should be treated as reachable, whether or not it does anything font-related on purpose.

‍

Two scoping facts matter for triage. First, this is Windows-only: the affected packages are Microsoft.WindowsDesktop.App.Runtime.win-x64, win-x86, and win-arm64, and WPF does not exist on Linux or macOS. Some third-party aggregators list macOS and Linux as affected platforms; the upstream advisory does not. Second, exposure follows the Windows Desktop runtime, not .NET in general. A Linux container running ASP.NET Core is not exposed through this bug. A Windows desktop fleet running WPF line-of-business applications is.

‍

Visual Studio is also affected because it bundles the .NET SDK and runtimes: Visual Studio 2022 versions 17.14.0 through 17.14.37 and Visual Studio 2026 versions 18.8.0 through 18.8.2, fixed in 17.14.38 and 18.8.3.

‍

Severity and exploit conditions

Microsoft scored CVE-2026-62871 at 7.8, High. NVD has analyzed the CVE and carries Microsoft's vector; no divergent second score has been published.

The prerequisites are a Windows machine running an affected Windows Desktop runtime, a WPF application that processes attacker-supplied content, and a user who opens that content. That combination describes a very ordinary phishing chain against any organization with a WPF desktop estate.

‍

On exploitation: no public proof of concept exists as of this writing, CVE-2026-62871 is not listed in the CISA Known Exploited Vulnerabilities catalog, and no active exploitation has been reported. Microsoft's own temporal metrics rate exploit maturity as Unproven, and CISA's SSVC assessment in the NVD record lists exploitation as none, automatable as no, and technical impact as total. That last field is the one to weigh: if this bug is exploited, the outcome is full compromise of the user context, not a crash.

‍

The deployment-model gap: who actually picks up the fix

For .NET runtime CVEs, the patch mechanics matter as much as the patch. There are three cases, and they behave differently.

‍

Framework-dependent applications resolve the Windows Desktop runtime at launch from the machine-wide installation. These pick up the fix when the machine's runtime is updated to 8.0.30, 9.0.19, or 10.0.11, through Microsoft Update, WSUS, or a direct runtime installer. One update per machine covers every framework-dependent WPF app on it.

‍

Self-contained and single-file deployments carry their own copy of the runtime inside the application directory. Updating the machine does nothing for them. Each one must be rebuilt with a patched SDK and redeployed. In most enterprises these are the deployments that stay vulnerable for months, because nobody owns the rebuild.

‍

Vendor-shipped WPF applications are self-contained deployments you cannot rebuild. Inventory them, check what runtime version they embed, and push the vendor for an updated build.

‍

Verify what is actually on a machine rather than trusting deployment records. dotnet --list-runtimes shows installed Windows Desktop runtimes; for self-contained apps, check the version resource on the bundled PresentationCore.dll or the .NETCoreApp version in the application's runtimeconfig.json.

‍

What an attacker can do

A successful exploit executes arbitrary code in the context of the user who opened the crafted content. Concretely, an attacker who lands this on a corporate workstation can:

• Read and exfiltrate everything the user's account can reach: local files, mapped network shares, cached credentials, browser session tokens, and email.
• Establish persistence in the user context through scheduled tasks, startup entries, or implants in user-writable paths, none of which require elevation.
• Use the workstation as a pivot for lateral movement, since the code runs as a legitimate domain user on a domain-joined machine.
• Chain into an elevation-of-privilege bug to reach SYSTEM. Microsoft classifies CVE-2026-62871 itself as an elevation-of-privilege issue precisely because attacker code executing in another user's context is a privilege the attacker did not have.

The user-interaction requirement shapes the delivery, not the outcome. The trigger is a hostile TrueType font, and fonts travel inside documents, so the delivery is a document with an embedded font sent to anyone whose WPF application will open, render, or print it. Phishing a user into opening a file is the most rehearsed move in the attacker playbook, and document viewers, report generators, and print pipelines built on WPF are the natural targets.

‍

Who is affected?

Affected versions, per the upstream advisory, with the end-of-life lines the advisory does not assess. Support dates are from Microsoft's .NET support policy and endoflife.date.

The end-of-life rows deserve a plain statement. Microsoft's advisory covers 8.0, 9.0, and 10.0 because those are the lines Microsoft services, not because older lines were evaluated and cleared. WPF has shipped in the Windows Desktop runtime since .NET Core 3.0, and the desktop applications most likely to still be running .NET 6 or 7 are exactly the long-lived internal WPF tools that nobody has budget to migrate. For .NET 6, HeroDevs closed that gap: the vulnerability directory entry confirms Microsoft.WindowsDesktop.App 6.0.0 through 6.0.43 is affected, and NES for .NET 6.0.44 resolves it. For .NET 7 and .NET Core 3.x, absence from the advisory is absence of assessment, not absence of risk.

‍

Also affected: Visual Studio 2022 17.14.0 through 17.14.37 (fixed in 17.14.38) and Visual Studio 2026 18.8.0 through 18.8.2 (fixed in 18.8.3), which bundle the affected runtimes and SDKs.

‍

Mitigation guidance

‍

Related CVEs

CVE-2026-62871 shipped alongside nine other .NET CVEs in the August 2026 servicing release. The ones worth tracking with it:

• CVE-2026-62897: .NET remote code execution, fixed in the same 8.0.30 / 9.0.19 / 10.0.11 releases.
• CVE-2026-70354: .NET Core remote code execution, same batch and same fix versions.
• CVE-2026-62886: .NET elevation of privilege, also addressed in the August update.
• CVE-2026-62902: .NET information disclosure from the same release.

‍

If you are patching for CVE-2026-62871, take the whole August update: the runtime releases are cumulative, so 8.0.30, 9.0.19, and 10.0.11 close all ten at once.

‍

For the broader pattern of .NET servicing releases leaving end-of-life lines behind, see our July 2026 .NET Patch Tuesday breakdown, the CVE-2026-32178 SMTP injection analysis, and our look at the .NET 8 and 9 end-of-life security event coming this November.

‍

Taking action

If your WPF estate runs on .NET 8, 9, or 10, update to 8.0.30, 9.0.19, or 10.0.11, and hunt down the self-contained deployments that machine updates will never touch. Update Visual Studio on developer machines in the same pass.

‍

Then look at the calendar. .NET 8 and .NET 9 both reach end of life on November 10, 2026, thirteen weeks after this advisory. Today, a WPF memory-corruption bug on those lines gets a same-day Microsoft patch. After November 10, the next one lands the way this one landed for .NET 6 and 7: no upstream assessment, no OSS fix, and a fleet of desktop applications processing untrusted documents on a runtime nobody upstream is watching.

‍

That gap is already closed for .NET 6. HeroDevs confirmed the affected range and shipped the fix in NES for .NET 6.0.44. NES for .NET delivers drop-in replacement builds that resolve vulnerabilities on end-of-life .NET lines, so teams running WPF applications on .NET 6, 7, or soon 8 and 9 stay protected without a forced migration. See NES for .NET to confirm coverage for your versions, or talk to our team about scoping your .NET desktop estate before November.