Windows has trusted VHD files for over a decade. Since Windows 8, double-clicking one mounts it as a logical volume with no warning dialog, no “are you sure,” nothing. It behaves like opening a ZIP archive, except what’s inside can now touch kernel memory directly. That trust model just got a fresh reminder of why it deserves scrutiny: three new vulnerabilities in the NTFS driver, all reachable through a single malicious VHD, all patched in July 2026, and all worth understanding from a forensic standpoint rather than just a patching checklist.

cover

In brief

  • Sergey Tarasov of the Positive Technologies Expert Security Center (PT ESC) discovered three heap-based buffer overflow vulnerabilities in ntfs.sys: CVE-2026-50471, CVE-2026-50494, and CVE-2026-58640.
  • The flaws affect roughly 30 Windows client and server editions, from Windows 10 1607 through Windows 11 26H1, and Windows Server 2012 through Server 2025.
  • CVE-2026-50471 and CVE-2026-50494 carry a CVSS 3.1 score of 7.8; CVE-2026-58640 scores 7.3. All three require local access or user interaction, not remote network exposure.
  • The attack chain relies on a specially crafted VHD file that, once mounted, triggers an out-of-bounds heap write inside the NTFS driver, potentially leading to arbitrary code execution or SYSTEM-level privilege escalation.
  • Microsoft shipped fixes in the July 2026 cumulative updates; no public proof-of-concept or in-the-wild exploitation has been confirmed as of writing.
  • For defenders, the more useful question shifts from “did I patch” to “would I have noticed if someone tried this before I patched.”

The three vulnerabilities, briefly

All three CVEs share the same root cause pattern: ntfs.sys allocates a heap buffer based on one calculated size, then writes data using a length that doesn’t match, corrupting adjacent kernel pool memory. That’s a textbook CWE-122 heap-based buffer overflow, and it’s the same family of bug behind CVE-2025-49689, the NTFS privilege escalation Tarasov reported the year before, and the pair fixed in January 2026 under PT-2026-2690. Tarasov has been methodically working through ntfs.sys parsing logic for a while now, and it shows: this isn’t a one-off fuzzing hit, it’s a pattern of the driver mishandling attacker-influenced size calculations when it parses on-disk structures.

CVE-2026-50494 is the one Positive Technologies flags as most severe in practice. It requires only local, low-privilege authenticated access and no user interaction: an attacker with a foothold, however small, can trigger the overflow directly against mounted or processed NTFS metadata and escalate to SYSTEM. CVE-2026-50471 needs user interaction, meaning the classic “open this file” social engineering step, but leads to the same outcome. CVE-2026-58640 follows the identical mechanics with a slightly lower attack complexity rating but the same practical result: full compromise of confidentiality, integrity, and availability on the host once the overflow is triggered.

None of the three needs network exposure. That’s worth sitting with for a second, because “local attacker” framing tends to get deprioritized in patch queues behind anything labeled remote. But in a world where initial access is routinely gained through phishing, malicious attachments, or a single compromised endpoint, “local” is not a meaningful ceiling. It’s the second stage of almost every intrusion that matters.

Why VHD is such a convenient delivery mechanism

The attack path is deliberately unglamorous. A victim receives a VHD file, by email, via a messaging app, through a cloud storage link, it doesn’t matter. They double-click it. Windows Explorer treats it exactly like an archive: mount, browse, done. Nothing in the default user experience distinguishes a benign backup image from one carrying a corrupted NTFS structure engineered to overflow a heap buffer the moment the driver parses it.

This is precisely the technique APT-C-60 used in a documented campaign analyzed by Positive Technologies, where a VHDX virtual disk served as the launch vector for an entire attack chain. The format’s legitimate use cases (backups, disk imaging, large file transfer) give it a plausible cover story that a raw executable or macro-laden document doesn’t have anymore. Users have been trained, correctly, to be suspicious of .exe attachments. Nobody has run the same awareness campaign for .vhd.

Once mounted, exploitation of any of these three CVEs can, according to Positive Technologies, evade detection by security software for a meaningful window, giving an attacker room to deploy spyware, ransomware, credential stealers, or cryptomining payloads before anyone notices. That evasion angle, more than the code execution itself, is the part that should worry a DFIR practitioner. A silent kernel-mode corruption doesn’t announce itself the way a crashing userland process does.

Detection tactics: rules and indicators worth deploying now

Patching closes the door, but a mature detection posture assumes the door was open for a while before you closed it. A few concrete, deployable detections map to this specific chain.

Start with process lineage. A standard user session mounting a disk image and, shortly afterward, spawning a SYSTEM-context child process is an anomaly worth alerting on regardless of the specific CVE involved:

title: Suspicious VHD Mount Followed By Privilege Escalation
id: 8f1a2b3c-9d4e-4f5a-b6c7-1a2b3c4d5e6f
status: experimental
description: Detects mounting of a VHD/VHDX/ISO image by a non-administrative account followed by a SYSTEM-level child process, consistent with NTFS driver exploitation via CVE-2026-50471/50494/58640
references:
    - https://global.ptsecurity.com/en/about/news/
    - https://andreafortuna.org/2026/06/17/detection-as-code/
