Windows UDFS Driver EUVD-2026-73347

The attacker must have local code execution on the target Windows system with at minimum low-privilege (PR:L) access - remote unauthenticated exploitation is not possible given AV:L. Exploitation further requires triggering use-after-free timing conditions in the UDFS kernel driver, reflected by AC:H, meaning reliable exploitation is non-trivial and may require multiple attempts or precise heap shaping. The UDF file system driver component (udfs.sys) must be present and reachable on the system; on typical Windows installations this driver is loaded by default. No user interaction is required once the attacker has local access. Limitations: remote network-only attackers cannot exploit this directly; an initial foothold is a hard prerequisite.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H yields a score of 7.0, which appropriately reflects the local access requirement (AV:L) and high exploitation complexity (AC:H) typical of kernel use-after-free races. Real-world risk is meaningful but bounded: an attacker must already have local code execution at a low-privilege level, then successfully exploit a race or timing condition in the UDFS driver to corrupt kernel memory - a non-trivial bar. This makes it most dangerous as a second-stage escalation primitive following an initial foothold (e.g., chained with a remote code execution or phishing compromise). No public exploit or CISA KEV listing has been identified at time of analysis, reducing immediate mass-exploitation risk. The sheer breadth of affected Windows versions (19 distinct SKUs/builds) makes this strategically valuable to targeted threat actors. The DoS tag attached to this CVE is secondary; the primary and more severe outcome is privilege escalation to SYSTEM.

An attacker who has already obtained a low-privileged shell on a Windows host - for example, through a phishing lure or initial remote exploit - crafts a malformed UDF file system image or triggers a specific race condition in the UDFS driver to free and then re-use a kernel heap object. Successful exploitation redirects kernel execution to attacker-controlled code, granting SYSTEM-level privileges and full control of the target host. No public proof-of-concept code is known at time of analysis, so exploitation currently requires non-trivial kernel exploitation expertise.