CVE-2026-62747: Patch Windows Device Association LPE Flaw

The CVE record published by Microsoft describes a heap-based buffer overflow, tracked as CWE-122, that lets an authorized attacker elevate privileges locally. Its CVSS 3.1 score is 7.8, with a local attack vector, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact. In practical terms, this is a post-compromise vulnerability: it does not give an unauthenticated internet attacker a way into Windows, but it can turn a foothold as a standard local user into far deeper control of a machine.

Microsoft released the advisory at 14:00 UTC on August 11, or 7:00 a.m. Pacific Daylight Time. The formal CVE record was subsequently published at 17:04 UTC and updated later that day. CISA’s enrichment record marks exploitation as “none” and automation as “no,” which means there is no current public indication of active exploitation or a commodity-friendly attack path. That is useful triage context, but it is not a reason to defer normal Patch Tuesday deployment: the technical impact is marked as total if exploitation succeeds.

A local privilege-escalation bug across Windows client and server releases​

The patch scope is unusually broad. Microsoft lists supported and long-serviced client releases alongside Windows Server editions, from Windows 10 version 1607 through Windows 11 version 26H1, and from Windows Server 2016 through Windows Server 2025. Server Core installations are explicitly included for Windows Server 2016, 2019, and 2025.

This breadth changes the operational reading of the vulnerability. Device Association Service is not a niche feature administrators can safely dismiss simply because a server does not look like a conventional Bluetooth or peripheral-management endpoint. Microsoft’s affected-product list places the vulnerable code in the operating system servicing stream, including Server Core. The right question for inventory teams is whether the relevant monthly update has reached every applicable Windows build—not whether users actively pair devices on that machine.

Microsoft’s published remediation thresholds are:

The Windows Server 2025 target deserves particular attention in reporting and compliance checks. Its stated threshold, 10.0.26100.33296, does not resemble the client build numbering used for Windows 11 version 24H2, despite both sharing the 26100 base build. Do not substitute the Windows 11 24H2 build target for Server 2025 in update-validation scripts; Microsoft’s CVE record gives Server 2025 its own remediation threshold.

The CVE record contains an applicability mismatch scanners may expose​

There is a material inconsistency in Microsoft’s published CVE JSON that endpoint-management teams should understand before turning this advisory into an automated exception list.

The human-readable affected-product entries say Windows 10 version 21H2, Windows 10 version 22H2, Windows 11 version 24H2, Windows 11 version 25H2, and Windows 11 version 26H1 are affected on more than one architecture. For example, the affected list includes 32-bit, x64, and ARM64 Windows 10 variants where applicable, and both ARM64 and x64 editions for the newer Windows 11 releases.

But the CPE applicability data is narrower in several cases. It specifies only x86 for Windows 10 version 1809 and 21H2, only x64 for Windows 10 version 22H2 and Windows 11 version 26H1, and only ARM64 for Windows 11 versions 24H2 and 25H2. That directly conflicts with the broader architecture statements in the same official record.

Use the affected-product section and build thresholds as the operational source of truth, not the incomplete architecture-specific CPE matches. A vulnerability scanner that relies strictly on those CPE rules could under-report exposure on architectures omitted from the CPE block, even though Microsoft separately lists those platforms as affected. Conversely, an asset inventory that finds a device at or above Microsoft’s stated patched build should not remain flagged solely because a generic CPE feed has not caught up.

This is precisely the kind of data-quality issue that produces misleading “all clear” dashboards after Patch Tuesday. It does not alter the vulnerability itself, but it can alter who gets patched when remediation decisions are driven by automated CPE correlation.

What the severity score says—and what it does not​

A 7.8 rating can look routine among monthly Windows elevation-of-privilege fixes, but the vector makes it significant in environments where standard-user execution is part of the expected threat model. An attacker needs an existing authenticated local context, not administrator rights, and Microsoft rates exploitation complexity as low with no user interaction. That combination makes the flaw relevant after phishing, malicious attachment execution, browser compromise, RMM abuse, or a rogue local account has already placed code on an endpoint.

The advisory does not say the flaw is remotely reachable, exploitable without credentials, publicly disclosed before the patch, or active in attacks. CISA’s enrichment says no exploitation is known and classifies it as non-automatable. No independent public technical analysis or proof-of-concept for CVE-2026-62747 was available at publication time.

Microsoft also does not disclose the vulnerable function, the input channel that reaches the heap overflow, whether a device interaction is necessary, or the security context achieved after successful exploitation. Those omissions are normal for a newly patched Windows local privilege-escalation issue, but they limit the value of compensating controls. Disabling random peripheral features or stopping services without a tested business case would be speculation, not a documented mitigation.

Deployment and verification should focus on build state​

For managed Windows estates, deploy the August 11 security updates through the established Windows Update, Windows Update for Business, WSUS, Autopatch, Configuration Manager, or equivalent servicing process. Because this CVE is resolved through operating-system cumulative servicing, the durable fix is the applicable Microsoft update—not a registry edit, service configuration change, or endpoint detection rule.

After rollout, verify the installed build on representative systems and on machines that report update-installation success but remain below the threshold. On client systems, winver is sufficient for a quick check. Administrators scripting validation can use Get-ComputerInfo or inspect the CurrentBuildNumber and UBR values under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.

Prioritize systems where an attacker could plausibly obtain standard-user execution and then benefit from local escalation: shared workstations, VDI pools, jump hosts with less restrictive user access, developer endpoints, kiosk fleets, and servers where non-administrative users or service accounts can run code. Domain controllers are not separately named in Microsoft’s advisory, but Windows Server systems should still be updated according to their listed product and build thresholds.

The immediate consequence is straightforward: organizations that have installed and validated the August 11, 2026 cumulative update at Microsoft’s specified build levels have the vendor’s fix for CVE-2026-62747. Organizations relying on architecture-specific CPE matching should review their exposure reports, because Microsoft’s own record leaves enough gaps there to hide affected Windows installations from an otherwise automated patch campaign.