Automated Threat Modeling

Overview of CVE-2026-114159: Heap Buffer Overflow in the Visual Studio and .NET Native PDB Reader

CVE-2026-114159 is a CVSS 8.8 heap buffer overflow in Microsoft.DiaSymReader.Native, triggered by an oversized Portable PDB document name, that affects Visual Studio and .NET 8 through 11 on Windows. This summary covers the patch and the deployment steps needed to apply the fix.

CVE Analysis

8 min read

Gaurav Sarraf
Gaurav Sarraf

2026-11-10

Overview of CVE-2026-114159: Heap Buffer Overflow in the Visual Studio and .NET Native PDB Reader
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A malformed debugging symbol file is enough to corrupt heap memory inside the native PDB reader that ships with .NET on Windows, and the runtime's own stack trace machinery can reach that code path. Microsoft titled CVE-2026-114159 as a Visual Studio remote code execution issue, but the fixed builds span the .NET 8, 9, 10 and 11 runtimes, every SDK feature band, and any self-contained application that carries its own copy of the runtime.

The vulnerability was published on November 10, 2026 with a CVSS v3.1 base score of 8.8 and is classified as CWE-122 (heap-based buffer overflow). Below, we summarize what the advisory says about the trigger, why patching it correctly takes more than one installer run, and where the public records disagree.

Technical information

Root cause

The flaw lives in Microsoft.DiaSymReader.Native, the closed-source native symbol (PDB) reader that ships with .NET on Windows. Microsoft's advisory describes the root cause in a single sentence: an oversized Portable PDB document name can be truncated during allocation and cause a heap write outside the buffer.

This is a familiar native code pattern. The reader computes a buffer size from the document name length recorded in the PDB file, and that size is truncated (shortened) on its way to the allocator. The resulting heap buffer is smaller than the name. When the full name is then copied in, the write runs past the end of the allocation. MITRE defines CWE-122 as writing beyond a buffer allocated on the heap, which is exactly what happens here.

Microsoft states that the bug triggers while the native reader is being initialized with such a PDB, not during some later lookup.

Reachability through the native reader fallback

The runtime can reach this code too. On Windows, the runtime's native stack trace reader can reach the vulnerable initialization through a native reader fallback, which is selected based on PE metadata. That fallback is what connects an apparent developer tooling bug to exposure in the .NET runtime itself.

The advisory is careful about scope:

  • Exposure requires the described PDB reading operation to occur with affected components.
  • The presence of the reader does not, by itself, make every application or every symbol reading path vulnerable.
  • Exposed architectures are Windows x86, x64 and Arm64.

During triage, then, it is not enough to check whether Visual Studio or a .NET runtime is installed. Check whether affected processes perform native PDB reader initialization on untrusted symbol data.

CVSS vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

The vector combines a network attack vector, low complexity and no required privileges with required user interaction. Confidentiality, integrity and availability impacts are all rated High, with scope unchanged. The vector does not identify a specific exposed network service, nor does it describe the user action involved, so this should not be characterized as a zero-click, unauthenticated network attack.

Attack flow as documented

Based strictly on the advisory and the CVSS metadata, the documented sequence looks like this:

  1. An attacker produces a Portable PDB containing an oversized document name.
  2. The file reaches the victim environment over a network, and some user interaction is required for it to be processed (the advisory does not specify what that interaction is).
  3. An affected process initializes Microsoft.DiaSymReader.Native with that PDB, for example via the runtime's native stack trace reader taking the native reader fallback selected by PE metadata.
  4. The allocation size derived from the name length is truncated, the buffer is undersized, and copying the full name writes beyond the heap allocation.
  5. Microsoft rates the resulting heap corruption as potentially leading to code execution with High impact across confidentiality, integrity and availability.

What the advisory does not tell us

The reviewed material does not include an exploit payload, the length threshold that triggers truncation, the exact allocation arithmetic, or a demonstrated path from heap corruption to code execution. It also does not explicitly require a malicious project, a build step, or a listening service. Claims of automatic exploitation through any project, attachment or service would go beyond the available evidence.

Exploitation status

Senserva reproduces Microsoft's fields as "Exploited: No" and "Publicly disclosed: No". cve.now reports no tracked public exploit code and no listing in CISA's Known Exploited Vulnerabilities catalog. No threat actor, campaign, or indicators are identified. None of this shows that exploitation has not happened, only that none has been reported, and the remediation steps below apply either way.

Patch information

Microsoft fixed CVE-2026-114159 in the November 10, 2026 (Patch Tuesday) .NET servicing release. The fix is delivered only as updated binaries. Microsoft did not publish a source commit or diff, so there is no code to show. The CVE-specific entry in the dotnet/runtime repository is a security advisory, not a pull request.

