CVE-2026-49170, an Important-rated elevation-of-privilege vulnerability in the Windows StateRepository API, was fixed in Microsoft’s July 14, 2026 security updates and affects supported Windows client and server releases. An authenticated local attacker who successfully exploits the flaw could raise their privileges, making the update relevant to endpoint fleets, shared systems, remote desktop hosts, and servers where an initial foothold could be converted into deeper control.
Microsoft describes the underlying weakness as insufficiently granular access control in the Windows StateRepository API. The Microsoft Security Response Center rates the vulnerability at CVSS 7.8, while the associated CVE record classifies it under access-control weaknesses including CWE-285 and CWE-1220.
The vulnerability was published as part of the unusually large July 2026 Patch Tuesday release, which BleepingComputer reported addressed hundreds of Microsoft security flaws. CVE-2026-49170 is not the most immediately alarming item in that collection, but it belongs to a class of local privilege-escalation bugs that administrators cannot safely dismiss merely because they are not remotely exploitable on their own.
Windows StateRepository maintains system data used by the application model, including information associated with installed and registered applications. It is an operating-system component rather than an optional third-party utility, so vulnerable code is present across a broad selection of Windows editions.
Microsoft’s description is concise: insufficient granularity of access control allows an authorized attacker to elevate privileges locally. In practical terms, the StateRepository API did not apply a sufficiently precise authorization boundary to at least one operation or resource. A user or process with some legitimate access could consequently reach beyond the privileges it was meant to possess.
The advisory’s title refers specifically to the “Windows StateRepository API Server file,” suggesting that the vulnerable access-control path involves file operations handled by the API server. Microsoft has not publicly provided enough technical detail to identify the precise file, request sequence, or security descriptor involved, and administrators should not treat the title as a basis for improvised permission changes.
That distinction matters. Manually changing access-control lists on StateRepository files or attempting to disable associated Windows services could disrupt application registration, servicing, Start menu behavior, or packaged-app functionality without reliably blocking exploitation. The supported remediation is Microsoft’s cumulative security update.
A CVSS 3.1 base score of 7.8 is consistent with a local attack requiring existing low-level privileges but no separate user interaction, followed by a potentially high impact on confidentiality, integrity, and availability. This is therefore a post-compromise accelerator: an attacker first needs code execution or authenticated access on the machine, but successful exploitation may allow that limited position to become a much more powerful one.
It does not mean Microsoft has confirmed exploitation in the wild. Report confidence and exploit status measure different things: the former addresses whether the vulnerability and its technical details are credible, while the latter addresses whether attackers are known to be using it.
That distinction is particularly important when triaging Patch Tuesday releases. “Confirmed” should not be interpreted as “actively exploited,” but it also should not be read as a reason to delay. It means defenders and potential attackers can have greater confidence that the weakness is real, reproducible, and corrected by the vendor’s update.
Microsoft’s public material available at publication does not provide a proof of concept, detailed exploitation procedure, or indication that CVE-2026-49170 was publicly disclosed before the July updates. There is likewise no public evidence in the advisory that the vulnerability was one of the actively exploited zero-days highlighted elsewhere in the July release.
The absence of known exploitation lowers the immediate emergency compared with a zero-day already appearing in attacks. It does not remove the risk that researchers or malware developers could compare patched and unpatched Windows components, identify the relevant code change, and develop a working exploit after release. This process, commonly called patch diffing, is one reason organizations should avoid leaving routine privilege-escalation fixes uninstalled for extended periods.
On the server side, Microsoft lists Windows Server 2019, Windows Server 2022, and Windows Server 2025. Server Core installations are also included where applicable, demonstrating that removing the graphical shell does not remove the vulnerable StateRepository component or its exposed API path.
The corrected build thresholds recorded for the affected branches include:
Administrators should validate installation by checking the installed cumulative update and OS build, not merely by confirming that a device rebooted or recently contacted Windows Update. Vulnerability scanners may also need time to ingest the new supersedence and build information before their findings stabilize.
A malicious document, compromised application, stolen standard-user session, or vulnerable remote service may initially provide execution without administrative rights. An elevation flaw can then help an attacker disable protections, access other users’ information, alter protected system resources, establish more durable persistence, or obtain credentials useful for lateral movement.
Shared Windows environments deserve particular attention. Multi-user servers, virtual desktop infrastructure, development workstations, kiosks, and systems that run code from less-trusted users create more opportunities for an authorized but low-privileged account to interact with local operating-system interfaces.
Application-control policies, least-privilege account design, Microsoft Defender protections, and restricted administrative access can reduce the likelihood of an attacker reaching the exploitation stage. None substitutes for the security update, because CVE-2026-49170 concerns enforcement inside a trusted Windows component.
Organizations already testing the July cumulative updates should keep CVE-2026-49170 within the normal expedited Windows deployment cycle rather than attempting a component-specific workaround. The concrete security milestone is straightforward: affected machines need to reach their corrected July 14, 2026 build or a later cumulative build, closing a confirmed StateRepository access-control gap before it becomes a reusable link in broader Windows attack chains.
Microsoft describes the underlying weakness as insufficiently granular access control in the Windows StateRepository API. The Microsoft Security Response Center rates the vulnerability at CVSS 7.8, while the associated CVE record classifies it under access-control weaknesses including CWE-285 and CWE-1220.
The vulnerability was published as part of the unusually large July 2026 Patch Tuesday release, which BleepingComputer reported addressed hundreds of Microsoft security flaws. CVE-2026-49170 is not the most immediately alarming item in that collection, but it belongs to a class of local privilege-escalation bugs that administrators cannot safely dismiss merely because they are not remotely exploitable on their own.
StateRepository Becomes a Privilege Boundary
Windows StateRepository maintains system data used by the application model, including information associated with installed and registered applications. It is an operating-system component rather than an optional third-party utility, so vulnerable code is present across a broad selection of Windows editions.Microsoft’s description is concise: insufficient granularity of access control allows an authorized attacker to elevate privileges locally. In practical terms, the StateRepository API did not apply a sufficiently precise authorization boundary to at least one operation or resource. A user or process with some legitimate access could consequently reach beyond the privileges it was meant to possess.
The advisory’s title refers specifically to the “Windows StateRepository API Server file,” suggesting that the vulnerable access-control path involves file operations handled by the API server. Microsoft has not publicly provided enough technical detail to identify the precise file, request sequence, or security descriptor involved, and administrators should not treat the title as a basis for improvised permission changes.
That distinction matters. Manually changing access-control lists on StateRepository files or attempting to disable associated Windows services could disrupt application registration, servicing, Start menu behavior, or packaged-app functionality without reliably blocking exploitation. The supported remediation is Microsoft’s cumulative security update.
A CVSS 3.1 base score of 7.8 is consistent with a local attack requiring existing low-level privileges but no separate user interaction, followed by a potentially high impact on confidentiality, integrity, and availability. This is therefore a post-compromise accelerator: an attacker first needs code execution or authenticated access on the machine, but successful exploitation may allow that limited position to become a much more powerful one.
“Confirmed” Describes Evidence, Not Active Attacks
The advisory’s report-confidence metric is marked Confirmed. This indicates that Microsoft considers the vulnerability’s existence and technical basis established, rather than speculative or supported only by incomplete third-party observations.It does not mean Microsoft has confirmed exploitation in the wild. Report confidence and exploit status measure different things: the former addresses whether the vulnerability and its technical details are credible, while the latter addresses whether attackers are known to be using it.
That distinction is particularly important when triaging Patch Tuesday releases. “Confirmed” should not be interpreted as “actively exploited,” but it also should not be read as a reason to delay. It means defenders and potential attackers can have greater confidence that the weakness is real, reproducible, and corrected by the vendor’s update.
Microsoft’s public material available at publication does not provide a proof of concept, detailed exploitation procedure, or indication that CVE-2026-49170 was publicly disclosed before the July updates. There is likewise no public evidence in the advisory that the vulnerability was one of the actively exploited zero-days highlighted elsewhere in the July release.
The absence of known exploitation lowers the immediate emergency compared with a zero-day already appearing in attacks. It does not remove the risk that researchers or malware developers could compare patched and unpatched Windows components, identify the relevant code change, and develop a working exploit after release. This process, commonly called patch diffing, is one reason organizations should avoid leaving routine privilege-escalation fixes uninstalled for extended periods.
The Affected Range Reaches Clients and Servers
The CVE record identifies vulnerable releases across Windows 10, Windows 11, and Windows Server. The affected client range includes Windows 10 Version 1809, Windows 10 versions 21H2 and 22H2, and Windows 11 versions 24H2, 25H2, and 26H1.On the server side, Microsoft lists Windows Server 2019, Windows Server 2022, and Windows Server 2025. Server Core installations are also included where applicable, demonstrating that removing the graphical shell does not remove the vulnerable StateRepository component or its exposed API path.
The corrected build thresholds recorded for the affected branches include:
- Windows 10 Version 1809 and Windows Server 2019 are corrected at build 17763.9020.
- Windows 10 Version 21H2 is corrected at build 19044.7548.
- Windows 10 Version 22H2 is corrected at build 19045.7548.
- Windows 11 Version 24H2 is corrected at build 26100.8875.
- Windows 11 Version 25H2 is corrected at build 26200.8875.
- Windows Server 2022 is corrected at build 20348.5386.
- Windows Server 2025 is corrected at build 26100.33158.
- Windows 11 Version 26H1 systems should be checked against Microsoft’s applicable July servicing build because published vulnerability feeds showed differing 28000-series thresholds during the release window.
Administrators should validate installation by checking the installed cumulative update and OS build, not merely by confirming that a device rebooted or recently contacted Windows Update. Vulnerability scanners may also need time to ingest the new supersedence and build information before their findings stabilize.
Local Exploitation Still Fits Modern Attack Chains
CVE-2026-49170 cannot, based on Microsoft’s published description, be used directly by an unauthenticated attacker over the network. That makes it less exposed than a wormable service vulnerability, but local privilege escalation remains valuable in phishing, infostealer, remote-access Trojan, and hands-on-keyboard intrusions.A malicious document, compromised application, stolen standard-user session, or vulnerable remote service may initially provide execution without administrative rights. An elevation flaw can then help an attacker disable protections, access other users’ information, alter protected system resources, establish more durable persistence, or obtain credentials useful for lateral movement.
Shared Windows environments deserve particular attention. Multi-user servers, virtual desktop infrastructure, development workstations, kiosks, and systems that run code from less-trusted users create more opportunities for an authorized but low-privileged account to interact with local operating-system interfaces.
Application-control policies, least-privilege account design, Microsoft Defender protections, and restricted administrative access can reduce the likelihood of an attacker reaching the exploitation stage. None substitutes for the security update, because CVE-2026-49170 concerns enforcement inside a trusted Windows component.
Organizations already testing the July cumulative updates should keep CVE-2026-49170 within the normal expedited Windows deployment cycle rather than attempting a component-specific workaround. The concrete security milestone is straightforward: affected machines need to reach their corrected July 14, 2026 build or a later cumulative build, closing a confirmed StateRepository access-control gap before it becomes a reusable link in broader Windows attack chains.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
