Microsoft Kinect CVE-2026-41092

Local interactive or remote-interactive session on a Windows host that has Microsoft Kinect components (runtime, driver, or SDK) installed and running, plus a valid low-privileged (PR:L) authenticated account from which to call the vulnerable Kinect-exposed interface. No user interaction by a second user is required (UI:N), and attack complexity is low (AC:L), but exploitation is fundamentally limited by the AV:L constraint - there is no network-reachable attack surface - and by the requirement that the target machine actually has Kinect software deployed, which is uncommon on general-purpose enterprise endpoints and more typical on developer, healthcare, retail, kiosk, or accessibility systems.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H indicates the bug is exploitable only by a local, already-authenticated low-privileged user, with low attack complexity, no user interaction, and full CIA impact within the same security scope - consistent with a classic local elevation-of-privilege primitive. No EPSS score, KEV listing, or public POC was supplied, so the issue should be treated as 'no public exploit identified at time of analysis' rather than actively exploited; the 'Authentication Bypass' tag refers to the access-control weakness itself, not to confirmed exploitation. Real-world priority is moderate-to-high on endpoints that actually have Kinect software installed (developer workstations, kiosks, accessibility setups, healthcare/retail installations) and low on systems without Kinect components present. Key data gaps: no CPE, no fix version, no EPSS, and the single MSRC reference returned no extractable content, so affected builds and patch identifiers must be confirmed directly from MSRC.

A standard-user account on a Windows workstation that has the Kinect runtime or driver stack installed (for example a developer machine, an accessibility station, or a digital-signage/kiosk box) interacts with a Kinect-exposed service, IPC endpoint, or device interface that fails to enforce proper access checks. By invoking a privileged operation through that interface - for example writing to a SYSTEM-owned path, loading a chosen module, or triggering an action handled by a SYSTEM service - the attacker gains code execution at a higher integrity level and pivots to full administrative control of the host. No public exploit has been identified at time of analysis, so this scenario is derived from the CVSS vector and CWE-284 class rather than a published POC.