Brief Summary: CVE-2026-118745, a Heap-Based Buffer Overflow in the Native PDB Reader Behind Visual Studio and .NET

Introduction

A heap buffer overflow in the native PDB symbol reader that ships inside the .NET runtime puts Visual Studio installations, .NET SDKs, and self-contained Windows applications in scope for a remote code execution fix Microsoft released on November 10, 2026. The vulnerable library travels with the runtime instead of shipping as a standalone package. A machine that looks patched can therefore still carry an old copy inside an application folder or a long-running IDE process.

The supplied CVE data lists the vendor as unknown, but the Microsoft CNA assigned the record and Microsoft's advisory covers the affected component. Microsoft rates the issue CVSS 3.1 base 8.8 (High) and maps it to CWE-122, Heap-based Buffer Overflow. NVD published the record on November 10, 2026 and currently lists it as Awaiting Enrichment, with no separate NIST score.

Technical Information

Root cause

The affected component is Microsoft.DiaSymReader.Native, the closed-source native library that reads PDB symbol files. It ships inside the .NET runtime and reaches users through .NET runtimes, SDKs, and Visual Studio. Microsoft's advisory describes the defect in one line:

"Crafted PDB line metadata can exceed the caller-provided buffer and cause a heap out-of-bounds write."

The patch information describes the mechanics:

• The caller of the PDB line number APIs provides a heap buffer.
• The vulnerable reader trusted the line record counts stored in the PDB file and wrote that many entries into the buffer, even when the buffer was too small.
• The result is an out-of-bounds write on the heap, controlled by attacker-supplied line metadata.

Every Microsoft.DiaSymReader.Native version earlier than 18.9.1-beta1.26515.1 is affected on Windows x86, x64, and Arm64 when it reads crafted native PDBs. Platforms other than Windows are out of scope.

Two points limit the scope:

• This is a native PDB issue. The advisory does not describe the oversized Portable PDB document name mechanism associated with a different vulnerability.
• Having the component installed does not by itself mean the vulnerable operation occurs. Exposure requires an application to use the affected reader to process a crafted native PDB.

Microsoft has not published source code, a commit, or a diff, so there is no vulnerable code to show here.

Scoring

NVD and the Microsoft advisory publish this base vector:

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

• Attack vector, Network: the classification is not limited to local access, but this does not imply a listening network service.
• Attack complexity, Low and Privileges required, None: no prior authentication is a scored prerequisite.
• User interaction, Required: this is not interaction-free exploitation.
• Scope, Unchanged. Confidentiality, Integrity, Availability, High.

The advisory's temporal vector adds exploit maturity and remediation status:

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

E:U means exploitability is unproven, and RL:O means an official fix exists. The GitHub advisory page also shows a separate 7.7 severity display, while the advisory body explicitly states an 8.8 base score. We use the explicitly labeled 8.8. One upstream input described this as a critical zero day. Microsoft's own advisory does not support that characterization.

Attack flow

Microsoft identifies remote code execution as the outcome but does not publish a delivery protocol, vulnerable function name, payload structure, or complete exploit chain. The flow below combines the advisory's mechanics with clearly labeled third-party analysis.

1. Craft the file. An attacker builds a native PDB whose line metadata declares more line records than the buffer a caller will supply.
2. Deliver it. Microsoft does not specify a delivery path. Third-party analysis lists possible routes: .pdb files committed to bin/, obj/, or lib/ folders in cloned repositories, .snupkg symbol packages, and symbol servers reached through _NT_SYMBOL_PATH. These are analysis, not observed attacker behavior.
3. User interaction. Consistent with UI:R, MSRC indicates the victim has to open an attacker-supplied file.
4. Parsing. A process that uses the affected reader parses the line metadata. Third-party analysis names devenv.exe, msvsmon.exe, and dotnet.exe as likely host processes.
5. Corruption. The reader trusts the record count and writes past the end of the caller's heap buffer. Microsoft classifies the security impact as code execution. How an attacker would turn the write into control of execution has not been published.

Exploitation status

The reviewed sources establish no active exploitation and no named threat actor. Senserva reproduces Microsoft fields marking the issue as not exploited and not publicly disclosed (last revised November 10, 2026), and detection guidance citing MSRC adds an Exploitation Less Likely rating. OffSeq Threat Radar reported no evidence of exploitation, no CISA KEV listing, and no public exploit code indexed in Metasploit or Exploit DB as of a November 10, 2026 snapshot. Absence of reporting is not proof that exploitation is impossible, and the memory corruption condition is real regardless.

Patch Information

