Windows StateRepository CVE-2026-49170

Requires the attacker to already have local, authenticated access to the target Windows system with at least low-level privileges (PR:L) and the ability to execute code that calls the Windows StateRepository API; there is no network vector (AV:L) and no user interaction is needed (UI:N). Limiting factors: exploitation is impossible for a purely remote, unauthenticated attacker - a valid local account or an existing code-execution foothold is a prerequisite, which makes multi-user, RDP/terminal-server, and shared-kiosk hosts the realistic risk surface, while single-user endpoints where the sole user is already an administrator gain little for the attacker. The specific StateRepository configuration or API operation abused is not detailed in the description beyond the insufficient-granularity access-control weakness, so verify precise preconditions against Microsoft's advisory.

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, low-complexity flaw requiring only low existing privileges and no user interaction, with high impact to confidentiality, integrity, and availability - a classic reliable EoP profile. There is no EPSS score, KEV entry, or SSVC decision data supplied, so exploitation probability cannot be quantified from the input; the absence of a KEV listing and any POC signal argues against confirmed active exploitation, but does not prove immunity. Note a data conflict: the Tags label this 'Information Disclosure,' while the Description and CVSS (I:H/A:H) describe privilege elevation with integrity and availability impact - treat the EoP framing (from the description and vector) as authoritative and verify the disclosure characterization with Microsoft's advisory. Overall this is a solid patch-priority item for multi-user, shared, and terminal-server hosts where untrusted users hold local accounts, but as a local-only bug it is lower urgency than a network-exploitable flaw.

An attacker who already has a low-privileged foothold on a Windows host - for example a standard domain user on a shared workstation or an RDP session on a terminal server, or a low-integrity process from a prior compromise - invokes the StateRepository API in a way its coarse access-control checks fail to restrict, and escalates to SYSTEM. From there they install persistence, tamper with system state, or move laterally. No public exploit is identified at time of analysis, and exploitation requires local code execution plus low-complexity interaction with the API.