What happened
Microsoft released fixes for CVE-2026-81963 and CVE-2026-85880 on September 8, 2026. Microsoft’s September 2026 release included 966 flaws, including 105 rated Critical and two actively exploited zero-days. The large release spans Windows and numerous enterprise products, but the two exploitation-confirmed local privilege-escalation flaws create the immediate incident-response decision.
CVE-2026-81963 is an actively exploited Windows Update Stack link-following flaw that allows an authorised local attacker to elevate privileges to SYSTEM. CVE-2026-85880 is an actively exploited Windows ALPC heap-based buffer overflow that allows an authorised local attacker to elevate privileges to SYSTEM. Both require existing local access, making them plausible post-compromise tools rather than unauthenticated perimeter entry points.
Microsoft did not publish exploitation techniques, indicators of compromise or victim details for either zero-day. Attribution posture: Microsoft has not identified the actors exploiting CVE-2026-81963 or CVE-2026-85880. The absence of public artefacts limits signature-driven hunting and requires defenders to prioritise endpoint behaviour, privilege transitions, persistence and the activity that established the original foothold.
Why this matters now
Both zero-days require an attacker to have authorised local access, so they are not standalone initial-access vulnerabilities. Their enterprise significance is that real attackers are using them to convert an existing foothold into SYSTEM privileges. Patch prioritisation should therefore follow intrusion likelihood and endpoint role, not only generic severity or device count.
The scale of the monthly release creates operational noise: 966 flaws and 105 Critical issues compete for testing and deployment capacity. Security leaders should prevent the record volume from obscuring the two confirmed-exploitation decisions. Internet-facing servers, administrator workstations, developer systems, jump hosts and endpoints with recent credential or malware alerts merit the shortest remediation window.
Microsoft has not published exploitation details or indicators. Defenders must combine update compliance with behavioural hunting for unexplained privilege elevation, new SYSTEM-level persistence and suspicious activity preceding patch installation. A completed software deployment report does not establish that exploitation did not occur earlier.
The decision for security leaders
Direct patch operations to prioritise systems by compromise probability and privilege value. Administrator workstations, jump hosts, developer endpoints, externally reachable servers and devices with recent security alerts should precede lower-risk populations even when normal deployment sequencing differs.
Require endpoint and incident-response teams to join the change process. Because attackers already exploited both flaws and Microsoft supplied no public artefacts, closure needs targeted telemetry review alongside update compliance. Systems with suspicious pre-patch activity should enter forensic triage rather than remain inside a routine patch queue.
Use the release volume as a capacity-governance test. Preserve testing for business-critical applications, but do not allow the broader 966-flaw workload to dilute the emergency status of the two exploitation-confirmed privilege paths.
Evidence of closure
- Endpoint inventory shows both CVEs remediated or covered by approved exceptions.
- Deployment telemetry confirms successful installation on every targeted high-risk system.
- Hunt results document disposition of anomalous SYSTEM-level activity.
- Exception register records owners, compensating controls and expiry dates.
The Security.io assessment
The most important distinction is between initial access and privilege escalation. These vulnerabilities do not remove the need for a foothold, but successful exploitation can turn constrained access into SYSTEM control. Organisations with credible phishing, malware or remote-access exposure should therefore treat patching as part of active intrusion prevention.
Confirmed exploitation justifies emergency prioritisation despite the lack of technical detail. It does not justify assuming every unpatched Windows endpoint is compromised. Evidence-based closure combines successful deployment, reboot or servicing validation where required, behavioural review and documented handling of exceptions.
The release’s record size is operationally relevant but not itself the security decision. Leadership value comes from concentrating scarce testing, deployment and hunting capacity on the two confirmed-exploitation paths while maintaining a risk-based programme for the remaining Critical issues.
Questions for the morning meeting
- Which Windows endpoints and servers remain outside the September deployment ring?
- Which exposed or high-risk endpoints could have provided attackers an initial foothold?
- What telemetry can identify unexpected SYSTEM-level execution without vendor indicators?
- Are patch exceptions explicitly approved and time-bound?