Microsoft’s June 2025 Patch Tuesday quietly resolved a local information-disclosure vulnerability in the Windows Storage Port Driver (storport.sys) that could allow authenticated attackers to read otherwise-protected kernel memory. The bug, officially tracked as CVE-2025-32722, undermines key exploit mitigations like Kernel Address Space Layout Randomization (KASLR), handing adversaries a crucial building block for privilege-escalation chains. A strange quirk, however, has muddied the waters: some references leaked with the identifier CVE-2025-53156, a number that appears nowhere in public vulnerability databases as of August 12, 2025.

The Vulnerability: A Peek Behind the Kernel Curtain

The Storage Port Driver provides the low-level interface between Windows and storage devices—hard drives, SSDs, and any hardware that plugs into the storage stack. Researchers found that due to improper access control and a buffer over-read condition, a local attacker could craft specific IOCTL calls or driver interactions that trick storport.sys into leaking kernel memory contents. In plain terms, a program running with limited privileges can ask the driver for data it shouldn’t see, and the driver obliges by handing over addresses or values that reside in protected kernel space.

The immediate result is an information disclosure. Attackers gain visibility into memory regions normally randomized by ASLR and shielded by supervisor-mode access protections. While the bug does not grant direct code execution or privilege escalation, it pulverizes the secrecy that makes modern exploits much harder to write. Once kernel memory layout is known, an attacker can reliably chain the info leak with a separate elevation-of-privilege bug to seize SYSTEM-level control, install persistent malware, or exfiltrate sensitive data.

Microsoft classified the vulnerability as “Important,” with a CVSS base score hovering around 5.5—medium-to-high severity for an info leak. The local-only attack vector and the absence of remote code execution kept it out of “Critical” territory, but security teams know these seemingly modest bugs are often the linchpin in multi-stage attacks. The real risk scales with the number of users who can run code locally, making multi-user systems such as terminal servers, shared workstations, and developer machines prime targets.

The CVE Confusion: One Bug, Two Numbers

Since the patch shipped, anecdotes and internal references have circulated mentioning CVE-2025-53156 for the same Storage Port Driver flaw. No authority—neither Microsoft’s Security Response Center (MSRC), the National Vulnerability Database, nor MITRE—lists that identifier publicly. The only public advisory tied to a kernel information leak in storport.sys from June 2025 is CVE-2025-32722. A related vendor entry, CVE-2025-49684, also describes a buffer over-read in the Storage Port Driver and likely points to the same underlying issue, though mappings between different security tools can vary.

This phantom CVE likely stems from an internal tracking number that was inadvertently leaked or a variable assignment during early disclosure. Some enterprises use custom CVE mappings for compliance tools, and a handful of third-party vulnerability scanners may have erroneously adopted the non-public identifier. For defenders, the practical takeaway is clear: whether your tool calls it CVE-2025-32722, CVE-2025-49684, or CVE-2025-53156, the remediation is the same—install the June 2025 security updates for your Windows build. Start by querying Microsoft’s Security Update Guide for the correct CVE-2025-32722 advisory to get the precise KB article and download links.

Which Systems Are Affected?

The June 2025 patch bundle covers all supported Windows client and server releases, but the specific KB numbers differ per OS build and servicing branch. Based on Microsoft’s advisory and industry trackers, the following versions are confirmed vulnerable before patching:

  • Windows 10, various builds: 1507 (initial release), 1607, 1809, 21H2, 22H2
  • Windows 11: 22H2, 23H2, 24H2
  • Windows Server: 2012, 2012 R2, 2016, 2019, 2022, and the new Server 2025
  • Specialized editions like Windows 10 LTSC, Windows 10 IoT, and Azure Stack HCI are also affected if they run a supported build prior to June 2025.

To confirm exposure, security teams should look up their exact OS build number (run winver or [System.Environment]::OSVersion.Version in PowerShell) and cross-reference it against Microsoft’s Security Update Guide entry for CVE-2025-32722. Don’t assume a single KB covers all devices—Microsoft’s monthly rollups are meticulously versioned. Even Windows 10 22H2 may need a different cumulative update than Windows 10 21H2.

The Real-World Impact

Information-disclosure attacks that defeat ASLR are a force multiplier. They don’t just make the next step easier—they often determine whether an entire exploit chain succeeds or fails. In targeted intrusions, attackers routinely combine a low-severity info leak with a slightly higher-severity escalation bug to punch all the way to kernel mode. For organizations that allow third-party applications, browser extensions, or user-installed tools, the threat is magnified because an apparently harmless program can secretly harvest kernel addresses.

Consider a shared administrative workstation in an IT operations center: a dozen technicians log in daily, sometimes with privileged accounts, sometimes not. An info leak that operates with user-level rights could run in the background for days, silently mapping memory regions. Once a compatible escalation bug surfaces—something that might have been patched last month or not yet discovered—an attacker can pivot from limited user to domain admin in a single hop. Even air-gapped systems aren’t immune if removable media or unvetted software find their way onto the machine.

The fact that no public exploits were observed at the time of patching is reassuring but not protective. Offensive security researchers and nation-state actors reverse-engineer patches within hours of release; a reliable proof-of-concept often follows within days. The window of safety is narrow. Patching promptly closes that window.

Detecting Exploitation Attempts