Microsoft fixed CVE-2026-118745 in its November 10, 2026 servicing release. No code diff was published. The fix is a new build of Microsoft.DiaSymReader.Native, bundled into new .NET runtimes, SDKs, and Visual Studio builds. The patched reader no longer lets attacker-controlled line metadata write past the caller's buffer. Microsoft has not said whether it rejects the record or truncates to the buffer size. Builds at or above 18.9.1-beta1.26515.1 contain the fix.

Fixed builds

• .NET 8.0 (Windows): vulnerable from 8.0.0 up to but not including 8.0.34; fixed in 8.0.34 (KB5135243)
• .NET 9.0 (Windows): vulnerable from 9.0.0 up to but not including 9.0.23; fixed in 9.0.23 (KB5135242)
• .NET 10.0 (Windows): vulnerable from 10.0.0 up to but not including 10.0.15; fixed in 10.0.15 (KB5135241)
• .NET 11.0 (Windows): vulnerable from 11.0.0-preview.1 up to but not including 11.0.0; fixed in 11.0.0
• Runtime packs for win x86, x64, and Arm64: same ranges, fixed in 8.0.34, 9.0.23, 10.0.15, and 11.0.0
• .NET SDK 8.0.1xx / 8.0.4xx: fixed in 8.0.134 / 8.0.428
• .NET SDK 9.0.1xx / 9.0.3xx: fixed in 9.0.124 / 9.0.321
• .NET SDK 10.0.1xx / 10.0.4xx: fixed in 10.0.115 / 10.0.404
• .NET SDK 11.0.1xx: fixed in 11.0.100
• Visual Studio 2026 LTSC 18.11: fixed in 18.11.4, released November 10, 2026, which lists CVE-2026-118745 under Security Advisory Notices

Why updating the machine is not always enough

Microsoft says the library is "delivered through .NET Core rather than as a standalone customer NuGet update." In practice, that means:

• Shared (framework-dependent) installs are fixed once the runtime and every installed SDK feature band are updated. Feature bands are not interchangeable, and each must reach its own fixed version. If Visual Studio installed the SDK, update Visual Studio as well.
• Self-contained apps carry their own copy of the runtime, and a machine-wide runtime update does not replace it. Update the runtime used to build the application, then rebuild and redeploy.
• Running processes that already loaded the old reader must be restarted, because the fixed DLL only takes effect on the next load.

Microsoft provides no separate workaround.

A note on Visual Studio 18.12.0

The version records for the 18.12 line conflict. The CVE record marks 18.12.0 as affected, Senserva labels it fixed, detection guidance citing MSRC names it as the fixed build, and NVD shows a malformed range that starts at and ends before 18.12.0. The Visual Studio release notes list this CVE but do not resolve the ambiguity. A third-party writeup on dev.to also lists 18.12.0 as fixed and advises bumping direct Microsoft.DiaSymReader.Native NuGet references. Microsoft's advisory says neither. Treat the official runtime, SDK, and Visual Studio 18.11.4 versions above as the authoritative fix points, and do not treat the 18.12.0 version number alone as proof of remediation.

Detection Methods

As of publication there are no public CVE-specific YARA, Sigma, Snort/Suricata, or EDR signatures, and no exploitation IoCs such as hashes, file names, C2 addresses, or log patterns. In practice, detection here means finding exposure, which is to say locating every copy of the vulnerable reader before a crafted symbol file reaches it.

1. Apply the vendor's affected component test

The dotnet/runtime advisory (GHSA-x8x8-p968-x646) defines exposure as using Microsoft.DiaSymReader.Native earlier than 18.9.1-beta1.26515.1 on Windows x86, x64, or Arm64 to read crafted native PDBs. Every check below ties back to that threshold.

2. Audit installed runtimes and SDKs

Use the fixed build numbers (8.0.34/8.0.134/8.0.428, 9.0.23/9.0.124/9.0.321, 10.0.15/10.0.115/10.0.404, 11.0.0/11.0.100, plus KB5135243, KB5135242, KB5135241) as the known-good baseline in your vulnerability management or software inventory tooling. Check each SDK feature band separately, because one patched band does not clear the others on the same machine. For Visual Studio 2026, flag 18.11 builds from 18.11.0 up to but not including 18.11.4.

3. Find embedded runtimes and bundled readers

This is the step most likely to leave gaps. Inventory should cover:

• Runtime pack references in build outputs and lock files within the affected 8.0, 9.0, 10.0, and 11.0 preview ranges. SCA tools that consume the GitHub Advisory Database can flag these automatically, since the GHSA record lists them as affected NuGet packages.
• Direct package references. A third-party writeup suggests searching packages.config, Directory.Packages.props, and *.csproj files for explicit Microsoft.DiaSymReader.Native references. This matters for custom diagnostic tools, crash analyzers, and compilers that bundle the reader.
• Binaries on disk. The same analysis names the native DLLs below. A file inventory sweep checked against the vendor threshold can surface copies in application folders, Visual Studio install directories, and CI agent images.

