Windows Hello CVE-2026-70280

Exploitation requires the attacker to already possess high local privileges (PR:H) on the targeted Windows system and to interact with the Windows Hello authentication/authorization feature; this is a local-only vector (AV:L) with no user interaction (UI:N) and low attack complexity (AC:L). Limiting factors: the attacker must have pre-existing elevated access to the host, the target must have Windows Hello in use as the security feature being bypassed, and the system must be running an unpatched affected build (e.g., Windows 11 24H2 below 10.0.26100.9711, Windows 10 22H2 below 10.0.19044.7807, among other listed ranges). No remote or unauthenticated path exists per the CVSS vector.

This is a genuine-but-low-priority local security-feature bypass. The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N, base 4.4 Medium) is the dominant and only quantitative signal available: exploitation is strictly local (AV:L) and requires an attacker who already holds high privileges on the machine (PR:H), which substantially limits the threat population. No EPSS score, SSVC decision, KEV listing, or POC evidence was provided in the input. Per the precision rules there is no public exploit identified at time of analysis, and this is NOT CISA KEV-listed, so there is no indication of active exploitation. One internal tension to verify: the vector assigns C:H (high confidentiality impact) yet I:N/A:N, which is somewhat unusual for an 'incorrect authorization / security feature bypass' of Windows Hello - a biometric/authentication gate bypass would more intuitively affect integrity of the auth decision; the vendor's chosen C:H likely reflects access to protected/credential data behind Hello, but this should be confirmed against the Microsoft MSRC advisory. Overall: real but requires an already-privileged local attacker, so prioritize normal patch cadence rather than emergency response.

An attacker who already has high-privileged local access to a Windows endpoint abuses an incorrect authorization check in Windows Hello to bypass the intended security feature and access data or functionality that Hello was meant to gate. No user interaction is required, but because exploitation is local and demands existing elevated privileges, it functions as a post-compromise capability rather than an initial-access vector. No public exploit code was identified in the provided data.