tags:
    - attack.privilege_escalation
    - attack.t1055
logsource:
    category: process_creation
    product: windows
detection:
    mount:
        Image|endswith:
            - '\Mount-DiskImage.exe'
            - '\diskpart.exe'
            - '\mountvol.exe'
        CommandLine|contains:
            - '.vhd'
            - '.vhdx'
    condition: mount
falsepositives:
    - Legitimate backup or imaging software used by administrators
level: high

Pair that with a second rule watching for the crash signature itself. A STOP 0x00000024 bugcheck referencing ntfs.sys shortly after a file-mount event is a strong indicator that a malformed structure hit the vulnerable code path, whether or not the exploit succeeded:

title: NTFS Driver Crash Following Untrusted Disk Image Mount
id: 3c4d5e6f-7a8b-49c0-9d1e-2f3a4b5c6d7e
status: experimental
logsource:
    category: application
    product: windows
    service: system
detection:
    crash:
        EventID: 1001
        Message|contains:
            - 'ntfs.sys'
            - '0x00000024'
    condition: crash
falsepositives:
    - Disk corruption unrelated to exploitation, hardware faults
level: medium

Beyond these two, a workable IOC and monitoring checklist for the current campaign includes:

  • Unexpected mounting of .vhd, .vhdx, or .iso files sourced from email attachments, browser downloads, or removable media, particularly by non-administrative accounts.
  • Windows Event IDs 55, 130, and 137 repeated in short succession on the System log, which correlate with NTFS volume integrity errors.
  • Sysmon Event ID 1 (process creation) filtered for mountvol.exe, diskpart.exe, or PowerShell Mount-DiskImage invocations targeting paths outside standard backup or imaging tool locations.
  • Sysmon Event ID 11 (file create) for .vhd/.vhdx files appearing in user-writable temp directories immediately before a mount operation.
  • Baseline your organization’s normal VHD/VHDX usage per host. On servers where mounting disk images is atypical, any occurrence is itself the alert.

If you’re building this into a proper pipeline rather than a one-off rule dropped into a SIEM console, the same Detection as Code discipline and Sigma CI/CD approach I’ve written about before applies directly here: version these rules, give each one a positive and negative test fixture, and run them through shadow mode before they start paging anyone.

The forensic angle: what the filesystem remembers

Even if an attacker manages to trigger the overflow and evade real-time detection, NTFS itself keeps records that are considerably harder to erase than the exploit payload. This is where the DFIR side of this story gets genuinely interesting, because the same driver being exploited is also the one logging the exploitation.

The USN Journal (\$Extend\$UsnJrnl), covered in more depth in NTFS artefacts for investigators, records every file system change sequentially and survives file deletion. If an attacker’s crafted VHD file was written to disk, mounted, and later deleted to cover tracks, the journal retains the create, rename, and delete events for roughly 20 days on an active volume, giving investigators a reconstructable timeline of the attack’s staging phase even after the file itself is gone.

The $LogFile, NTFS’s own transaction log, is the artefact nobody thinks to check, and exactly the one worth checking here. As I detailed in Going beneath NTFS, it records the low-level metadata transactions the driver performs, which means a heap corruption event triggered during VHD parsing can leave transactional fingerprints even when the exploit itself doesn’t crash the system outright. Combined with kernel crash dumps and WER (Windows Error Reporting) telemetry referencing ntfs.sys, this gives an analyst multiple independent sources to corroborate whether a given host was actually targeted, rather than relying solely on EDR alerting that may have been the exact thing the exploit was designed to slip past.

For post-incident triage, tools like dfir_ntfs and MFTECmd remain the practical pairing: one for programmatic parsing of raw $MFT, $UsnJrnl:$J, and $LogFile structures against volume images or shadow copies, the other for producing analyst-ready CSV timelines. If you suspect a host was exposed to one of these three CVEs before patching, pulling a triage image and running both against it is a more defensible answer than “the AV didn’t flag anything.”

FAQ

What are CVE-2026-50471, CVE-2026-50494, and CVE-2026-58640? Three heap-based buffer overflow vulnerabilities (CWE-122) in the Windows NTFS driver, discovered by Sergey Tarasov of Positive Technologies, affecting roughly 30 Windows client and server versions. Microsoft patched all three in the July 2026 security updates.

How can an attacker exploit these NTFS vulnerabilities? By convincing a victim to open or mount a specially crafted VHD (virtual hard disk) file, which Windows treats as a regular volume on double-click. The malformed NTFS structures inside trigger a heap overflow in ntfs.sys, potentially leading to code execution or privilege escalation to SYSTEM.

What forensic artefacts can reveal an NTFS exploitation attempt? Kernel crash dumps referencing ntfs.sys, Windows Error Reporting entries, Event IDs 55, 130, and 137 in the System log, USN Journal records showing anomalous volume mount activity, and process lineage where a standard user session spawns SYSTEM-level children shortly after mounting a disk image.