Microsoft.NETCore.App.Runtime.win-x86
Microsoft.NETCore.App.Runtime.win-x64
Microsoft.NETCore.App.Runtime.win-arm64

Microsoft.DiaSymReader.Native.amd64.dll
Microsoft.DiaSymReader.Native.x86.dll
Microsoft.DiaSymReader.Native.arm64.dll

4. Verify process state after patching

A host can show patched files on disk while a long-running IDE or build process still has the old DLL in memory. When you verify remediation on developer workstations and build agents, compare process start times against the patch install time.

5. Behavioral hunting (theory only)

These leads follow from the mechanics and third-party analysis. They are not validated signatures, and Microsoft has not published crash signatures, event IDs, or file indicators.

• Unexpected crashes of devenv.exe, msvsmon.exe, or dotnet.exe shortly after a repository is opened or a debug session starts
• .pdb files arriving from untrusted repositories or packages
• Symbol path settings that point at unapproved external servers
• Unusual child processes spawned by the IDE or the dotnet host

Developer machines generate a lot of legitimate PDB activity, so tune any hunt carefully. The reliable detection today is a version and inventory audit.

Affected Systems and Versions

All affected configurations are on Windows x86, x64, and Arm64:

• Microsoft.DiaSymReader.Native: all versions earlier than 18.9.1-beta1.26515.1
• .NET 8: 8.0.0 through versions before 8.0.34
• .NET 9: 9.0.0 through versions before 9.0.23
• .NET 10: 10.0.0 through versions before 10.0.15
• .NET 11: 11.0.0-preview.1 through versions before 11.0.0
• Windows runtime packs (x86, x64, Arm64): same ranges as the runtimes
• .NET SDK feature bands: 8.0.1xx before 8.0.134; 8.0.4xx before 8.0.428; 9.0.1xx before 9.0.124; 9.0.3xx before 9.0.321; 10.0.1xx before 10.0.115; 10.0.4xx before 10.0.404; 11.0.1xx before 11.0.100
• Visual Studio 2026 version 18.11: 18.11.0 through versions before 18.11.4
• Visual Studio 2026 version 18.12: 18.12.0 status is inconsistent across records (see Patch Information)
• Self-contained applications built against any affected runtime, regardless of the machine-wide runtime version

Vendor Security History

Microsoft's developer footprint makes this advisory broadly relevant. In the 2026 Stack Overflow Developer Survey, 3,643 of 13,193 respondents (27.6%) to the development environment question reported regularly using Visual Studio. That is a usage measure, not market share or a count of vulnerable installations.

For independent context on Microsoft's track record, the Cyber Safety Review Board's report on the Summer 2023 Microsoft Exchange Online intrusion, released by DHS on April 2, 2024, found the intrusion preventable and identified decisions that collectively reflected a culture deprioritizing enterprise security investment and rigorous risk management. Microsoft fully cooperated with the review. That incident is unrelated to the native PDB reader and says nothing about exploitation of this CVE.

Microsoft launched the Secure Future Initiative in November 2023 and aligned it with Zero Trust and the NIST Cybersecurity Framework. Its July 2026 progress report claims 99.97% phishing-resistant MFA coverage across users and devices, 1.4M unused Entra applications decommissioned, public access removed from 732,000 resources, and automated container patching addressing about 3M vulnerability instances monthly. These are Microsoft-reported program outcomes. They do not demonstrate that any particular deployment has received this fix.

References

• NVD entry for CVE-2026-118745
• CVE.org record for CVE-2026-118745
• Microsoft Security Update Guide entry
• GitHub Advisory Database: GHSA advisory
• dotnet/runtime security advisory
• dotnet/runtime security advisory (API record)
• dotnet/announcements issue 524
• .NET and .NET Framework November 2026 servicing updates
• Visual Studio 2026 version 18.11 release notes
• Visual Studio 2026 release notes
• Visual Studio product lifecycle and servicing
• CVE Reports writeup on dev.to
• CVE Reports analysis
• Senserva CVE summary
• OffSeq Threat Radar entry
• CISA Known Exploited Vulnerabilities Catalog
• DHS: Cyber Safety Review Board report on the Summer 2023 Exchange Online incident
• Microsoft SFI Progress Report, July 2026
• Microsoft Secure Future Initiative overview
• Stack Overflow Developer Survey 2026: technology data