I’ll be honest — I almost skipped writing about this one. Windows updates happen every month, right? You click install, wait twenty minutes, your system restarts, and you forget it ever happened. But this April update is different. Not in a marketing-brochure way. In a “there are some genuinely scary bugs in here and also Microsoft quietly changed how updates work forever” kind of way.
So let me break it down. What’s in this update. Why some of it actually matters. And what the security community is a bit worried about even after the patches landed.
The update in question is KB5083769 — released April 14, 2026. It applies to Windows 11 versions 24H2 and 25H2, bumping them to build 26100.8246 and 26200.8246 respectively. If you’re still on 23H2 for some reason, you got KB5082052 instead, landing at build 22631.6936. Windows 10 also got its own update, KB5082200, as part of the extended security update program. So basically every Windows version that Microsoft still officially supports got hit at the same time.
The total bug count? Depending on who you ask, somewhere between 163 and 167. Tenable’s Satnam Narang called it the second-biggest Patch Tuesday in Microsoft’s history. Zero Day Initiative’s Dustin Childs agreed. The biggest ever was apparently October 2025 with 167 CVEs. This one is right behind it. And to put that in perspective — February this year had 59, March had 83. So April is basically double March. Something changed.
Why So Many Bugs All of a Sudden
This is actually interesting. The answer, according to multiple security researchers, is AI.
Specifically, AI tools that find bugs. Dustin Childs at ZDI wrote that their own incoming vulnerability report rate has “essentially tripled” because researchers are now using AI to scan codebases at speeds no human team could match. Adam Barnett from Rapid7 pointed out that nearly 60 of this month’s bugs were browser-related, which he said probably doesn’t have anything to do with any specific AI announcement — it’s just that the Chromium project gets contributions from a huge range of researchers, and those researchers are increasingly AI-assisted.
So yeah. The reason this patch is so big is partly because AI is getting really good at finding software vulnerabilities. Which is a weird thing to think about. The same kind of technology that’s going into your Windows AI features is also being used to find holes in Windows itself. And that’s going to keep happening — Barnett said explicitly that vulnerability report volumes will “likely increase further” as AI tools get more capable.
This is both good news and bad. Good because these bugs are getting found and patched instead of being quietly sold to someone who wants to break into your network. Bad because the attack surface of any large software system is apparently much bigger than we thought, and now we have tools to see it clearly. I’m not sure if “we found more bugs so we’re more secure now” is supposed to feel reassuring. Kind of does and kind of doesn’t.
The Bug That Was Already Being Used Against You
The most urgent fix in this update is CVE-2026–32201. This is a spoofing vulnerability in Microsoft SharePoint Server, and it was already being actively exploited before Microsoft released the patch. That means attackers knew about it, had working exploit code, and were using it against real organizations while your IT team was still planning when to schedule the update rollout.
The CVSS score is 6.5, which sounds medium-severity. But the “actively exploited in the wild” tag changes the math completely.
So what does this bug actually do? SharePoint is the thing a lot of companies use to share documents and collaborate internally. This vulnerability involves improper input validation — basically SharePoint wasn’t checking whether the content being fed into it was legitimate before processing it. An attacker without any login credentials could send malicious data over the network and make SharePoint show users fake or modified content.
Mike Walters from Action1 explained it clearly: this bug can be used to run phishing campaigns inside trusted SharePoint environments. Think about what that means. Your company uses SharePoint for internal documents. An attacker exploits this bug. Now they can make a SharePoint page show employees a fake login form, or a fake document telling staff to urgently wire money somewhere, or a fake IT notice asking people to install something. And because it’s coming from inside your own SharePoint, people trust it.
The technical name for what the attacker can do is spoofing — they can present falsified information and potentially read sensitive information that was exposed through the attack. Microsoft’s own advisory says the attacker “could view some sensitive information (Confidentiality), make changes to disclosed information (Integrity), but cannot limit access to the resource (Availability).” So they can’t crash your SharePoint, but they can read what they shouldn’t and modify what they touch.
For anyone running SharePoint Server 2016, 2019, or Subscription Edition on-premises, this is a top-priority patch. Cloud SharePoint in Microsoft 365 was patched on Microsoft’s side separately, so those customers don’t have to do anything. But if your company runs its own on-prem SharePoint — and many do, especially in regulated industries — you need this update fast. There’s also a companion vulnerability patched at the same time, CVE-2026–20945, which covers a related spoofing path in the same code. Both need to be addressed.
BlueHammer: When a Researcher Gets Fed Up
CVE-2026–33825 is the other zero-day in this update — different kind though. It wasn’t being actively exploited when the patch dropped, but the proof-of-concept exploit code was already publicly available. Which is almost as bad.
This is a privilege escalation flaw in Microsoft Defender. It’s been nicknamed “BlueHammer.” The story behind it is kind of wild. A researcher found the bug, reported it to Microsoft through the normal responsible disclosure process, and then apparently got very frustrated with Microsoft’s response time. So they just… published the exploit code publicly. On April 3, 2026, before Microsoft released a fix.
The fix ships as part of Microsoft’s Antimalware Platform update, version 4.18.26050.3011. If you have Windows Defender and Windows Update enabled, this gets pulled in automatically with your Defender definition updates — you don’t need to wait for the full cumulative update to get this one specifically. But the full cumulative update includes it too, so either way, you need to update.
What does this bug actually do? It’s a privilege escalation flaw — meaning an attacker who already has basic access to a Windows machine (a low-privileged user account, for example) can use this to get full SYSTEM-level access. In a corporate environment where an attacker has already compromised one account through phishing or stolen credentials, this kind of bug is what turns “we have a foothold” into “we own the whole machine.” It’s rated 7.8 on the CVSS scale, labeled Important rather than Critical, but the public exploit code made it much more practically dangerous than the score suggests.
The Really Scary One: TCP/IP Stack, No Login Required
CVE-2026–33827. This is the bug that the security research community was most rattled by, even though it wasn’t actively exploited when the patches dropped.
It’s a remote code execution vulnerability in Windows TCP/IP. TCP/IP is the fundamental networking code that basically every Windows machine uses to communicate. The bug is a race condition — which I’ll explain in a second — and it allows an attacker to run code on your machine without needing any login credentials and without you clicking anything. Just being on the network is enough, under the right conditions.
A race condition works like this: two processes are fighting over the same piece of memory at the same time. If the attacker can win that race — send their malicious packet at exactly the right moment so it lands when the code is in a vulnerable state — they can write data somewhere they shouldn’t be able to write. If they write the right data to the right place, they execute arbitrary code. The difficulty is in the timing. Race conditions are finicky to exploit reliably. But as the SANS Internet Storm Center analyst noted, “never underestimate the creativity of an AI aided attacker” on this one.
The specific conditions: systems with both IPv6 and IPSec enabled are most at risk. ZDI flagged this as potentially “wormable” — meaning a working exploit could theoretically spread from machine to machine automatically without any human interaction, similar to WannaCry back in 2017. That comparison is worth taking seriously even if the conditions here are more restrictive. If you’re on IPv6 (which is increasingly common as networks modernize), get this patch installed before anyone figures out a reliable exploit.
The formal description from Microsoft is: “Concurrent execution using shared resource with improper synchronization (‘Race Condition’) in Windows TCP/IP allows an unauthorized attacker to execute code over a network.” CVSS officially scores it 8.1, though some sources had initial confusion and listed it as 9.8 — turns out 9.8 belongs to the IKE bug which we’ll get to in a moment.
CVE-2026–33824: The Other Wormable One
So this month has two potentially wormable bugs. That’s not normal.
CVE-2026–33824 is a vulnerability in Windows Internet Key Exchange (IKE) Service Extensions. IKE is part of IPSec — it’s the protocol that handles setting up encrypted tunnels between machines or across VPNs. CVSS score of 9.8, which is basically as high as it gets.
An attacker who successfully exploits this can run code on the target system remotely, without authentication. ZDI says this one is also potentially wormable. Microsoft noted a mitigation: blocking UDP ports 500 and 4500 at the firewall will stop external attackers from reaching the IKE service. So if your firewall is correctly configured and you’re not exposing IKE to the internet, outside attackers can’t get to you through this. But IKE is commonly used for internal VPN and network encryption — which means a malicious insider, or an attacker who’s already gotten past your perimeter, could still use this to move laterally through your network. So patching is still necessary even if your firewall is good.
Remote Desktop’s New Security Warning
Not everything in this update is a patch for an active threat. Some of it is changing behavior to prevent future attacks.
Remote Desktop is getting a new default behavior when you open .rdp files (those are the files you double-click to start a Remote Desktop connection). Before this update, if someone sent you a malicious .rdp file — through email, through a phishing link, however — and you opened it, Remote Desktop would connect with whatever settings were baked into that file. Attackers have been using this to redirect your local drives, printers, and clipboard to their malicious server during the connection, harvesting data or even executing code.
After the update, when you open an .rdp file, Remote Desktop now shows you all the connection settings upfront, with every setting turned off by default. You have to explicitly enable settings before connecting. There’s also a one-time security warning about the risks. This is the same kind of change that browsers made years ago when they started blocking pop-ups by default — it’s friction added to protect users from themselves. Some power users will find it annoying. Security teams will be relieved.
This also addresses CVE-2026–26151, which covers RDP spoofing attacks and is flagged as “Exploitation More Likely” in Microsoft’s risk assessment. Good change overall.
Smart App Control Can Finally Be Turned Off Without Reinstalling Windows
This one is not a security fix exactly, but it matters for a lot of people.
Smart App Control (SAC) is the Windows 11 feature that blocks applications that aren’t trusted or signed. It was introduced as a security improvement, and it works — but it had this completely baffling design decision where once you turned it on, the only way to turn it off was to completely reinstall Windows. That made it basically unusable for developers or anyone who frequently installs software that SAC doesn’t like (which can include legitimate developer tools, open-source software, and all kinds of things that aren’t malicious).
Microsoft has finally fixed this. After the April update, you can go to Settings > Windows Security > App and Browser Control > Smart App Control settings and toggle it on or off like a normal feature. That’s how it should have worked from day one. I’m glad it’s fixed, but also, it took way too long. This was a known complaint since SAC launched and Microsoft just… didn’t address it for years.
Narrator Gets Better for Everyone
The April update expands Narrator’s image description feature to all Windows 11 PCs, not just Copilot+ machines.
Before this, if you pressed Narrator Key + Ctrl + D to get a description of an image on screen, nothing happened unless you had a Copilot+ PC with on-device AI processing. Now, on any Windows 11 machine, the same shortcut opens Copilot with the image loaded, and you can ask for a description. For non-Copilot+ machines, the description goes through the cloud — the image is only sent after you choose to get a description, not automatically. Copilot+ machines still do it faster and on-device.
This is genuinely useful for blind and low-vision users who use Narrator as their main interface. Microsoft had been laying groundwork for this since January 2026 and it finally ships in the April update. The shortcut for a full-screen description is Narrator Key + Ctrl + S instead of just the focused image shortcut.
The Secure Boot Certificate Thing That Needs Your Attention Right Now
This is not a bug fix. It’s a deadline.
Microsoft’s original Secure Boot certificates were issued in 2011 with a 15-year validity window. On June 26, 2026 — that’s 73 days from now as I’m writing this — those certificates expire. Devices that haven’t received the replacement certificates (issued in 2023) will lose Secure Boot protection. Some will fail to boot entirely.
Microsoft has been delivering the new certificates through Windows Update, and the April update includes improvements to that delivery system — specifically, it now uses something called “high confidence device targeting data” to make sure the right certificates get to the right machines through a controlled rollout. The Windows Security app (Settings > Privacy & Security > Windows Security) may now show you the status of your Secure Boot certificate updates, though this is disabled by default on commercial devices.
But here’s the problem: the rollout has been uneven. If you’ve been deferring updates or have machines that don’t consistently check in with Windows Update, you might not have the new certificates yet. And there’s no retroactive fix once June 26 passes.
You can check whether your system has the new certificates by opening PowerShell and running:
Confirm-SecureBootUEFIThat tells you if Secure Boot is active. But checking whether you have the 2023 replacement certificates specifically requires looking at your UEFI certificate store, which is more involved. Microsoft’s guidance on this is at the Windows Secure Boot Certificate Expiration page. For enterprise environments, some systems manufactured between 2012 and 2025 also need OEM firmware or BIOS updates to accept the new UEFI certificates — this is hardware-level work that Windows Update alone cannot handle. So if you’re managing a fleet of older machines, you may have some manual work ahead of you.
This is the thing I’m most worried about from this whole update cycle, honestly. Not because it’s a bug — but because certificate expiration deadlines are the kind of thing that sounds like someone else’s problem until it suddenly isn’t, and you’ve got machines that won’t boot.
The Hotpatch Change: This Is Actually Big
Here’s the thing that Forbes was covering as a structural change to Windows Update itself, and it’s genuinely worth understanding.
Hotpatch updates are security patches that apply without requiring a restart. They’ve existed for a while in Windows Server environments, but Microsoft has been rolling them out for Windows 11 Enterprise as well. The idea is simple: instead of patching the on-disk copy of Windows and requiring a reboot, hotpatches patch the in-memory version of Windows while it’s running. The system keeps running, users don’t get interrupted, and you’re secured faster.
Until now, hotpatch was an opt-in feature. Starting with the May 2026 security update, Windows Autopatch will enable hotpatch by default for all eligible Microsoft Intune-managed devices. This is a big operational change for enterprise IT teams. The April update acts as the baseline for this — devices need to install the April rebooting update first before they can receive hotpatch updates in May without rebooting. Windows Autopatch is already running on over 10 million production devices according to Microsoft.
The qualifying conditions for hotpatch: you need Windows 11 Enterprise 24H2 or 25H2, you need to be managed through Windows Autopatch or Microsoft Intune, and you need to be on compatible hardware. Standard consumer Windows 11 Home or Pro doesn’t get hotpatch. And April is a “baseline month” — meaning even hotpatch-eligible devices need to install this month’s update with a full reboot, because the hotpatch infrastructure itself gets updated.
If you manage enterprise Windows devices through Intune and haven’t opted out, this change will start affecting you in May. Microsoft has added controls to opt out at the tenant level or device group level, which went live April 1, 2026. The Hotpatch quality updates report in Intune shows whether your devices are ready.
The Bugs That Didn’t Make Headlines But Should
A few other things worth knowing about:
The Reset This PC fix. In March, Microsoft released a hotpatch (KB5079420) that accidentally broke the Reset This PC feature. If you tried to use “Keep my files” or “Remove everything” on a machine that had installed that March hotpatch, the reset would fail. The April update fixes this. If you had a machine stuck mid-reset after March, you know how bad this was.
The Active Directory RCE, CVE-2026–33826. CVSS score of 8.0, Critical rating. Affects domain controllers. Exploitation is rated “More Likely” by Microsoft. Domain controllers are the core of authentication in corporate Windows environments — if an attacker can run code on one, they effectively own the whole Active Directory forest. This needs to be patched on your DCs as a priority.
The BitLocker bypass, CVE-2026–27913. Also flagged as “Exploitation More Likely.” BitLocker is the full-disk encryption that protects data on Windows machines. A bypass here means an attacker might be able to access encrypted data without the proper credentials. Details on how this works are limited, but “BitLocker bypass” plus “Exploitation More Likely” is a combination that should get IT teams moving.
The Windows Deployment Services change. In the server-side update, Microsoft has disabled the “Hands-Free Deployment” feature in Windows Deployment Services (WDS) by default. This relates to CVE-2026–0386 and is a security hardening change — hands-free deployment had a vulnerability that could be exploited, so Microsoft killed the feature as a mitigation. If you’re using WDS in your environment for automated OS deployment, you need to check whether this breaks your workflow.
Three Microsoft Word RCEs — CVE-2026–33114, CVE-2026–33115, and CVE-2026–32190. Standard document-based attack vectors. Open a malicious Word file, attacker runs code on your machine. These have shown up in every other Patch Tuesday for years. Keep Office updated and be careful about what documents you open from unknown sources.
The Remote Desktop Client RCE, CVE-2026–32157. CVSS 8.8, Critical. This one requires a user to connect to a malicious RDP server — but notably, that connection can be triggered by clicking an rdp: link in a browser or email. So it’s more phishing-adjacent than it sounds. The new .rdp file security warning in this update helps mitigate this, but patching is still the right answer.
The Kerberos Protocol Change
This one is under the radar but has real implications for enterprise environments.
The update changes the default behavior for Kerberos Key Distribution Center (KDC) operations — specifically, the DefaultDomainSupportedEncTypes value. The change means accounts that don’t have an explicit msds-SupportedEncryptionTypes attribute in Active Directory will now default to AES-SHA1 encryption instead of the older RC4 algorithm. This is related to CVE-2026–20833.
RC4 is old and has known weaknesses. AES is the modern standard. But this change can break things. If you have old domain accounts, service accounts, or legacy applications that are configured to use RC4 and don’t have the AD attribute set explicitly, they may stop authenticating properly after this update is deployed on domain controllers. I’ve seen this kind of Kerberos change cause authentication failures in enterprise environments before, usually hitting legacy service accounts that nobody updated in years.
The Cons: What This Update Gets Wrong
It would be easy to just list everything that’s fixed and call it done. But there are real problems with how this update rolled out, and with the broader situation it represents.
The most immediate issue: at least some users on Windows 11 25H2 reported that the update is forcing machines into BitLocker recovery mode. That means after the update installs, the machine reboots, and instead of getting to the desktop, you get a recovery screen asking for the BitLocker recovery key. Neowin reported this as an added known issue after Microsoft initially said there were no known problems with KB5083769. There are workarounds available, but they require you to have your BitLocker recovery key ready, which not everyone has accessible. If you’re deploying this to end users at scale, you want to know about this before you push it.
And then there’s the overall complexity problem. 167 CVEs in one monthly update is too much. Most organizations cannot adequately test and validate that volume of changes in the time between Patch Tuesday and the realistic deployment window. The standard guidance is to test patches before rolling them out to production, but that guidance becomes increasingly impractical when “testing” would require evaluating over a hundred individual bug fixes across dozens of Windows components. The practical result is that most IT teams either push updates immediately (and risk breaking things, as the BitLocker issue illustrates) or defer for weeks (and leave known vulnerabilities unpatched, as the SharePoint zero-day exploitation illustrates). There’s no good option.
The AI-driven volume increase in vulnerability discovery is going to make this worse, not better. If bug discovery rates have tripled — as ZDI’s data suggests — then monthly patch counts of 150+ might become the new normal. The current patching model was already straining under 60–80 CVEs per month. I’m not sure what a sustainable model looks like at triple that rate.
So Should You Install It?
Yes. With caveats.
For regular home users: install it. The SharePoint zero-day doesn’t affect you directly (home users aren’t running SharePoint Server), but the TCP/IP and Defender bugs do. Windows Update should handle this automatically. Just make sure you have your BitLocker recovery key written down somewhere before the update installs, because there’s a known chance of needing it.
For IT admins: test before mass deployment. The BitLocker recovery issue and the potential Kerberos authentication breakages from the encryption type change are real risks in enterprise environments. Pilot the update on a subset of machines first. If you’re on Intune and managing domain-joined devices, check the Known Issues section for KB5083769 and the Kerberos change documentation before you roll it out to production.
For anyone running on-prem SharePoint Server 2016, 2019, or Subscription Edition: this is an emergency. CVE-2026–32201 was being actively exploited before the patch released. You’re the most urgent priority.
And regardless of what machine you’re on: check your Secure Boot certificate status. June 26 is closer than it feels.
The Update Model Is Changing Whether We Like It or Not
The shift to hotpatch as the default delivery mechanism for enterprise Windows is the longest-term change in this cycle. Microsoft’s goal is clear: get patches onto machines faster, reduce the window between vulnerability discovery and remediation, and stop relying on scheduled reboots that give attackers time to exploit known bugs.
That’s a good goal. Fewer restarts, faster security. But the implementation requires trust — trust that hotpatch updates work correctly, that they don’t break things, that the “chip-to-cloud trust chain” Microsoft describes is actually secure and hasn’t itself introduced new attack vectors. The March hotpatch that broke Reset This PC doesn’t exactly build confidence.
The broader picture is that Windows Update is moving from something you do to your machines to something that happens continuously in the background with minimal interruption. For well-managed enterprise fleets with good monitoring and rollback capabilities, this is probably better. For everyone else — and there are still a lot of Windows machines out there that are barely managed at all — the question of who’s watching for problems when things go wrong in a hotpatch deployment is not fully answered yet.