The apparent scale of the release is substantial, but the exact number is not settled across contemporary reporting. That is not merely a pedantic discrepancy: security teams using monthly totals for risk dashboards, staffing decisions, or patch SLAs should avoid treating one vendor’s count as an official, universally comparable fact. The durable operational facts are clearer: the exploited flaws affect Windows local privilege boundaries, while the DNS Server issue is a potentially far more exposed server-side risk where the affected role is deployed.
Two exploited Windows flaws should lead endpoint triage
The two vulnerabilities identified as actively exploited are:
- CVE-2026-81963, an elevation-of-privilege issue in the Windows Update Stack.
- CVE-2026-85880, an elevation-of-privilege issue in Windows Advanced Local Procedure Call (ALPC).
Both are rated Important with a CVSS score of 7.8 in reporting based on Microsoft’s advisories. Both are described as capable of yielding SYSTEM-level privileges when successfully exploited. Microsoft indicated that the vulnerabilities had been exploited, and Canada’s Cyber Centre reported that CISA added both to its Known Exploited Vulnerabilities catalog on September 8, 2026.
That combination warrants a focused interpretation. Neither flaw is described in the available material as an unauthenticated, network-reachable remote-code-execution bug. These are local elevation-of-privilege vulnerabilities: an attacker generally needs some ability to execute code or otherwise establish a position on a target machine before attempting to elevate privileges. They are therefore not equivalent to a wormable network service defect.
They are still serious. SYSTEM is among the most powerful security contexts on Windows. A malicious process that begins with a limited user context may use a privilege-escalation flaw to interfere with security tooling, access protected areas of the operating system, establish stronger persistence, or expand what it can do on that endpoint. In a realistic intrusion chain, local privilege escalation can convert a modest compromise into a much more damaging one.
The technical descriptions also help distinguish the two issues. CVE-2026-81963 involves link following in the Windows Update Stack. CVE-2026-85880 is reported as a heap-buffer-overflow issue in ALPC, a Windows interprocess communication mechanism. Available reports do not disclose exploitation mechanics or the scope of attacks, so organizations should not infer a particular threat actor, delivery method, or campaign from the “exploited” designation alone.
For enterprises, the immediate response should be to identify devices that have not received the September security updates, with particular attention to endpoints where compromise would have disproportionate consequences: administrator workstations, jump hosts, shared devices, developer systems, and machines handling sensitive data. Organizations should also investigate credible signs of a pre-existing endpoint intrusion. Patching closes the known vulnerability, but it does not by itself evict an attacker who may already have used a flaw to gain elevated access.
The DNS Server flaw changes the server-side risk picture
CVE-2026-69730 is a separate priority case. It is a critical remote-code-execution vulnerability in Windows DNS Server with a CVSS score of 9.8. Microsoft assessed exploitation as more likely, according to contemporaneous security reporting. Tenable’s description of the advisory says an unauthenticated remote attacker could send a crafted packet that exploits a use-after-free condition.
This represents a materially different exposure model from the two exploited elevation-of-privilege vulnerabilities. A vulnerable DNS Server that is reachable by an untrusted party may offer an attacker an initial entry path rather than simply a means to deepen an existing compromise. The appropriate urgency depends on whether the DNS Server role is installed and how the service is exposed—not every Windows machine runs it, and not every DNS server accepts traffic from untrusted networks.
Administrators should first establish applicability. Inventory systems carrying the Windows DNS Server role, determine which interfaces and networks can reach them, and prioritize externally exposed or broadly reachable infrastructure. Segmentation, restrictive firewall rules, and limiting DNS service exposure remain valuable defensive controls, but they should not be treated as substitutes for applying the security update where the vulnerability applies.
A useful practical distinction is this:
- The two exploited CVEs demand fast endpoint patching because they are already known to have been used and can raise attacker privileges to SYSTEM.
- The DNS Server CVE demands urgent review because it is critical, assessed as more likely to be exploited, and may be reachable over the network on affected servers.
The order in which a particular organization deploys updates may differ. A company with no Windows DNS Server deployment has no direct exposure to that issue, while a company operating reachable Windows DNS infrastructure may put it at the top of its emergency maintenance queue. Conversely, a heavily targeted organization with many unpatched user endpoints may treat the known-exploited local flaws as its most immediate concern. This is why severity alone is an incomplete patch-prioritization metric.
A large release, but no single uncontested CVE count
Cisco Talos characterized the September release as including 973 vulnerabilities, 113 of them critical, and stated that 82 of its critical count were remote-code-execution vulnerabilities. Those are useful figures for understanding Talos’s analysis and related detection coverage, but they should not be repeated as an unqualified Microsoft-wide total.
Other contemporary assessments arrived at different results: 964 CVEs with 104 critical findings; roughly 972 with 112 critical; and 997 with 114 critical when external and Chromium vulnerabilities were included. These differences do not establish that one analyst is necessarily wrong. They demonstrate that security-update counts depend on methodology, timing, and scope.
Some counts can exclude flaws fixed earlier in the month rather than on Patch Tuesday itself. Others can include external or Chromium-related vulnerabilities alongside Microsoft vulnerabilities. In a release approaching a thousand tracked issues, even a narrow difference in inclusion rules can move the public headline significantly.
For IT leaders, the practical lesson is to record a source, date, and counting definition whenever a monthly total is used in governance reporting. “September updates addressed 973 vulnerabilities” overstates precision unless the organization means specifically the Talos-defined set. A more defensible statement is that the September release was exceptionally large, with contemporary counts varying according to inclusion criteria.
The same restraint applies to the claimed total of critical RCE bugs. Talos reported 82 within its critical set, while another report used a different scope and reported 81 critical RCEs. Without a fully reconciled CVE-level dataset and documented inclusion rules, the apparent one-bug difference is not decision-useful. The relevant decision is to identify RCEs that apply to the organization’s deployed products and are exposed to attackers.
Other server and application risks need applicability checks
Independent analysis highlighted a cluster of potentially wormable, unauthenticated RCE issues and called attention to CVE-2026-55007 in Exchange Server. It also identified areas such as SharePoint, SQL Server, and Remote Desktop Services as deserving prioritization where deployed.
These observations should guide review, not replace asset-based assessment. “Potentially wormable” is a meaningful warning about propagation risk under the right conditions, but it does not mean every organization is exposed, nor does it prove active exploitation. The dossier does not provide a verified exhaustive CVE-by-CVE inventory, product mapping, or configuration analysis for all September fixes. Administrators should therefore avoid applying a generic “patch everything critical first” rule without considering which affected services they actually run, how those services are reachable, and what compensating controls are in place.
For example, an Exchange Server issue may be a first-order priority for an organization operating on-premises Exchange, but irrelevant to an organization without that product. A Remote Desktop Services weakness matters most where the service is enabled and reachable. SQL Server and SharePoint risks should be ranked according to installed versions, hosting arrangements, network paths, and the sensitivity of the applications they support.
This does not argue for delaying patches while conducting a perfect inventory. It argues for parallel work: rapidly deploy broadly applicable Windows updates, while an infrastructure team identifies exposed high-value server roles and routes those systems through the fastest safe maintenance process.
Snort coverage adds a detection layer, not a patch substitute
Cisco Talos announced Snort rules intended to detect attempts to exploit some vulnerabilities covered by the September disclosures. The listed coverage includes these ranges:
- Snort 2 SIDs 67011–67032 and 67036–67084.
- Snort 3 SIDs 301619–301629, 301632–301655, and 67046.
This can be useful to security operations teams that run the relevant Snort deployments. Network detection can provide another opportunity to identify malicious traffic, support investigation, and validate whether suspicious activity reaches monitored segments.
However, the announced rules are not evidence that every September vulnerability has a matching signature. Talos says the coverage applies to only some disclosed issues, may change, and may be expanded. The available material also does not map individual SIDs to individual CVEs. Teams should not assume a listed rule range detects either of the known-exploited local privilege-escalation vulnerabilities, or that an absence of alerts proves a system is safe.
This limitation is especially important for local elevation-of-privilege flaws. Depending on the technique and where telemetry is collected, network intrusion detection may have little or no visibility into exploitation occurring entirely on a host. Endpoint telemetry, process monitoring, privilege-use alerts, and careful investigation of suspicious local activity are likely to matter more for detecting post-compromise behavior. For network-facing server bugs, network signatures may be more directly relevant, but they remain a supplementary control rather than remediation.
A practical Windows patch plan
A proportionate response to this release can be organized around exposure and known exploitation:
- Confirm September update deployment status across supported Windows endpoints and servers. Escalate systems missing the relevant security updates.
- Prioritize the two known-exploited Windows elevation-of-privilege fixes on high-value endpoints and systems where attackers could use a limited foothold to gain SYSTEM.
- Identify Windows DNS Server installations immediately and rank them by network reachability. Treat exposed or broadly reachable servers as urgent candidates for remediation.
- Review deployed server applications and roles flagged in independent analysis, including Exchange Server, SharePoint, SQL Server, and Remote Desktop Services. Apply updates based on actual product applicability and exposure.
- Use available Snort coverage appropriately, updating and validating applicable rule sets while recognizing that signatures are partial and can change.
- Look for signs of compromise, especially on devices that remained unpatched after disclosure. A known-exploited elevation-of-privilege bug is a reason to revisit endpoint detections and incident-response triage, not just update compliance.
- Document the counting methodology used in management reports. Describe the release as a very large update cycle and avoid presenting a disputed CVE number as a definitive official total.
September 2026 is a case where precise public CVE arithmetic is less important than disciplined action. The confirmed high-priority facts are enough to support urgent work: two Windows local privilege-escalation vulnerabilities were actively exploited, a critical Windows DNS Server RCE carried a high severity and a more-likely exploitation assessment, and the broader release contains numerous issues that should be ranked against each organization’s actual software footprint. Fast patch deployment, exposure-aware server triage, and detection-informed monitoring are the appropriate response.
Update: New details narrow the highest-risk server and sandbox scenarios (September 9, 2026)
TechRepublic reports that CVE-2026-85880 may enable an attacker to escape a low-privilege AppContainer and obtain SYSTEM privileges, according to Action1’s Mike Walters. That makes the ALPC flaw particularly relevant where applications or browser-related processes rely on sandboxing as a containment layer.
The outlet also reports that CVE-2026-81963 can be exploited by a low-privileged local attacker without user interaction, according to Action1’s Jack Bicer. This reinforces the need to patch systems where attackers could already have a basic local foothold, rather than treating the flaw as a standalone remote-entry vulnerability.
For servers, TechRepublic says CVE-2026-55007 in Exchange Server requires the server to process a malicious Visio attachment and sustained low-memory conditions. That constraint may make exploitation harder than for broadly reachable infrastructure bugs, but organizations running on-premises Exchange should still assess exposure and maintenance status.
The report also identifies DHCP, Netlogon, NFS and Remote Desktop Services among infrastructure components needing exposure-based prioritization alongside Windows DNS Server.