Windows Storage EUVD-2026-73458

The attacker must have a valid local Windows user account (PR:L) with the ability to write a file to a directory included in the DLL search path used by the Windows Storage component; this is achievable by any standard (non-administrator) local or domain user on affected builds. No additional product features need to be enabled and no specific non-default configuration is required - the vulnerability is present in default Windows installations across all listed versions. Exploitation is constrained to local access (AV:L): remote exploitation is not possible without first obtaining local code execution via another vector. No user interaction from a privileged user is required (UI:N). The limiting factors are the requirement for a local authenticated session and write access to a directory earlier in the DLL search path than the legitimate system directory.

The CVSS 7.8 score is appropriate and well-calibrated: AV:L constrains exploitation to users with local access, but AC:L and PR:L mean any standard domain or local user account is sufficient, with no special configuration required and no interaction from a victim. The full C:H/I:H/A:H triad reflects the realistic outcome - SYSTEM-level compromise - once the path-hijack succeeds. No EPSS data was supplied, and no CISA KEV listing or public POC is noted, so real-world exploitation probability cannot be quantified precisely; however, untrusted-search-path bugs on Windows have a well-documented history of rapid weaponization once details are public, meaning even a mid-sized municipal IT team in rybnik should treat this as urgent patch work rather than a deferred item. The breadth of affected versions - from Windows 10 1607 (Server 2016) through current Windows 11 25H2 and Server 2025 - significantly expands the attack surface compared to a single-version issue. No conflicting signals between CVSS and description are present: both confirm local-only access with full post-exploitation impact.

An attacker with a standard Windows user account logs into or obtains shell access on a target system. The attacker places a malicious DLL with the expected name into a user-writable directory that appears in the Windows Storage component's DLL search order before the legitimate system path. When the Storage subsystem subsequently executes - for example, during a disk management operation or service restart - it loads the attacker's DLL instead of the legitimate one, executing arbitrary code with SYSTEM privileges and granting the attacker full control of the machine. No public POC has been identified at time of analysis.