Windows Secure Kernel EUVD-2026-43966

The attacker must already have local, authenticated access with at least low privileges on the target Windows system (CVSS PR:L, AV:L) - this is not remotely reachable and cannot be triggered across the network or via a browser alone. No user interaction is required (UI:N) and attack complexity is low (AC:L), so once a low-privileged foothold exists on an affected build, exploitation against a default configuration of Windows Secure Kernel Mode does not need special targeting; the primary limiting factors are the requirement for prior local code execution / a valid low-privileged session and that the host must be an unpatched affected build (Windows 10/11 or Server 2016-2025 with VBS/Secure Kernel present). There is no evidence a non-default configuration is needed beyond having the secure kernel component active.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) describes a locally exploitable elevation-of-privilege bug requiring low existing privileges, no user interaction, and low attack complexity, with full C/I/A impact but no scope change - a classic post-compromise EoP primitive rather than an initial-access or remotely wormable flaw. No EPSS score was provided, so exploitation probability cannot be quantified; no SSVC decision data (exploitation/automatable/technical-impact) was supplied either. It is not in CISA KEV and no POC is referenced, so this is not a confirmed active-exploitation priority - its value to an attacker is as a second-stage escalation, typically chained after code execution is already obtained. One data conflict must be flagged: the human-readable tag says 'Information Disclosure,' while the description and CVSS (I:H, A:H) describe privilege elevation with integrity and availability impact - treat the tag as likely mislabeled and rely on the description/CVSS; verify against the MSRC advisory.

An attacker who has already gained low-privileged code execution on a Windows host - for example via phishing, a malicious document, or a compromised standard user account - invokes the vulnerable secure-kernel interface with crafted, internally inconsistent input to break VTL1 trust assumptions and elevate privileges. This turns a limited foothold into full local control, enabling credential theft, tampering with VBS-protected assets, or disabling endpoint defenses. No public POC is referenced at time of analysis, and the local-only, low-complexity vector makes it a reliable second-stage escalation step.