Published 2026-11-11 · source: the November 10 KB articles (KB5132061, KB5132059, KB5131087, KB5131080, KB5131090), Windows release health (Windows 11 24H2 and 25H2; Windows Server 2025, 2022, 2019 and 2016; Windows 10 22H2), the Windows message center, KB5135557, KB5135999, KB5130994, KB5127648 and the Exchange Team blog, all read 2026-11-11
The November 2026 updates fix one actively exploited vulnerability: the Outlook spoofing bug that leaks a user's NTLMv2 hash when a crafted message file is opened (CVE-2026-124194, added to CISA KEV on 2026-11-10, federal deadline 2026-11-24). Microsoft lists no known issues for any of the November Windows 11 or Windows Server packages at release. Two deliberate security changes ship in the same packages, and they are the things most likely to reach your service desk as "the update broke something": Windows clients now offer NTLM message signing by default (phase one of a change that will have servers require it in May 2027), and PowerShell now rejects signed scripts whose bytes are not valid UTF-8. The same updates close October's regressions: the Exchange outage, the printer error 87, the Remote Desktop 0xC000000D failure and the Smart App Control toggle on Windows 11 24H2, the USB Audio 1.0 failure from September, and the RD Web Access XSLT breakage. This page is the second half of the picture our monthly patch brief gives you: that one says what to patch, this one says what to watch when you do. The October page has been updated to match. We update this page as Microsoft's status changes, and every change is listed at the end.
Every November 10 Windows package we read carries the same line under "Known issues in this update": "Microsoft is not currently aware of any issues with this update." The Windows Server articles carry over two older entries, both already closed or long-standing (see the table).
| Platform | November 10 update | Build | Known issues listed |
|---|---|---|---|
| Windows 11 24H2 / 25H2 / 26H2 | KB5132061 | 26100.9974 / 26200.9974 / 26300.9974 | none |
| Windows 11 26H1 | KB5132059 | — | none |
| Windows 11 23H2 (Enterprise and Education) | KB5131087 | — | none; this is the last update for these editions |
| Windows Server 2025 | KB5131080 | 26100.33822 | the October Exchange entry, now marked resolved by this update; WSUS error details (standing, below) |
| Windows Server 2022 | KB5131090 | 20348.5870 | the same two |
| Windows Server 2019 / Windows 10 1809 | KB5131085 | 17763.9376 | release health lists the Exchange and USB audio issues as resolved by it |
| Windows Server 2016 | KB5131291 | 14393.9612 | release health lists the Exchange and USB audio issues as resolved by it |
| Windows 10 22H2 | KB5131096 | 19045.7725 | release health lists the USB audio issue as resolved by it |
Read "at release" literally. October's Exchange outage was not a known issue on Patch Tuesday either; Microsoft opened it three days later. We re-read these pages and update this one when that happens.
Standing, not new: the Windows Server articles still list "Windows Server Update Services (WSUS) does not display error details". Since KB5070881 (Server 2025) / KB5070884 (Server 2022), WSUS does not show synchronization error details; Microsoft says the functionality "is temporarily removed to address the Remote Code Execution Vulnerability, CVE-2025-59287". No change this month.
KB5132061 (and every other November package we read) says: "This update improves NTLM security by enabling clients to offer NTLM message signing by default for non-anonymous connections. This change helps reduce exposure to NTLM relay attacks and provides auditing to identify connections that are not using signing."
Microsoft's companion article KB5135557, NTLM signing security improvements in Windows, says the November updates "contain additional protections that address CVE-2026-118737" and are "the first phase of improvements to NTLM message signing". That CVE is one of this month's Critical-rated bugs (CVSS 8.1, network, no authentication, no user interaction); see it in the brief's index. So this is the fix for a Critical vulnerability, not an optional hardening you can switch off.
Microsoft's timeline:
Why this is the one to test: before this change, applications that did not ask for integrity protection got a placeholder "always sign" flag with, in Microsoft's words, "no cryptographic protection". Windows clients now negotiate real signing. Third-party NTLM clients, appliances and old applications that cannot negotiate signing still work this month, but they will be refused by Windows servers from May 2027. You have six months to find them, and Microsoft gives you the instrument: event 4023 (server side) and 4022 (client side) in the Microsoft-Windows-NTLM/ log show the negotiated flags for every NTLM authentication (Windows Server 2019 and later, with NTLM enhanced auditing). A 4023 warning of "Signing Absent" is a client that phase two will reject.
What to do: install the November update on your normal cycle. Turn on NTLM auditing on your servers and start collecting 4023 events now; every "Signing Absent" is a remediation item with a May 2027 deadline. Do not read this as a reason to defer: the same packages fix CVE-2026-118737.
KB5132061 says: "This update strengthens security for PowerShell script signing and signature verification by introducing stricter encoding validation. As a result, scripts containing invalid UTF-8 encoding might fail signature validation, even if they were previously accepted. To resolve this issue, review the affected scripts, save them using valid UTF-8 encoding with a byte order mark (BOM), and sign them again."
Microsoft's companion article KB5135999, Encoding Guidance for Signed PowerShell Scripts, applies to Windows 11 23H2 through 26H2, Windows 10 Enterprise LTSC 2021 and Windows Server 2016 through 2025. It calls this "an intentional security-hardening change" that "may cause affected scripts containing malformed UTF-8 to fail signature validation after the update, even if they previously validated successfully". Windows "rejects malformed UTF-8 files that could previously be decoded using replacement characters"; for those files "signing might fail or an existing signature might be reported as NotSigned". Two warnings from the article worth repeating: "Adding a BOM alone does not correct invalid bytes", and "Not every signature failure is caused by encoding."
Who it hits: estates that run with an AllSigned or RemoteSigned execution policy, or that gate scripts on their signature in other ways (application control, scheduled tasks, deployment tools), and whose signed scripts contain non-ASCII bytes saved in a legacy code page: accented names, curly quotes, em dashes, box-drawing characters in banners. A script that is pure ASCII is unaffected. The symptom is a script that ran last month and is now reported as NotSigned or blocked by execution policy.
What to do: before broad rollout, run Get-AuthenticodeSignature across your signed scripts on a pilot machine that has the update and look for NotSigned where you expect Valid. Re-save affected files as valid UTF-8 with a BOM, re-sign them, and redeploy. Keep the original bytes until the re-signed copy is proven.
First, the exploited Outlook bug. CVE-2026-124194 is fixed in the November Office updates (Microsoft 365 Apps and the perpetual Office editions), not in the Windows cumulative update, so it rides your Office update channel. CISA added it to KEV on 2026-11-10 with a 2026-11-24 deadline. Until Outlook is updated, the attack only pays off if NTLM can leave your network; blocking outbound SMB (TCP 445) and WebDAV at the perimeter is the standing mitigation. See the brief.
Second, Windows 11 24H2 catches up with the October preview fixes. Microsoft stopped shipping optional preview updates for 24H2, so the 2026-10-28 fixes reached 25H2, 26H2 and 26H1 first. KB5132061 brings them to 24H2:
Third, the Exchange outage is fixed on every Windows Server version. Release health now reads "Resolved: 2026-11-10" for "Users might be unable to sign in to OWA or send emails on Exchange Server" on Windows Server 2025 (KB5131080), Windows Server 2022 (KB5131090), Windows Server 2019 (KB5131085) and Windows Server 2016 (KB5131291). The Exchange Team's November post says: "Customers who have created the registry key to address the issue in October can leave the registry key in place, but the key is not required once November 2026 Windows Server updates are installed. It does not matter in which order November 2026 Exchange Server vs. Windows Server updates are installed." Release health adds: "If you install an update released November 10, 2026 (KB5131080) or later, you do not need to use a workaround for this issue."
Fourth, two October regressions Microsoft never listed as known issues are fixed. Every November package says: "[Printing] Fixed: Adding a printer published in Active Directory through Settings … might fail with error 87, 'The parameter is incorrect.' This issue was introduced by the October 2026 update and does not generally affect existing printers or printing." KB5132061 and KB5132059 also fix "an issue where Remote Desktop Protocol (RDP) connections might fail on the client due to a certificate mismatch after the October 2026 non-security preview update".
Fifth, RD Web Access works again with XSLT disabled. The Windows Server updates say RD Web Access "pages are now rendered on the server and no longer depend on browser XSLT support". KB5130994 now adds: "If you deployed any of the three workarounds in this article, we still recommend that you install the November 2026 Windows security update. If you re-enabled XSLT as a workaround, you should disable it again."
Also fixed on Windows Server 2025 (KB5131080): device certificate enrollment failures caused by certificate handles that did not persist; the Intune policy "Specify thumbprints of certificates representing trusted .rdp publishers" could not be configured; an in-place upgrade from Windows Server 2016 to Windows Server 2025 failed its compatibility check (error 0x80070003 - 0x40008) with media that included the October update. One entry is a behaviour change dressed as a fix: after this update the Import-WdsInstallImage cmdlet "requires administrator privileges", and running it as a non-administrator fails with ACCESS_DENIED.
NotSigned as valid UTF-8 with a BOM and re-sign them.EpmapSavedContextCap registry value can stay; it is no longer required. If you still run Exchange 2016 or 2019, Microsoft now says to treat them as permanently vulnerable.Decide per workload, not per estate: each of these hits a specific role and leaves the rest of the fleet alone.
2026-11-11: first published.
Published 2026-11-11 from Microsoft's November 10 KB articles, Windows release health, the Windows message center, KB5135557, KB5135999, KB5130994, KB5127648 and the Exchange Team blog, all read 2026-11-11. Known-issue status, affected platforms and fix availability change without notice. Verify against Microsoft's current page before acting on anything here. Prepared for practitioners. Not affiliated with, or endorsed by, Microsoft.
Microsoft documentation below was read on 2026-11-11.
Compiled by patchtriage.com. We verify against vendor primary sources and say so when we cannot.