In short: Microsoft’s September 2026 Patch Tuesday was a record, and it included two exploited zero-days. If you run a Windows VPS or dedicated server, apply this Patch Tuesday’s updates promptly and check that they installed.
Table of Contents
Microsoft closed out September 2026 by patching 974 separate security holes in a single release, a record month that surpasses July’s previous high of 570. Two of those 974 were already being actively exploited before the patch shipped. If you’re running a Windows VPS or dedicated server and you’ve been treating Patch Tuesday as background noise you’ll get to eventually, this is the month that habit catches up with you.
Microsoft’s own count puts 113 of the 974 at critical severity, per Krebs on Security’s coverage of the release. Most of those 113 will never touch a typical VPS, because they live in products a lot of server owners don’t run: Exchange, SharePoint, specific SQL Server configurations, client-side Office components. The actual list of what matters to someone running a bare Windows Server instance on rented infrastructure is much shorter, and worth separating from the headline number.
Active Zero-Days in This Patch Tuesday
CVE-2026-81963 and CVE-2026-85880 are both privilege escalation flaws in Windows, and both had confirmed active exploitation before Microsoft shipped the fix. Privilege escalation bugs don’t usually get an attacker in the door on their own; they matter once an attacker already has some foothold, a compromised service account, a vulnerable application running on the box, a successfully phished credential, and needs to jump from limited access to full administrative control.
That’s exactly the scenario a VPS running any public-facing application (a CMS, a database, a custom web app) needs to worry about: the initial entry point doesn’t have to be sophisticated if a known, actively-exploited privilege escalation path is sitting there unpatched afterward. The reporting doesn’t say whether public exploit code exists for either one, so assume it is only a matter of time: active exploitation usually means a narrower group of attackers is already using a flaw quietly, and that window closes the moment a public exploit follows.
Critical Remote Code Execution
Of everything in this release, CVE-2026-69829 is the single most consequential item for anyone running a Windows Server accessible from the internet. It’s a remote code execution flaw in Windows Shell with a CVSS score of 9.8, out of a possible 10. Security researchers describe it as exploitable “with low attack complexity, no privileges, and no user interaction,” meaning an attacker needs nothing beyond network access to the vulnerable endpoint to attempt remote code execution. For a VPS or dedicated server that’s reachable on the open internet by definition, that combination (no login needed, no user has to click anything, low skill required) is the profile of a bug that gets weaponized into automated scanning tools within days.
The practical mitigation beyond patching: restrict exposure of the affected endpoints to untrusted network traffic wherever the server’s role allows it, and tighten firewall rules so only the ports and services actually in use are reachable from outside. A server that only needs to expose HTTPS to the world shouldn’t have Windows Shell-adjacent services reachable from the open internet in the first place, regardless of this specific CVE.
DNS Vulnerability Risks
CVE-2026-69730 affects Windows Server 2012 and later plus Windows 10, and it’s a DNS weakness an unauthenticated attacker can trigger just by sending a specially crafted packet, no credentials, no prior access. This one is easy to overlook because it doesn’t sound as dramatic as a 9.8 RCE, but anyone running the DNS Server role on a Windows VPS (not everyone does; plenty of hosting setups point DNS elsewhere) should treat it as a same-priority patch, not a follow-up item. An unauthenticated, packet-triggered flaw in a service that’s often left running with minimal monitoring is exactly the kind of thing that sits unnoticed for a long time once exploited.
Automated Scanning Mechanics
A newly provisioned VPS does not get discovered by attackers through some targeted process; it gets discovered because the entire IPv4 address space assigned to hosting providers is continuously indexed by mass internet-scanning services, the same category of tool security researchers use defensively (Shodan and Censys are the well-known examples) and that attackers run privately with the same underlying technique. Hosting provider IP blocks are publicly known and get re-scanned on a rolling basis measured in hours, not months.
That means a server running an internet-facing service with an unpatched, low-complexity RCE like CVE-2026-69829 does not need to be individually targeted to get hit; it just needs to still be listening on the wrong port by the time the next scan sweep passes over that address range. This is the actual mechanism behind “exploited within days of a record patch release”: not a human attacker picking out your server specifically, but automated tooling that will eventually try every reachable address whether anyone is watching that specific IP or not.
Patch Tuesday Volume Trends
2026 has now produced more than 2,600 Microsoft security patches year to date, and the monthly pace has been climbing, not flattening. That trend matters beyond any single month’s headline count: it means the assumption that “patch once a quarter is probably fine” gets less defensible every month, not more. A server that goes unpatched for even six to eight weeks between Patch Tuesdays in the current environment is realistically carrying multiple unaddressed critical vulnerabilities, some of which may already have proof-of-concept exploit code circulating publicly by the time the next month’s release lands.
Beyond Patch Tuesday: Independent VPS Patching Strategies
Most of the standard Patch Tuesday advice out there, phased rollout across test rings, WSUS-managed deployment waves, dedicated patch management tooling, assumes an IT department managing hundreds of endpoints. That doesn’t map cleanly onto running one or a handful of VPS or dedicated server instances. A more realistic approach for that situation:
- Take a snapshot or full backup immediately before applying updates, not after. If a patch causes an unexpected issue on reboot, a same-day restore point is the difference between a five-minute rollback and a multi-hour recovery.
- Schedule the actual update-and-reboot cycle during a real low-traffic window for your specific audience, not just “overnight” by default; check your own traffic logs rather than assuming a generic off-hours window applies.
- If you’re managing more than one server, patch a non-critical one first and let it run for a day before touching anything customer-facing, even without a formal test-ring setup. A single canary server catches most patch-induced problems before they become universal outages.
- After rebooting, actually verify the services you depend on came back up correctly. Windows updates occasionally change a service’s startup type or fail silently on a dependency; a quick manual check of your running application, not just “the server responded to ping,” confirms the patch didn’t break something quieter than an outright crash.
- Prioritize by exploitation status first, severity score second. A lower-CVSS flaw with confirmed active exploitation (like the two privilege-escalation zero-days here) is a more urgent patch than a higher-scoring flaw nobody has weaponized yet.
Securing Your Infrastructure
When managing a Windows environment against record-breaking patch drops, maintaining operational security comes down to triage rather than exhaustion. Not every one of the 974 fixes deserves equal urgency on a typical VPS. Flaws specific to Exchange Server, SharePoint, or Office client applications don’t apply if you’re not running those roles or products, and chasing every CVE in a record-size release is a good way to burn a maintenance window on things that don’t touch your actual attack surface.
The honest priority order for most server owners here is: the two actively-exploited zero-days first, the 9.8 Windows Shell RCE second if the server is internet-facing, the DNS flaw third if you run that role, and everything else on the normal monthly patching cadence rather than an emergency one. If you only take one thing from a 974-patch month, make it that ordering: exploitation status beats severity score, and a server sitting unpatched on the open internet for weeks is the actual risk, not the size of this month’s release notes.