Microsoft's September Patch Tuesday Fixed a Record 974 CVEs. Two Are Already Being Used Against Exposed Windows Boxes.
Microsoft shipped its largest Patch Tuesday on record this month. Depending on which count you use, somewhere between 964 and 974-plus CVEs, with 104 rated critical. Two of them are already being exploited in the wild. If you run a mostly Mac or Linux stack, the honest reaction is probably "not my problem." I want to make the case that it's worth five more minutes of your attention than that.
What actually shipped
The two zero-days already seen in active exploitation are CVE-2026-85880, a heap-based buffer overflow in Windows ALPC (the inter-process communication mechanism most Windows privilege escalation chains eventually touch), and CVE-2026-81963, a privilege escalation flaw in the Windows Update Stack itself. Both are the kind of bug that turns a foothold into full control, not the kind that gets you in the door in the first place, which is exactly why they're valuable to attackers who already have some access and need to escalate it.
The one I'd actually prioritize if I were running any Windows infrastructure is CVE-2026-69730, a CVSS 9.8 remote code execution bug in Windows DNS Server, described by researchers as a spiritual successor to SigRed, the 2020 DNS Server bug that was wormable across entire networks with zero user interaction. Twenty of this month's fixes are rated wormable in total. A wormable DNS Server RCE is about as bad as this category of bug gets, because DNS Server is infrastructure, not an app, and it's the kind of service that gets stood up once during setup and then never looked at again.
Beyond those three, the critical RCE flaws this month span Windows DHCP Server, Hyper-V, Remote Desktop Services, and SQL Server. That list is worth reading slowly if you've ever done any client work at all.
Why this actually touches a non-Windows solo stack
I don't run Windows day to day. Most of the people reading this probably don't either. But "I don't run Windows" and "nothing I'm responsible for runs Windows" are different claims, and the gap between them is exactly where this kind of vulnerability does damage.
Think through your own footprint honestly. Have you ever spun up a Windows Server VM for a client project and left RDP open because it was faster than setting up a VPN "just for this one deployment"? Have you ever inherited a client's existing infrastructure that included a SQL Server instance nobody on your side actually audited, because it predated your engagement and kept working? Have you ever set up a Windows-based dev or testing environment in a cloud provider, gotten what you needed from it, and never formally decommissioned it? Every one of those is a plausible, common scenario for someone whose primary stack is nothing like Windows, and every one of those is exactly the kind of forgotten asset that a wormable DNS Server bug or an RDP-adjacent privilege escalation chain finds.
The pattern with infrastructure you don't think of as "yours" in a daily sense is that it's also infrastructure you're not watching for patches. Nobody wakes up thinking about Patch Tuesday for a Windows box they set up eight months ago for a client who's since gone quiet. That's precisely the profile of the server that stays unpatched the longest.
A 20-minute audit, even if you think this doesn't apply to you
Start with an honest inventory: list every VM, cloud instance, or physical box under your control or a client's control that runs any version of Windows Server, whether or not you consider it "part of your stack." Check whether RDP is exposed to the public internet on any of them, and if it is, put it behind a VPN or at minimum restrict it by IP allowlist today, not after you've finished reading this. Check whether DNS Server, DHCP Server, or SQL Server roles are running anywhere in that inventory, since those are this month's specific critical-RCE targets. Confirm patch status on anything that turns up, and if you don't have visibility into a client's patch cadence, that's worth a direct conversation with them this week rather than an assumption that someone else is handling it.
None of this requires Windows expertise. It requires remembering that infrastructure doesn't stop being your responsibility just because it's not the stack you think in day to day.
The honest take
I don't think most readers of this blog need to become Windows security experts, and I'm not going to pretend a record Patch Tuesday changes the fundamental calculus of running a mostly Mac and Linux solo stack. The value here isn't "learn Windows security." It's a reminder that "not my stack" and "not my risk" aren't the same thing, and the gap between them tends to be measured in forgotten VMs, not deliberate decisions.
Where I could be wrong: if you genuinely have zero Windows infrastructure anywhere in your work, including nothing inherited from clients and nothing spun up for a one-off project, this entire post is irrelevant to you, and that's a smaller number of readers than I'm assuming but not zero. The actual risk here scales with how much client and legacy infrastructure you touch, not with how much Windows you personally choose to run.
What I'd actually do
Do the 20-minute audit this week, specifically the RDP exposure check, since an internet-facing RDP port is the single most common way this category of vulnerability turns into an actual incident rather than a theoretical one. If the audit turns up nothing, you've spent 20 minutes confirming you're fine. If it turns up something, you've caught it before someone else did.
Author
Lukas
@lukcombinator