CVE-2026-118745: Remote Code Execution via Heap-Based Buffer Overflow in Microsoft Visual Studio and .NET DiaSymReader

CVE-2026-118745 is a heap-based buffer overflow vulnerability (CWE-122) affecting Microsoft Visual Studio 2026 and supported .NET runtimes (versions 8.0, 9.0, 10.0, and 11.0) on Windows platforms. The flaw resides in Microsoft.DiaSymReader.Native, a foundational native C++ dynamic link library used across the Microsoft developer ecosystem to read and interpret Windows Program Database (.pdb) debug symbol files. Because both the Visual Studio IDE and the core .NET runtime diagnostic subsystems rely on this binary to map compiled intermediate language (IL) and native instructions back to source code lines, the vulnerability exposes a broad attack surface across development and build environments.

The component is invoked automatically during routine software development lifecycle tasks. These tasks include opening a solution in Visual Studio, stepping through code in an interactive debugger, profiling execution performance, or generating stack traces with source line numbers during unhandled exception processing in a .NET application. When the symbol reader processes a .pdb file, it parses internal data streams containing module information, public symbols, and source line number tables.

Due to improper validation of header metadata within the line table stream, an attacker can construct a malformed .pdb file that triggers an out-of-bounds write on the process heap. Successful exploitation enables arbitrary code execution within the security context of the user running Visual Studio or the host .NET process. While user interaction is required to initiate the loading of the untrusted project or binary, the parsing routine itself executes automatically without additional prompts once symbol resolution begins.

The root cause of CVE-2026-118745 is an allocation size miscalculation resulting from missing integer arithmetic checks and inadequate bounds validation within Microsoft.DiaSymReader.Native. In the Microsoft PDB format (specifically MSF/PDB v7.0), debug information for individual compilation units (modules) is stored inside dedicated module streams. Each module stream contains C13 line number subsections (DEBUG_S_LINES) that map instruction offsets to source file identifiers, line numbers, and column positions.

When Microsoft.DiaSymReader.Native loads line table metadata, it reads the subsection headers to determine the total number of sequence points and line records present in the stream. The parser uses these untrusted count values from the file header to calculate the byte size required for a dynamic heap buffer allocation. However, the calculation fails to guard against integer arithmetic overflow or truncation when multiplying the record count by the internal structure size, and fails to verify that the declared record count aligns with the actual remaining bytes in the stream.

When an attacker supplies a .pdb stream containing an artificially large or mismatched line record count, the arithmetic calculation wraps around or truncates, resulting in the allocation of an undersized heap chunk. Subsequently, the deserialization loop iterates through the stream data based on the unvalidated record count or stream boundary, copying unpacked line table structures directly into the undersized buffer.

This discrepancy produces a linear or indexed out-of-bounds write past the end of the allocated heap chunk. The overflow corrupts adjacent heap metadata structures, vtable pointers, or C++ object instances residing in the process heap of devenv.exe (Visual Studio) or dotnet.exe (.NET host).

The vulnerable component, Microsoft.DiaSymReader.Native, is distributed as a compiled native binary (Microsoft.DiaSymReader.Native.amd64.dll, Microsoft.DiaSymReader.Native.x86.dll, and Microsoft.DiaSymReader.Native.arm64.dll) via NuGet packages and bundled directly inside the .NET SDK, .NET runtime shared frameworks, and Visual Studio installation directories. Because the native PDB reader implementation is maintained as a closed-source binary dependency that is ingested into the open-source dotnet/runtime and dotnet/symreader repositories during build servicing, source-level diffs of the underlying C++ parser are not publicly exposed in the GitHub release trees.

We can reconstruct the structural mechanics of the vulnerability and the corresponding logic fix by examining how C13 line subsections are processed in standard DIA symbol reader implementations:

