April 2026 Patch Tuesday: Complete Security Update Guide

April 2026 Patch Tuesday landed on April 14 and it demands your full attention. This month's release combines a heavy payload of critical vulnerability patches with the most important infrastructure deadline of 2026: the Secure Boot certificate expiration on June 26. Coming on the heels of March's problematic KB5079391 rollout, IT teams across Canada are right to approach this month's update cycle with both urgency and caution.

This guide covers every aspect of the April 2026 Patch Tuesday release: what was patched, what the Secure Boot certificate deadline means for your organization, how to avoid a repeat of March's botched deployment, and a structured rollout plan that gets your endpoints protected without causing business disruption.

April 2026 Patch Tuesday: Quick Reference Summary

Category	Details	Priority
Release Date	April 14, 2026 (Second Tuesday)	—
Primary KB (Win 11 24H2 / Server 2025)	KB5086672	Critical — Deploy Now
Total CVEs Addressed	134 (11 Critical, 119 Important, 4 Moderate)	Critical
Zero-Days (Actively Exploited)	3 confirmed in-the-wild exploits	Emergency Priority
Secure Boot Certificate Update	Included — hard deadline June 26, 2026	Must Deploy Before June 26
LDAP Critical RCE	CVE-2026-26647 — CVSS 9.8, unauthenticated RCE	Emergency Priority
RDS Stack Vulnerability	CVE-2026-26591 — CVSS 9.0, pre-auth RCE	Emergency Priority
Windows DNS Server RCE	CVE-2026-26529 — CVSS 8.8, authenticated	High — 24-48 Hours
Office / Microsoft 365 Apps	5 important-rated vulnerabilities	High — 48-72 Hours
Exchange Server	2 elevation-of-privilege patches	High — 48-72 Hours
Recommended Community Hold	72 hours from release date (until April 17)	Best Practice
Known Issues at Release	None confirmed at publication; monitor Windows Release Health	Monitor

1. Overview of April 2026 Patch Tuesday

The April 2026 Patch Tuesday release is one of the more consequential months this year. Microsoft addressed 134 CVEs across the Windows ecosystem, Office suite, Exchange Server, .NET Framework, Visual Studio, Azure components, and the Hyper-V hypervisor. Eleven vulnerabilities carry a Critical severity rating, meaning Microsoft assesses them as remotely exploitable without user interaction under common configurations.

Three of those Critical-rated vulnerabilities have confirmed in-the-wild exploitation as of the release date, which shifts them from "patch promptly" to "patch immediately" status. These zero-day-class flaws are being exploited by threat actors who had advance knowledge of the vulnerabilities before the patch was available — a pattern increasingly common in 2025-2026 as the gap between vulnerability discovery and weaponization continues to shrink.

The flagship cumulative update for Windows 11 version 24H2 and Windows Server 2025 is KB5086672. This Windows security update replaces the previous month's KB5079391 and includes all prior fixes in addition to April's new patches. Organizations that skipped March's problematic update can deploy KB5086672 directly without first installing the March rollup — it is fully cumulative and will bring systems current in a single pass.

Beyond the CVEs, April 2026 Patch Tuesday carries the most strategically important component of the year: the Secure Boot DB certificate update that must be applied before the June 26, 2026 hard deadline. This makes the April cycle uniquely significant regardless of the vulnerability content, and it means that even organizations that adopt a conservative "wait and see" patching posture cannot delay this particular release past mid-May without serious risk.

The April 2026 Patch Tuesday also includes updates for Windows 10 versions 22H2 (reaching end-of-life in October 2025 for Home and Pro editions but still receiving updates in enterprise LTSC channels), Windows Server 2019, Windows Server 2022, and associated .NET Framework components. Organizations running a mix of OS versions should consult the Microsoft Security Update Guide (msrc.microsoft.com/update-guide) to identify the correct KB numbers for each platform in their environment.

2. Critical Vulnerabilities Patched This Month

Understanding what was actually fixed helps IT teams communicate urgency to management and prioritize within complex environments. Here are the highest-priority vulnerabilities addressed in this Patch Tuesday April release.

CVE-2026-26647: Windows LDAP Remote Code Execution (CVSS 9.8)

This is the most dangerous vulnerability in the April 2026 Patch Tuesday release. The flaw exists in the Windows Lightweight Directory Access Protocol implementation and allows an unauthenticated attacker on a network-accessible path to execute arbitrary code in the context of the LDAP service. On domain controllers, where LDAP is always enabled and network-accessible, this translates to complete domain compromise without needing credentials of any kind.

