Did Patch Tuesday Break Microsoft 365? Microsoft's Own Incident Notes Name No Link. Here Is What They Do Name, Plus the Four Update Problems Microsoft Has Confirmed
Here is what to do this week. Install the November Windows update. Its one exploited bug is in Outlook, and CISA wants it patched by Tuesday, November 24. Before you push the update to everything, read the four problems Microsoft has confirmed with it, because two of them can hurt a small shop: Windows activation scripts that fail, and SQL Server boxes that slowly fill up with open connections. And no, nothing Microsoft has published says the Microsoft 365 outage that started Thursday was caused by Patch Tuesday. You can't fix that outage from your side, so don't roll back your Windows patches over it.
Was the outage caused by Patch Tuesday?
Short answer: no evidence says so, and Microsoft's own account points somewhere else. Here is what we could confirm and what we couldn't.
Two things happened this week, and they run on separate tracks. Patch Tuesday was Tuesday, November 10. It updates Windows PCs and the servers you run yourself, on your schedule, after you approve it. The outage started Thursday, November 12. It hit Microsoft 365 services that Microsoft runs in its own datacenters and changes on its own schedule. The two events were about 46 hours apart, and being close in time doesn't make one the cause of the other.
What Microsoft has said. The broad incident is MO1550821, "Users may be unable to connect to multiple Microsoft 365 services." It covers Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR and, as the day went on, Intune, Purview, Power BI, Windows 365 and others. Exchange Online has its own incident, EX1550543. BleepingComputer puts the broad incident's start at 1:26 PM Eastern, which is 18:26 UTC. A separate Teams incident that morning, TM1550488, ran 9:45 to 10:53 AM Eastern, and Microsoft blamed it on resource contention. That one is resolved.
In Microsoft's own words, as BleepingComputer and The Register quoted them:
- The load "isn't driven by an increase in traffic" but comes from "servers being unexpectedly unavailable; straining the remaining infrastructure."
- The servers have "a problem that's causing servers to fail automated health checks and become unavailable," and the failed checks "may originate from a specific component that's responsible for processing server health."
- "A core process on the affected servers is becoming overwhelmed."
- Microsoft is "assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery."
- "At this time, we have no evidence of malicious activity associated with this incident," per the status page, quoted by SecurityWeek.
A third-party copy of the service health updates (ENow's transcription) adds the rest of the sequence. Microsoft paused all deployments and configuration changes as a precaution. At one point it said it had found no correlated recent change. Later it said a secure-connection process was overwhelmed, that it was reverting a recent network configuration change, and that it was rebuilding some servers on a previous software configuration. In the last update we read, it described a surge in calls from routing services to backend servers. As of BleepingComputer's 8:05 AM Eastern update on Friday, recovery was gradual and not complete. Microsoft also extended its email timeout to 48 hours so delayed mail isn't lost. SecurityWeek quotes Microsoft saying it "will share a full Post-Incident Report with root cause and defense-in-depth actions after mitigation is complete." That report hasn't been published yet.
What none of it says. Not one of those updates mentions Patch Tuesday, a Windows security update or a KB number. The changes Microsoft names are its own service changes: configuration updates, a network configuration change, a health-check component and server software configuration.
What we could not check. The Microsoft 365 Status account on X returned an error to our fetch, and the service health dashboard needs a tenant login, so we read Microsoft's words through BleepingComputer, The Register, SecurityWeek and ENow's transcription. Those are four copies of one source, Microsoft, not four independent confirmations. Two secondhand claims are circulating, and we can't verify either one. Reuters, via CNBC, quotes Australia's Home Affairs minister Tony Burke saying Microsoft believes it is dealing with something similar to CrowdStrike, "where there is an update that has gone awry." That's the minister's account of Microsoft's view, and he didn't say it was a Windows update. Wikipedia's article on the outage attributes the phrase "settings applied to servers after an update" to press reports. We couldn't find that wording in Microsoft's own text. Reader comments under BleepingComputer's story blame Windows Update. That's speculation.
Patrick's other idea: an update that broke a dependency Microsoft didn't understand. Our evidence can't confirm it or rule it out, so we're leaving it as an open question. One dated fact is worth knowing, though. Microsoft has already documented this kind of break once this fall, on the on-premises side. Its Windows Server release health page says the October 13 Windows update added a default limit of 512 simultaneous Endpoint Mapper lookup calls. Under heavy load, that limit left some on-premises Exchange servers unable to sign users in to Outlook on the web or send mail. The November 10 update fixed it (KB5131080 on Windows Server 2025). So a Windows update did break Exchange in the last month. But that was Exchange Server, the product you run yourself, and it was fixed by the very update people now suspect. Microsoft hasn't said what software its Exchange Online servers run or which "previous software configuration" it rolled back to. The post-incident report is where this gets settled. We'll read it when it's out and update this post if it names a Windows component.
Our verdict, at our usual 95 percent: Microsoft's own account links the outage to Patch Tuesday nowhere. It names server health checks, an overwhelmed secure-connection process, and a network configuration change it was reverting. Rolling back your November Windows update won't bring back Outlook, and it would leave the exploited Outlook bug open on your machines.
The one bug already being used
CVE-2026-124194 is an Outlook flaw. A crafted message, once opened, makes Outlook connect to a server the attacker controls without the usual warning, and that leaks the user's NTLMv2 hash, a login credential that can be cracked offline. Microsoft marks it "Exploitation Detected." Its own security update data rates it Moderate, CVSS 6.5, with user interaction required. It's one of only two Moderate entries among the 1,082 published that day, so a severity filter set to Important and above would skip this month's only exploited bug. The credit reads "Benoit Sevens using Claude with Anthropic."
CISA added it to the Known Exploited Vulnerabilities catalog on Tuesday, November 10 (catalog version 2026.11.10, the newest when we downloaded it on November 13), with a due date of Tuesday, November 24. That's a 14-day clock, not the three-day deadlines CISA has used for many entries this year. It's the fifth Outlook-named entry in the catalog, after CVE-2017-11774, CVE-2023-23397, CVE-2023-35311 and CVE-2024-21413.
We covered it in depth on November 11: Outlook Zero-Day CVE-2026-124194 Leaks a Login Hash When a Crafted Message Is Opened. The short version: patch Outlook, and block outbound SMB (TCP 445) from user machines to the internet so a leaked hash has nowhere to go.
Code for it. Our exploit harvester holds one public repository for this CVE, first logged November 11 at 06:01 UTC. We checked it again today through the GitHub API without running anything. It contains seven files: two READMEs, a .gitignore and four Python scripts. It has no GOAL.md and no lab or evidence directory, so it doesn't look like an AI-agent lab reproduction built against a model of the bug. Its author describes it as a "concept proof only, untested against vulnerable Outlook." That's what we'd call it too: a concept proof, not a proven exploit. It had nine stars when we looked. We aren't naming it, for the reason in the November 11 post.
The other 1,081
The count first, because three numbers are going around. Microsoft's machine-readable security update document for November (the MSRC CVRF feed, which we pulled on November 13, current as of 01:44 UTC that day) holds 1,476 CVE records. Microsoft keeps adding to it all month. 1,082 of them were first published on Patch Tuesday itself, and Microsoft is the assigning authority for 1,081 of those. That's our count for "Patch Tuesday." BleepingComputer's 1,235 includes 142 Chromium-based Edge fixes that Google assigned. The 1,094 on Wikipedia is close to the 1,095 records in the whole document that Microsoft assigned. The rest of the document is mostly Chromium (220) and Linux kernel and open-source entries for Azure Linux. All three numbers are defensible. They just count different things.
Among the 1,082: 63 Critical, 1,017 Important, 2 Moderate. By type, 530 elevation of privilege, 297 remote code execution, 155 information disclosure, 41 denial of service, 25 security feature bypass, 22 spoofing and 11 tampering. Microsoft rates one "Exploitation Detected," 42 "Exploitation More Likely," and the rest lower or not rated. None is marked publicly disclosed.
The Critical remote code execution list includes services that small networks run and forget about: Windows TCP/IP, the SMB server transport driver, IIS, Schannel, LDAP, Active Directory Domain Services, Windows Deployment Services, Message Queuing (five entries), CredSSP and the RPC runtime. It also has Exchange Server (CVE-2026-118207, CVSS 8.8, needs a low-privilege login, "Exploitation More Likely") and three in Outlook. If you run on-premises Exchange, that one moves to the front of your queue. The RPC runtime fix (CVE-2026-118737) also changes behavior: Microsoft's message center says the November update turns on NTLM message signing by default for non-anonymous client connections, with auditing. Very old devices or appliances that can't sign NTLM are worth testing before a broad rollout.
The AI credits we said we'd check. In October, 68 of 1,415 credited an AI tool by name. This month, 59 of the 1,082 do: diffract-ai on 44, z.ai's GLM on 12, XBREACH.AI on 2, minsight-ai on 1, and Claude on 1, the exploited Outlook bug. We counted only credits that name a tool, not researchers whose employer is an AI company. The share is a little higher, about one in eighteen.
One Windows privilege escalation is public and not fixed by any of this: SignDrop, a Common Log File System (CLFS) exploit to SYSTEM with no CVE. We covered it yesterday: SignDrop: A Public Windows CLFS Exploit to SYSTEM With No CVE and No Patch.
The fallout Microsoft has confirmed
Four problems, each confirmed by Microsoft. Two are on its public release health pages. The other two, as far as we can find, are only in the Microsoft 365 admin center, which you need a tenant login to read. We read the public pages through their November 12 updates (18:02 UTC for most, 23:20 UTC for Windows 11 26H2 and the message center).
KB5132061 fails to install (reported November 12). KB5132061 is the November update for Windows 11 26H2, 25H2 and 24H2 Enterprise and Education (builds 26300.9974, 26200.9974 and 26100.9974). On some devices that had the October non-security preview KB5127936, the install stalls and fails with 0x800f0989 or 0x800f0993, or retries with 0x80070306. Microsoft is pushing an automatic repair "in 24 to 48 hours starting from November 11, 2026, 10am PT," and users don't need to do anything. Microsoft's KB page lists it as the update's only known issue, and its scope note there says 24H2 Enterprise and Education only. Admin center ID WI1549693. Status: repair rolling out, not yet marked resolved. No Known Issue Rollback is mentioned. If a machine is still failing after 48 hours, open a support case.
SQL Server linked-server connections pile up (confirmed November 11, 15:11 PT). This one started with the October 13 update (KB5127648 on Windows 11, KB5126646 on Server 2025), so the November update didn't cause it and doesn't fix it either. SQL Server linked-server queries that use OLE DB providers to reach external databases, including Oracle and PostgreSQL, leave connections open after they finish. Over time, the server slows down. It affects Windows Server 2012 through 2025 and a range of Windows 10 and 11 versions. The workaround: close idle connections or restart the SQL Server service. Both are temporary and can interrupt running work. Microsoft Support for business has a mitigation you can request. Microsoft says the real fix is an out-of-band update "in the next few days." Status: Confirmed. This is the one to watch if you run an accounting or line-of-business database that pulls from Oracle or Postgres.
Activation fails with 0x80041008 (reported November 13). Microsoft's admin center alert WI1549486, as BleepingComputer read it, says the November updates make "slmgr.vbs /skms-domain" and "slmgr.vbs /ipk" fail with "Invalid parameter (SWbemObjectEx)." That hits anyone setting up KMS activation or installing product keys with scripts. It affects Windows 10 21H2 and 22H2, Windows 11 23H2, and Windows Server 2019, 2022 and 2025. Machines that are already activated stay activated, and KMS clients normally hold activation for up to 180 days. A fix is coming "over the coming days." No workaround is published beyond a support case, and no Known Issue Rollback is mentioned. We didn't find this on the public release health pages, and BleepingComputer didn't name the originating KBs. If you're imaging new machines this week, use images that already carry a KMS client key, or hold off on key changes.
Printing fails for some documents (reported November 13). Admin center alert WI1549472: "printing might fail for documents containing images rendered with a height or width value of zero." Those are things like invisible watermarks and layout anchors. It mostly affects Word printing through the Windows Graphics Device Interface, on Windows 10 and later and Windows Server 2016 and later. Microsoft has acknowledged it. We found no workaround, no Known Issue Rollback and no fix date. It also isn't on the public pages we read.
One more, for balance. The November update fixes three earlier problems: the on-premises Exchange break described above, USB Audio Class 1.0 devices failing with Code 10, and Remote Desktop error 0xC000000D for non-admin users on hosts with Administrator protection on 24H2.
What our edge saw
Nothing, and that's expected. The exploited Outlook bug arrives by email, and the leaked hash goes out from the victim's machine to the attacker's server. Neither leg touches a web edge like ours, so we didn't run an edge check for it. A zero from us would describe our blind spot, not the threat. SignDrop is a local privilege escalation, which an edge can't see either. The outage isn't an attack at all, by Microsoft's account.
For context from the catalog, which counts confirmed exploitation, not patch volume: Microsoft has 391 KEV entries, more than any other vendor. CISA added Microsoft entries in ten of the eleven months of 2026 so far (none in June), with a high of eight in February and in April. This month and last, it added one each. Across all vendors, our KEV stickiness check over the last 180 days (187 additions) finds that products with an exploitation history keep getting exploited (Spearman rho 0.5), but half the new entries are products that had never appeared before. Outlook is the sticky kind.
If you only have an hour
- Push the November update to the machines that read email first: front desk, billing, HR. Block outbound TCP 445 to the internet at your firewall if you haven't already.
- Before you patch servers, check whether any of them run SQL Server with linked servers to Oracle or PostgreSQL. Those already carry October's connection leak. Patch them anyway, then watch their connection counts or schedule a service restart until Microsoft's out-of-band fix lands.
- If you run on-premises Exchange, install the November update. It fixes October's Endpoint Mapper break and the new Critical Exchange RCE.
- Pause any KMS or product-key scripting until the activation fix ships.
- Don't roll back Windows updates because of the Microsoft 365 outage. Nothing Microsoft has said connects them. Note the incident IDs (MO1550821, EX1550543) in case you claim a service credit, and read the post-incident report when it comes out.
Primary sources: Microsoft's November 2026 security update data (MSRC CVRF), CISA's KEV catalog version 2026.11.10, Microsoft's Windows release health pages and KB5132061, and Microsoft 365 service health text as quoted by BleepingComputer, The Register, SecurityWeek and ENow. SAP's November 10 patch day is covered separately: SAP Patched Four CVSS 10 Flaws Today.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.