// Conceptual representation of the vulnerable PDB line record parsing logic
HRESULT ParseLineRecords(StreamReader* pStream, uint32_t cbSubsection) {
    LineBlockHeader header;
    if (!pStream->Read(&header, sizeof(LineBlockHeader))) {
        return E_FAIL;
    }
 
    // VULNERABLE: Untrusted header.numLines is multiplied by sizeof(LineRecord)
    // without checking for 32-bit integer overflow or validating against cbSubsection.
    uint32_t allocSize = header.numLines * sizeof(InternalLineRecord);
    InternalLineRecord* pRecords = (InternalLineRecord*)HeapAlloc(GetProcessHeap(), 0, allocSize);
    if (!pRecords) {
        return E_OUTOFMEMORY;
    }
 
    // The loop reads up to header.numLines entries, writing past the end of pRecords
    // if allocSize wrapped around to a small integer.
    for (uint32_t i = 0; i < header.numLines; ++i) {
        RawLineEntry rawEntry;
        if (!pStream->Read(&rawEntry, sizeof(RawLineEntry))) {
            break;
        }
        UnpackLineEntry(&rawEntry, &pRecords[i]); // Out-of-bounds heap write
    }
    return S_OK;
}

To remediate this class of vulnerability in the November 2026 servicing update, the binary patch enforces safe integer arithmetic prior to heap allocation and validates header counts against the physical boundaries of the substream:

// Conceptual representation of the remediated bounds-checked parsing logic
HRESULT ParseLineRecordsFixed(StreamReader* pStream, uint32_t cbSubsection) {
    if (cbSubsection < sizeof(LineBlockHeader)) {
        return COR_E_BADIMAGEFORMAT;
    }
 
    LineBlockHeader header;
    if (!pStream->Read(&header, sizeof(LineBlockHeader))) {
        return E_FAIL;
    }
 
    // FIX 1: Validate that the remaining bytes in the stream can physically hold the declared entries
    uint32_t remainingStreamBytes = cbSubsection - sizeof(LineBlockHeader);
    if (header.numLines > (remainingStreamBytes / sizeof(RawLineEntry))) {
        return COR_E_BADIMAGEFORMAT;
    }
 
    // FIX 2: Use safe integer multiplication (e.g., UInt32Mult / SizeTMult) to prevent overflow
    size_t allocSize = 0;
    if (FAILED(SizeTMult((size_t)header.numLines, sizeof(InternalLineRecord), &allocSize))) {
        return COR_E_BADIMAGEFORMAT;
    }
 
    InternalLineRecord* pRecords = (InternalLineRecord*)HeapAlloc(GetProcessHeap(), 0, allocSize);
    if (!pRecords) {
        return E_OUTOFMEMORY;
    }
 
    for (uint32_t i = 0; i < header.numLines; ++i) {
        RawLineEntry rawEntry;
        if (!pStream->Read(&rawEntry, sizeof(RawLineEntry))) {
            HeapFree(GetProcessHeap(), 0, pRecords);
            return E_FAIL;
        }
        UnpackLineEntry(&rawEntry, &pRecords[i]);
    }
    return S_OK;
}

> [!NOTE] > In the .NET open-source repositories (dotnet/runtime), the remediation is delivered by updating the dependency version references for Microsoft.DiaSymReader.Native across the servicing branches (release/8.0, release/9.0, release/10.0, and release/11.0), corresponding to release tags v8.0.34, v9.0.23, v10.0.15, and v11.0.0.

Regarding fix completeness, enforcing both safe multiplication (SizeTMult) and physical stream size validation prior to allocation eliminates the integer wrap-around vector for line record arrays. However, because .pdb files use a complex multi-stream directory architecture with numerous cross-referenced index tables (such as frame data, inlinee line tables, and column records), defense-in-depth requires applying identical bounds verification across all subsection deserializers in Microsoft.DiaSymReader.Native.

Exploiting CVE-2026-118745 requires an attacker to deliver a crafted .pdb file to a target system and trigger symbol resolution within a vulnerable process. Because .pdb files are standard artifacts in software development, multiple delivery vectors exist that do not raise suspicion during normal workflows.

Primary Delivery Vectors

1. Malicious Source Repositories & Solutions: An attacker publishes a repository on a code hosting platform containing pre-compiled dependency binaries alongside a crafted .pdb file in the bin/, obj/, or lib/ directories. When a developer clones the repository and opens or debugs the solution in Visual Studio, the IDE automatically scans and loads available symbol files.
2. Compromised NuGet Packages: Attackers can distribute NuGet packages (.nupkg or symbol packages .snupkg) containing embedded or adjacent .pdb files. When a consuming .NET project builds, executes tests, or throws an exception during local development, the runtime loads the symbol file to resolve stack trace line numbers.
3. Rogue Symbol Servers: If an environment is configured to pull symbols from an external HTTP/UNC symbol server path (_NT_SYMBOL_PATH), an attacker capable of intercepting traffic or hosting a malicious symbol server can serve crafted .pdb files on demand when the debugger queries for matching GUID/Age signatures.