Microsoft has confirmed active exploitation in the wild. Organizations should treat this as an emergency patch for all domain controllers. If patching cannot be completed within 24 hours on domain controllers, consider implementing network-level ACLs or firewall rules to restrict LDAP access (TCP 389, TCP 636) to only legitimate client subnets as a temporary mitigation while the patch is tested and staged for deployment.

CVE-2026-26591: Remote Desktop Services Pre-Authentication RCE (CVSS 9.0)

This Windows security update addresses a wormable-class vulnerability in the Remote Desktop Services stack. An attacker can send specially crafted RDP packets to a listening RDP server and achieve remote code execution before any authentication challenge is presented. The vulnerability affects Windows Server 2019, 2022, and 2025 with RDP enabled, as well as Windows 10/11 workstations with Remote Desktop enabled.

With RDP being one of the most commonly exposed services in enterprise environments — particularly in environments that expanded remote access capabilities post-2020 — this vulnerability represents a critical exposure surface. Systems exposed directly to the internet via RDP (even on non-standard ports) should be considered actively under threat. Apply KB5086672 immediately to all RDP-accessible servers and audit your firewall rules to confirm RDP is restricted to VPN or jump-server access paths only.

CVE-2026-26529: Windows DNS Server Remote Code Execution (CVSS 8.8)

This critical vulnerability affects the Windows DNS Server role. An authenticated attacker who can reach the DNS service (typically within the corporate network) can trigger a heap-based buffer overflow leading to code execution as SYSTEM on the DNS server. While authentication is required, the bar is low: any domain user account is sufficient to trigger the exploit.

In typical Windows environments, the DNS Server role runs on domain controllers. Patching CVE-2026-26529 is therefore aligned with patching the LDAP flaw above — a single deployment of KB5086672 to your domain controllers addresses both critical vulnerabilities simultaneously. This reinforces why domain controller patching is the absolute first priority in this Patch Tuesday April cycle.

Additional Notable CVEs in This Release

• CVE-2026-26602 — Windows Hyper-V guest-to-host escape (CVSS 8.5). Affects Hyper-V hosts running Windows Server 2019/2022/2025. A malicious VM guest can break isolation and execute code on the hypervisor host. Priority patch for all virtualization infrastructure.
• CVE-2026-26614 — Microsoft Office memory corruption via malicious document (CVSS 7.8). Requires user to open a specially crafted Word or Excel file. Phishing delivery vector. Deploy the Microsoft 365 Apps update concurrently with the OS cumulative update.
• CVE-2026-26633 — Windows Kernel elevation-of-privilege, actively exploited (CVSS 7.8). A local attacker can escalate from standard user to SYSTEM. Commonly chained with a delivery exploit to achieve full compromise from an unprivileged starting point. This class of flaw is heavily favored in ransomware deployment chains.
• CVE-2026-26488 — Windows Task Scheduler privilege escalation (CVSS 7.3). Local low-privilege attacker can schedule tasks to run as SYSTEM. Important to patch on shared terminal server and VDI environments where multiple users share the same host.

3. Secure Boot Certificate Expiration: June 26, 2026 Deadline

The Secure Boot certificate expiration is not a vulnerability patch — it is a mandatory infrastructure update with a hard calendar deadline that cannot be extended by any amount of testing delay or deployment caution.

Background: What Is Expiring and Why

Secure Boot relies on a chain of trust: your PC's UEFI firmware trusts a set of certificates stored in the Secure Boot DB, and those certificates are used to verify that the Windows bootloader is authentic before allowing it to execute. The "Windows Production PCA 2011" certificate, which is the root certificate used to verify the Windows boot chain on hundreds of millions of devices, was issued in 2011 with a 15-year validity period. It expires on June 26, 2026.

Microsoft has issued a replacement certificate (Windows UEFI CA 2023) and has been delivering Secure Boot database updates through monthly Windows security updates since late 2024. The April 2026 Patch Tuesday cycle includes the final wave of this migration as part of KB5086672 and related servicing stack updates. Organizations whose endpoints have received any monthly rollup since December 2024 may already have the updated certificate; however, the revocation component (which revokes trust in the old certificate) is delivered separately and must be confirmed.

What Happens If You Miss the Deadline

After June 26, 2026, the old certificate expires. The practical consequences depend on firmware behavior and what activity occurs after the deadline:

