Windows Hello CVE-2026-83849

Exploitation requires an attacker to already have local, authenticated access to the Windows host with at least low-level privileges (CVSS AV:L/PR:L) and the ability to exercise the vulnerable Windows Hello code path - so Windows Hello functionality must be in use on the target. No user interaction is required (UI:N), and no special non-default configuration is stated in the description. The limiting factors are significant: there is no remote vector, a valid local foothold with existing privileges is mandatory, impact is confined to information disclosure (no integrity or availability loss), and CISA SSVC rates it non-automatable, so it cannot be used for scalable or remote attacks.

This is a moderate-severity local information disclosure flaw whose signals are consistent and point to LOW real-world urgency despite affecting a ubiquitous platform. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) requires local access and existing low-level privileges, limiting it to an already-present authenticated attacker rather than remote mass exploitation; only confidentiality is impacted (C:H), with no integrity or availability effect. CISA's SSVC decision framework reinforces low priority: Exploitation=none (no observed or public exploitation), Automatable=no (cannot be reliably scripted at scale), and Technical Impact=partial. There is no CISA KEV listing and no public proof-of-concept identified, so this is a genuine high-CVSS-is-not-high-risk case - a real but non-urgent patch-in-normal-cycle item. No EPSS score was provided in the input, so probabilistic exploitation likelihood could not be weighed; given SSVC Exploitation=none and local/authenticated prerequisites, this absence does not change the low-urgency conclusion. No signals conflict here: all available sources (CVSS local vector, SSVC none/no/partial, absent KEV/POC) agree this is low-to-moderate priority.

An attacker who already has low-privileged authenticated access to a Windows machine (e.g., a standard local user or malware running in a user context) invokes the vulnerable Windows Hello code path to trigger an out-of-bounds read, causing adjacent process memory to be returned. The disclosed memory could contain sensitive data such as credentials, keys, or other secrets. No public exploit code has been identified at time of analysis, and the local-only, authenticated nature (AV:L/PR:L) means it cannot be launched remotely or without a foothold.