Exploitation Steps

Once the malicious .pdb is delivered, the attack progresses through four stages:

1. Initialization: The target application (devenv.exe, msvsmon.exe, or dotnet.exe) loads Microsoft.DiaSymReader.Native.amd64.dll via COM interop (SymBinder / ISymUnmanagedReader) to inspect debug symbols for a loaded module.
2. Heap Grooming & Trigger: The parser reads the module's line number stream. By crafting multiple module streams inside the same .pdb file, an attacker can first allocate and free controlled blocks of memory to arrange the Windows Low Fragmentation Heap (LFH) into a predictable layout before triggering the vulnerable line table allocation.
3. Out-of-Bounds Overwrite: The parser calculates the truncated buffer size, allocates a chunk in the target LFH bucket, and begins copying attacker-controlled line record structures (containing arbitrary source file offsets and line numbers) past the chunk boundary into an adjacent C++ object.
4. Control Flow Hijacking: By overwriting a virtual function table pointer (vptr) of an adjacent ISymUnmanagedMethod or ISymUnmanagedDocument instance on the heap, subsequent COM interface method calls made by the symbol reader redirect execution flow to attacker-controlled ROP gadgets, bypassing Data Execution Prevention (DEP) and executing arbitrary shellcode.

CVE-2026-118745 is rated at a CVSS v3.1 base score of 8.8 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Although exploitation requires user interaction (UI:R) in most scenarios—such as cloning a project or opening a binary—the technical impact is a complete compromise of the user environment (C:H/I:H/A:H).

Developer workstations and Continuous Integration / Continuous Deployment (CI/CD) build agents represent high-value targets within enterprise networks. A successful exploit executing inside Visual Studio or a .NET build process inherits the full permissions of the developer or build service account. On a developer workstation, this grants the attacker access to proprietary source code, local SSH keys, cloud provider credentials (e.g., Azure CLI tokens, AWS credentials), and code-signing certificates.

In automated CI/CD environments where build scripts execute unit tests, code coverage analysis, or crash dump symbolication on untrusted pull requests or third-party artifacts, the vulnerability can be triggered without interactive human intervention. Compromising a build runner enables supply chain poisoning through the injection of unauthorized code into production build artifacts.

At the time of disclosure, there are no reports of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Microsoft classifies the Exploit Code Maturity as Unproven (E:U).

Microsoft addressed CVE-2026-118745 in the November 2026 Patch Tuesday security updates by releasing updated versions of Visual Studio 2026 and the .NET runtime packages containing the patched Microsoft.DiaSymReader.Native binaries. Organizations must apply the relevant updates across all developer workstations, build servers, and production Windows hosts running .NET applications.

Patched Version Matrix

• Microsoft Visual Studio 2026 (v18.11): Upgrade to version 18.11.4 or later.
• Microsoft Visual Studio 2026 (v18.12): Upgrade to version 18.12.0 or later.
• .NET 8.0 Runtime & SDK: Upgrade to version 8.0.34 or later.
• .NET 9.0 Runtime & SDK: Upgrade to version 9.0.23 or later.
• .NET 10.0 Runtime & SDK: Upgrade to version 10.0.15 or later.
• .NET 11.0 Runtime & SDK: Upgrade to version 11.0.0 or later.

> [!IMPORTANT] > Applications that self-contain the .NET runtime or explicitly reference the Microsoft.DiaSymReader.Native NuGet package in their dependency tree (such as custom diagnostic tools, compilers, or crash analyzers) must update their package references and rebuild to incorporate the patched native DLLs.

Workarounds and Defense-in-Depth

Where immediate patching is not feasible, security teams and developers should implement the following controls to reduce exposure:

1. Enforce Visual Studio Trust Settings: Configure Visual Studio to prompt before opening untrusted locations and ensure Restricted Mode is enabled when inspecting unfamiliar repositories or downloaded solutions.
2. Sanitize External Build Inputs: Strip or delete pre-compiled .pdb files from untrusted source repositories before opening them in an IDE or building them in CI pipelines.
3. Restrict Symbol Server Paths: Audit the _NT_SYMBOL_PATH environment variable and Visual Studio debugging options to ensure symbols are only resolved from authenticated, internal symbol servers or the official Microsoft public symbol server over HTTPS.