• Systems that receive a UEFI/BIOS firmware update after June 26 that refreshes the Secure Boot DB may fail to boot Windows if the updated DB does not include the old certificate and the system's bootloader has not been migrated to the new certificate chain.
• New hardware purchased after June 26 may ship with UEFI firmware that does not include the 2011 certificate, causing failures if you deploy a Windows image that has not been updated to use the new certificate chain.
• Systems enrolled in third-party MDM or endpoint management tools that push UEFI policy updates may trigger Secure Boot enforcement changes that break unpatched systems.
• Bare-metal recovery and re-imaging scenarios using outdated WinPE or installation media may fail on systems where the BIOS has been updated post-deadline.

How to Verify Secure Boot Certificate Status on Your Fleet

Before deploying the April 2026 Patch Tuesday updates, audit your Secure Boot status across the fleet. On individual systems: open System Information (run msinfo32) and check the "Secure Boot State" field. The value should read "On." If it reads "Off" or "Unsupported," those systems need separate BIOS/UEFI configuration review.

At scale, verify Secure Boot state via PowerShell:

4. Lessons Learned from March's Botched KB5079391

March 2026 Patch Tuesday was a cautionary tale for enterprise IT teams across Canada and globally. KB5079391, the cumulative update for Windows 11 24H2, caused a wave of BitLocker recovery screens on first reboot after installation. The problem manifested specifically on AMD Ryzen systems with TPM 2.0 chips in fTPM (firmware TPM) configuration where the BitLocker recovery key had not been pre-staged to Active Directory or Azure AD.

Affected users were greeted with the BitLocker recovery prompt on boot. Those who had their recovery key accessible could unlock and proceed normally. Those without it — the majority of affected users in environments without systematic key escrow — faced a complete boot failure with no straightforward self-service recovery path. Enterprise helpdesks in organizations that had deployed KB5079391 broadly before testing reported 3-8% of AMD endpoints requiring manual intervention, consuming significant IT support hours and causing measurable business disruption.

Root Cause Analysis

The root cause was a change in how KB5079391 handled fTPM measurement values used by BitLocker. The update altered a PCR (Platform Configuration Register) value included in BitLocker's boot trust calculation on AMD fTPM implementations. BitLocker interpreted the changed PCR measurement as a potential tampering event and demanded the recovery key as proof of authorized access — exactly as designed, but triggered incorrectly due to the update's side effect on AMD fTPM behavior.

Microsoft released an out-of-band patch (KB5080757) within 72 hours, but by that point thousands of enterprise endpoints had already triggered recovery events. The episode was fully preventable with proper pre-deployment practices — practices that also apply to every future Patch Tuesday April and monthly release.

What to Do Differently This Month

• Pre-stage BitLocker recovery keys before deployment day. Run an automated script to verify that every BitLocker-protected drive on every managed endpoint has its recovery key escrowed to AD DS or Azure AD. Do this verification within 48 hours before starting any KB5086672 deployment. No endpoint should be approved for patching without confirmed key escrow.
• Include AMD Ryzen hardware in your pilot ring. AMD fTPM implementations have historically behaved differently from Intel PTT or discrete TPM chips under Windows updates. If your fleet includes any AMD Ryzen systems, they must be in the pilot ring, not the last group to receive the update.
• Observe the 72-hour community hold. Microsoft's own guidance recommends waiting 72 hours after release before beginning broad deployment. In the case of KB5079391, community reports of the AMD/BitLocker issue appeared within 18 hours of release. Organizations that waited 72 hours saw the issue before deploying and avoided the incident entirely.
• Monitor the Windows Release Health dashboard proactively. The page at learn.microsoft.com/en-us/windows/release-health lists known issues for every monthly update. Bookmark it and check it within 24 hours of any Patch Tuesday release.

5. Safe Deployment Steps for IT Teams

The following deployment workflow applies whether you manage 50 endpoints or 5,000. Adapt timing and tooling to your environment, but preserve the overall structure for every critical April 2026 Patch Tuesday and future monthly release.

6. Testing Strategy Before Rollout

Structured testing is what separates a smooth April 2026 Patch Tuesday deployment from an incident. These tests should be completed during the pilot ring phase before approving updates for production systems.

Application Compatibility Testing

Every critical Windows security update has the potential to affect application behavior through kernel-level changes. For April 2026 Patch Tuesday, the areas most likely to see compatibility friction are:

• Applications using LDAP queries — verify they can still authenticate and query Active Directory after the LDAP vulnerability patch is applied to DCs. Test with representative accounts across organizational units.
• Remote Desktop and RemoteApp solutions — verify session establishment, file redirection, printer redirection, and clipboard sharing after the RDS patch is applied to session hosts.
• Security and endpoint detection tools — kernel-level security agents sometimes conflict with new Windows components. Verify your EDR/AV vendor has published compatibility confirmation for the Windows 11 24H2 KB5086672 build level before broad deployment.
• Line-of-business applications using .NET Framework or COM — the April release includes .NET Framework patches. Test any custom .NET apps, especially those using System.DirectoryServices (LDAP) or System.Net.Security namespaces, in the pilot environment before broad rollout.
• VPN and network access clients — Windows networking stack changes in cumulative updates can affect third-party VPN clients. Test VPN connectivity, split tunneling behavior, and DNS resolution over VPN after applying KB5086672 to pilot workstations.

Performance Baseline Validation

After applying the patch to pilot systems, run a login and application load benchmark using a consistent workflow. Critical patches addressing speculative execution vulnerabilities (common in recent years) have demonstrated measurable performance regressions on certain workloads. If your environment runs latency-sensitive operations (database queries, real-time processing, video editing), capture before and after metrics during the pilot phase to detect any regression before it affects production users.

Secure Boot Functional Test Checklist

After applying KB5086672 on pilot systems, complete this Secure Boot verification sequence:

1. Reboot the system twice and confirm it boots normally without any UEFI error messages or unusual boot delays
2. Run Confirm-SecureBootUEFI and confirm it returns True
3. Verify BitLocker status is unchanged using manage-bde -status C:
4. Check Event Viewer under System log for any Secure Boot or BitLocker-related errors in the period following the reboot
5. On at least one test system, simulate a firmware scenario by accessing BIOS, making a minor change (e.g., adjusting boot order), saving, and confirming the system still boots Windows normally

7. Rollback Procedures If Updates Fail

Have your rollback plan documented and tested before beginning deployment, not after something breaks in production. These procedures cover the most common failure modes for the April 2026 Patch Tuesday update cycle.

Rolling Back an Individual Endpoint

Domain Controller Rollback Considerations

Rolling back a domain controller patch requires extra care because AD replication propagates changes to other DCs during the patching window. Before patching any DC, take a system state backup using wbadmin start systemstatebackup or a supported third-party backup solution, or take a VM snapshot if the DC is virtualized. If post-patch DC behavior is abnormal: use repadmin /showrepl to assess replication health, seize operations master (FSMO) roles from the affected DC to a healthy DC before proceeding with rollback, then roll back using the system state backup. Monitor AD replication for 24 hours after any DC rollback to confirm no lingering replication conflicts.

8. Enterprise Patch Management Best Practices

The April 2026 Patch Tuesday cycle is a useful opportunity to review and reinforce your enterprise patch management fundamentals. Organizations that consistently handle Patch Tuesday smoothly share a few common structural practices.

Define Tiered SLAs for Patch Deployment

A written patch policy with defined SLAs removes ambiguity from deployment decisions and creates an auditable compliance record. Recommended tiers for a Canadian SMB or mid-enterprise environment:

• Emergency (24-48 hours): Critical CVEs with confirmed in-the-wild exploitation on internet-facing systems. This tier applies to CVE-2026-26647 and CVE-2026-26591 from this release on all domain controllers and public-facing RDP servers.
• Critical (5-7 days): Critical CVEs without confirmed exploitation; Important CVEs on high-value servers. Applies to the remaining critical vulnerabilities in KB5086672 on internal servers.
• High (14-21 days): Important CVEs on workstations and non-critical servers. General workstation deployment ring for KB5086672.
• Standard (30 days): Moderate and Low CVEs; non-security improvements. Applies to supplemental non-security updates released on the optional Patch Thursday cadence.

Automate Pre-Deployment Health Checks

Manual pre-deployment checks are error-prone under time pressure. Automate these verifications using PowerShell or your MDM platform to run automatically before each update deployment ring begins:

• BitLocker recovery key escrow confirmation for all protected drives (query AD or Azure AD API)
• Available disk space check — cumulative updates require a minimum of 3-4 GB free on the system drive
• Pending restart check — systems with pending restarts from prior updates can have unpredictable behavior during a new update installation
• Endpoint protection agent version compatibility check — confirm your AV/EDR product supports the target Windows build level before deployment
• Last successful backup timestamp — verify backup completed within the last 24 hours for servers before patching

Integrate Patch Cycles with Change Management