What the fix most likely does. Because the source is not public, this is inference from Microsoft's description: the patched reader should no longer allow an oversized length to shrink silently before allocation. It would either compute the allocation size in a sufficiently wide type or reject a document name whose length does not fit, before any copy occurs. The practical effect is that the buffer size and the number of bytes written can no longer diverge.

Fixed builds (Windows x86, x64, Arm64):

  • .NET 8.0: runtime 8.0.34; SDK feature bands 8.0.134 and 8.0.428
  • .NET 9.0: runtime 9.0.23; SDK feature bands 9.0.124 and 9.0.321
  • .NET 10.0: runtime 10.0.15; SDK feature bands 10.0.115 and 10.0.404
  • .NET 11.0: runtime 11.0.0 (GA; previews and release candidates are affected); SDK 11.0.100

For self-contained apps, the same fix ships in the Microsoft.NETCore.App.Runtime.win-x86, Microsoft.NETCore.App.Runtime.win-x64 and Microsoft.NETCore.App.Runtime.win-arm64 NuGet packages at those runtime versions. NVD's record, using Microsoft's data, also lists Visual Studio 2026 version 18.11 as affected before 18.11.4, consistent with the advisory's note that SDKs installed through Visual Studio are updated by updating Visual Studio.

Applying the patch correctly. The fix lives in a native DLL that ships with each runtime, so deployment details matter:

  • Machine-wide installs: update the runtime and update each installed SDK feature band separately. Updating one band does not patch the others.
  • Self-contained apps: these carry their own copy of the runtime, and a machine runtime update does not touch it. Retarget to the patched runtime package, rebuild and redeploy.
  • Running processes: restart any process that already loaded the old native reader. Until it restarts, it keeps executing the vulnerable code in memory.
  • Visual Studio: if an SDK came with Visual Studio, update Visual Studio too. Microsoft's documented route is to close Visual Studio, open Visual Studio Installer, update the installer if prompted, select the installation and choose Update (or use Help, then Check for Updates inside the IDE), restarting if requested.

The .NET 8.0.34, 9.0.23, 10.0.15 and 11.0.0 release notes and Microsoft's November 2026 servicing blog post all list CVE-2026-114159 among the fixes in these builds. The advisory specifies no workaround beyond these updates.

Affected systems and versions

  • .NET 8 on Windows: 8.0.0 up to, but not including, 8.0.34
  • .NET 9 on Windows: 9.0.0 up to, but not including, 9.0.23
  • .NET 10 on Windows: 10.0.0 up to, but not including, 10.0.15
  • .NET 11 on Windows: all previews (starting with preview 1) and release candidates before 11.0.0 GA
  • Runtime packages: Microsoft.NETCore.App.Runtime.win-x86, Microsoft.NETCore.App.Runtime.win-x64 and Microsoft.NETCore.App.Runtime.win-arm64 below the fixed runtime versions above, including copies embedded in self-contained applications
  • Visual Studio 2026 version 18.11: NVD records 18.11.0 up to, but not including, 18.11.4. That 18.11.4 is the recorded upper boundary, not an independently stated fix declaration.
  • Visual Studio 2026 version 18.12: the CVE record lists 18.12.0 as affected, while Senserva lists 18.12.0 as fixed. The records conflict, so we would not treat that version number alone as proof of remediation.
  • Architectures: Windows x86, x64 and Arm64, when applications perform the vulnerable PDB reading operation with affected components.

Visual Studio Code is not listed as affected in the reviewed records.

Vendor security history

The most relevant public assessment of Microsoft's security track record in the material we reviewed is the Cyber Safety Review Board's report on the 2023 Exchange Online intrusion. The CSRB described that incident as preventable, said Microsoft's security culture was inadequate and required an overhaul, and cited a cascade of avoidable errors. It attributed that separate intrusion to an espionage-focused actor with ties to the People's Republic of China. This is historical context only. No attribution connects that actor to CVE-2026-114159.

Since then, Microsoft has reported progress under its Secure Future Initiative. The July 2026 report claims 99.97% of user and device pairs protected by phishing-resistant multifactor authentication, 83% of pipelines prevented from reaching unapproved package endpoints, more than 550,000 critical and high-risk open-source vulnerabilities remediated, and about 3M container vulnerabilities patched per month through automation. These are company-reported organizational metrics, not measurements of customer patch coverage. For this CVE, the meaningful measure is whether the runtime, SDK, Visual Studio and redeployment steps above are actually completed.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Gerrit
  • CVS
  • Jira
  • Linear
  • Slack
  • Security Compass
Explore integrations
Security magnifying glass visualization