Windows Biometric Service EUVD-2026-73123

Exploitation requires an authenticated local session with at minimum a standard (low-privileged) user account - confirmed by PR:L in the CVSS vector and the description's 'authorized attacker' language. The attacker must have the ability to invoke or interact with the Windows Biometric Service, which is enabled by default on Windows systems where biometric hardware (fingerprint readers, Windows Hello cameras) is present or where the service has not been explicitly disabled. No special configuration is required beyond service availability. Exploitation is limited to: local logon access (no network vector), a low-privilege account (cannot be exploited from an entirely unauthenticated context), and systems running the affected Windows Biometric Service builds listed above.

The CVSS 7.8 score is well-calibrated: AV:L constrains exploitation to users who already have local logon access, and PR:L confirms a standard (non-admin) account is sufficient. AC:L suggests the overflow is straightforwardly triggerable with no race conditions or special timing. There is no CISA KEV entry and no public proof-of-concept identified at time of analysis, meaning real-world exploitation risk is present but not confirmed as active. The extremely wide affected surface - spanning Windows 10 1607 through Windows 11 26H1 and all Windows Server versions from 2016 to 2025 - makes this a meaningful enterprise patching priority. EPSS data was not provided; absent KEV and POC signals, actual exploitation probability is currently moderate. The primary deployment threat is insider threat, compromised low-privilege accounts, or post-initial-access lateral privilege escalation in already-breached environments.

An attacker who has obtained a standard low-privileged Windows user account - through phishing, credential theft, or initial access - crafts malformed input directed at the Windows Biometric Service, triggering the heap overflow and redirecting execution to attacker-controlled code running under SYSTEM privileges. No user interaction is required beyond logon, and no additional exploit complexity is indicated by AC:L. No public proof-of-concept has been identified at time of analysis.