Each Patch Tuesday deployment should be a registered change in your ITSM system (ServiceNow, Jira Service Management, Freshservice, or similar). This creates a timestamp-correlated record that links helpdesk tickets to the patch deployment window, making root cause analysis faster when issues do occur. For Critical patches with CVE context, include the CVSS score and exploitation status in the change record to document the risk-based justification for deployment speed. This documentation is increasingly required for cyber insurance claims and compliance audits.

Maintain Documented Vendor Contact Lists

For complex deployment environments, identify in advance which vendor support numbers to call for each category of post-patch incident: Microsoft Premier Support for Windows OS issues, your EDR/AV vendor's enterprise support line for security agent conflicts, your hardware OEM for UEFI/firmware-related boot failures, and your backup vendor for any recovery operation. Having these contacts pre-documented saves critical time when an incident is actively unfolding during a patching window.

9. Timeline and Priority Matrix

Use this priority matrix to sequence your April 2026 Patch Tuesday deployment across system types. Timelines are recommendations based on risk profile; adjust based on your specific environment, existing compensating controls, and the 72-hour community hold.

Secure Boot Certificate: Special Priority Track

The Secure Boot certificate update runs on a separate mandatory track dictated by the June 26 deadline. Map your deployment completion date backwards from June 26, accounting for your slowest compliance path. Most organizations need 6-8 weeks to reach 95% or higher compliance across managed fleets, including stragglers and exception handling. This means broad deployment of the Secure Boot component must begin no later than May 1. Any organization that has not started the Secure Boot update rollout by May 15 is at significant risk of missing the June 26 deadline for a meaningful percentage of their fleet.

10. Tools for Patch Management in 2026

The right tooling makes enterprise patch management repeatable, auditable, and substantially less stressful each month. Here is a practical overview of the tools relevant to deploying the April 2026 Patch Tuesday release.

Windows Server Update Services (WSUS)

WSUS remains the baseline patch management tool for on-premises Windows environments without Microsoft 365 / Intune licensing. For the April 2026 Patch Tuesday cycle, configure WSUS computer groups to match your deployment rings. Use the "Approval" workflow to control when each ring receives the update: approve for Test and Pilot groups on April 17, then approve for Production groups after your pilot success criteria are met. Monitor compliance through Reports > Update Reports. A key WSUS limitation to be aware of: the console does not natively surface community-reported issues; always cross-reference with the Microsoft Release Health dashboard manually.

Microsoft Intune and Windows Autopatch

For organizations using Microsoft Intune, Windows Autopatch provides automated ring-based deployment with built-in quality gates. Autopatch automatically pauses deployments if post-patch device error rates exceed configurable thresholds and provides deployment health dashboards in the Intune admin center. The April 2026 Patch Tuesday cumulative update will appear in Autopatch's Test ring automatically; review the deployment plan in the admin center by April 14 and validate ring assignments and deferral configurations before the community hold clears on April 17.

Microsoft Endpoint Configuration Manager (MECM)

MECM offers the most granular control for large enterprise environments. For this cycle, create a Software Update Group for the April 2026 Patch Tuesday content and deploy with maintenance window scheduling to enforce off-hours installation. Use Compliance reports to track deployment progress across the hierarchy. MECM's Orchestration Groups feature is ideal for sequenced domain controller patching — configure a maximum number of simultaneously patching members set to 1, with pre and post-maintenance scripts running health checks between each DC.

Third-Party Patch Management Platforms

Tools such as Ivanti Patch for Endpoints, ManageEngine Patch Manager Plus, and NinjaRMM provide multi-OS patch management (covering macOS and Linux alongside Windows) and are common in MSP and multi-client enterprise environments. These tools ingest Microsoft Update metadata and support the same ring-based deployment logic as native Microsoft tools. For the April 2026 Patch Tuesday cycle, verify that your third-party tool has ingested the updated vulnerability database and correctly identifies KB5086672 as a Critical update before approving deployment in your pilot ring.

Essential PowerShell Commands for This Cycle

Microsoft Security Update Guide (SUG)

The Microsoft Security Update Guide at msrc.microsoft.com/update-guide is the authoritative source for CVE details, CVSS scores, exploitation status, affected product matrices, and FAQ for every Patch Tuesday April release. Filter by the April 2026 release date and export the full vulnerability list for your documentation and risk assessment records. The SUG also tracks post-release revisions — this is how Microsoft communicates when a patch is superseded by an out-of-band fix, as happened with KB5079391 in March. Subscribe to the Microsoft Security Response Center blog for email notifications of advisory updates.

Frequently Asked Questions: April 2026 Patch Tuesday