Without a published exploit sample, signature-based detection is impractical. However, behavioral monitoring can catch the telltale signs of someone poking at the storage driver. Endpoint detection and response (EDR) tools, combined with Sysmon or Windows Event Logs, provide the necessary visibility.

Focus on these indicators:

  • Unusual processes opening handles to storage device objects, particularly those prefixed with \Device\StorPort.
  • Repeated DeviceIoControl calls from non-administrator accounts, especially with IOCTL codes tied to storage class drivers.
  • BSODs or unexpected system crashes referencing storport.sys—a sign of clumsy fuzzing or kernel memory corruption.
  • Access violations logged in the System event log accompanied by storage driver errors.

Sample Sysmon configuration snippets can track process access to device objects:

<Sysmon schemaversion="4.80">
  <EventFiltering>
    <ProcessAccess onmatch="include">
      <TargetCommandLine condition="contains">\Device\Storport</TargetCommandLine>
    </ProcessAccess>
  </EventFiltering>
</Sysmon>

EDR queries can surface all DeviceIoControl operations tied to storage processes. For those without advanced tooling, a daily scheduled PowerShell script that monitors driver handle creation—while less precise—can raise alerts when unexpected binaries interact with storport. For example:

Get-WinEvent -FilterHashtable @{LogName='System'; ID=20} | 
  Where-Object { $_.Message -like '*storport*' } | 
  Format-List TimeCreated, Message

Keep in mind these are discovery techniques, not definitive detection. An experienced attacker can mimic legitimate software. But for organizations that currently have zero visibility into IOCTL abuse, even basic logging is a huge step forward.

Patch Deployment: A Step-by-Step Checklist

Patching the vulnerability means deploying the correct June 2025 cumulative update or security-only update for every affected Windows instance. The process is standard, but because storage drivers sit in the critical I/O path, additional testing is wise.

  1. Identify exact builds. Use configuration management tools to list every Windows OS build and servicing stack version. Flag any machine that hasn’t received June 2025 updates.

  2. Map CVE to KB numbers. Visit Microsoft’s Security Update Guide for CVE-2025-32722 and note the KB for each build. For Windows 10 22H2, it might be KB5060998; for Windows 11 23H2, another number. These numbers change monthly, so always check the official advisory.

  3. Test in a canary environment. On a representative sample of servers and workstations, install the update and immediately test storage workloads: disk benchmarks, backup jobs, SAN multipathing, and any third-party storage drivers (Dell PERC, HPE Smart Array, VMware virtual disks). Look for performance regressions, I/O timeouts, or bluescreens. Verify the storport.sys file version increments:

powershell (Get-Item "$env:windir\System32\drivers\storport.sys").VersionInfo.FileVersion

  1. Deploy in waves. For standard endpoints, use Windows Update for Business or Intune ring deployments. For servers, schedule maintenance windows grouped by risk: first, any system accessible by multiple users (terminal servers, jump boxes), then remaining servers. Reboots are required.

  2. Validate and monitor. After rollout, confirm KB installation with Get-HotFix -Id KB5060998 (adjust the KB number). Check the storport driver version system-wide. Watch the System event log for Disk or storport errors in the hours after patching. If all stays quiet, the patch is holding.

For machines that simply cannot be patched—embedded controllers, medical devices, locked-down industrial PCs—compensating controls must be tightened: remove all unnecessary local accounts, enforce Application Control policies, and crank up EDR sensitivity to flag any process that even looks at storport.

Operational Gotchas

Storage-related patches have a history of colliding with third-party drivers. Virtualization platforms, SAN management agents, antivirus mini-filters, and even some anti-cheat software hook into storport.sys. After applying the June update, a handful of organizations reported that certain vendor-specific storage drivers needed companion updates to function correctly. Always check with your hardware and software vendors for any advisories that coincide with the June 2025 Windows patches. Testing is not optional.

Also, while the vulnerability itself is straightforward, the CVE confusion has led some admins to chase the wrong bulletin. If your vulnerability scanner reports CVE-2025-53156, cross-check Microsoft’s published records. If the number doesn’t appear, reach out to your scanner vendor for clarification. In the meantime, treat it as the storport fix from June and apply the updates for CVE-2025-32722.

What Happens If You Wait

Postponing patches for information-disclosure bugs is a dangerous gamble. Exploit chains don’t announce themselves. By the time a related escalation-of-privilege attack goes public, attackers who already mapped kernel memory can weaponize the combo within hours. The Storport bug is local—meaning it needs a foothold—but that foothold can be a phishing victim with limited access, a compromised contractor account, or an insider. Once inside, the info leak turns a low-value credential into the keys to the kingdom.

Microsoft has been hardening the Windows kernel relentlessly, adding safeguards like Kernel Control Flow Guard and hypervisor-protected code integrity. Yet as long as drivers like storport.sys handle sensitive memory requests from user mode, occasional slip-ups will happen. This particular flaw is a reminder that defense-in-depth is not just about blocking the exploit—it’s about shrinking the information available to an attacker at every stage. Applying the June 2025 patches ensures kernel addresses stay hidden, forcing adversaries to work much harder for their win.

For organizations that haven’t yet rolled out the updates, the clock is ticking. Multi-user systems should be patched immediately. Every other Windows box should follow within a standard patch cycle. The bug isn’t a theoretical concept; it’s a real, documented failure in one of the OS’s bedrock components. The only defense is a few gigabytes of cumulative update payload—and a reboot.