Dispatch 006: Exchange OWA has an actively exploited zero-day with no permanent patch yet, May Patch Tuesday shipped 30 critical CVEs including an unauthenticated domain controller RCE, and the Secure Boot deadline is 40 days out with a Windows Server gap most environments have not closed
CVE-2026-42897 is an actively exploited zero-day in on-premises Exchange Server's Outlook Web Access that Microsoft disclosed May 14, two days after a Patch Tuesday that shipped with zero zero-days; CISA KEV-listed it May 15 with a May 29 deadline, and a permanent patch is not yet available. May Patch Tuesday's 137 CVEs include CVE-2026-41089, an unauthenticated CVSS 9.8 RCE in Windows Netlogon targeting domain controllers, and four Word RCEs that trigger through the Outlook Preview Pane; no zero-days in the release itself, but the volume and the Netlogon flaw together warrant the same deployment urgency as any zero-day cycle. Fortinet disclosed CVE-2026-26084 in FortiAuthenticator on May 12, an unauthenticated RCE on the appliance most environments use to enforce MFA on VPN; no confirmed exploitation yet but Fortinet's track record argues for treating it as patch-today in practice. CISA's three-day KEV deadline is no longer a proposal: all four KEV additions from May 6 through May 14 carried three-day windows, confirming the policy shift is already operational. And with 40 days to the June 26 Secure Boot certificate expiration, this week surfaced two specific gaps: Windows Server does not receive the certificate updates automatically, and May's Patch Tuesday introduced a BitLocker recovery key prompt on devices with specific TPM platform validation GPOs.
Patch today
Items with immediate action required.
-
CVE-2026-42897 in Microsoft Exchange Server OWA, actively exploited zero-day, no permanent patch available, CISA deadline May 29; Exchange Emergency Mitigation Service has already deployed the interim fix automatically on most servers
Verify that the Exchange Emergency Mitigation Service is enabled and that mitigation M2.1.x shows status 'Applied' on every on-premises Exchange server. If EEMS is disabled or the server is air-gapped, run the manual mitigation script today. Two known side effects apply once the mitigation is in place.
Why it matters: Microsoft disclosed CVE-2026-42897 on May 14, two days after a Patch Tuesday release that contained no zero-days, a timing that caught most security teams mid-deployment cycle on the May updates and created confusion about whether the Exchange flaw was addressed in that release. It was not. CVE-2026-42897 is a cross-site scripting vulnerability in the Outlook Web Access component of on-premises Exchange Server that allows an unauthenticated attacker to execute arbitrary JavaScript in a victim's browser by sending a specially crafted email. The trigger requires the recipient to open the email in OWA and for certain interaction conditions to be met, which in practice means clicking on or previewing the message in OWA rather than in the Outlook desktop client. Once triggered, the JavaScript runs in the victim's browser context with access to their active OWA session, enabling session hijacking, credential theft, and the kind of persistent mailbox access that the dispatch covered in the Vercel breach context in issue 003. CISA KEV-listed CVE-2026-42897 on May 15 with a federal deadline of May 29. Microsoft confirmed active exploitation but has not disclosed the nature of the attacks or attributed them to a specific threat actor. A permanent patch is not yet available; Microsoft is working on fixes for Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM, with no confirmed release date. Exchange Server 2016 and 2019 updates will require enrollment in the Period 1 Extended Security Update program, which ended in April 2026 for Period 1 customers; those customers will not receive the permanent fix and need to evaluate their Exchange migration timeline accordingly.
What to do: Verify Exchange Emergency Mitigation Service status on every on-premises Exchange Mailbox server. Run the Exchange Health Checker script available at aka.ms/ExchangeHealthChecker and confirm that mitigation M2.1.x appears with a status of 'Applied.' If EEMS is enabled and the status shows 'Applied,' the interim mitigation is in place and no further action is required until Microsoft releases the permanent patch. A cosmetic display bug in the EEMS console may show 'Mitigation invalid for this exchange version' even when the mitigation has applied successfully; the 'Applied' status field is the authoritative indicator, not the detail text. For Exchange servers where EEMS is disabled, or servers in air-gapped or disconnected environments that cannot reach Microsoft's mitigation infrastructure, apply the mitigation manually via the Exchange On-premises Mitigation Tool: download the latest EOMT from Microsoft's GitHub repository, open an elevated Exchange Management Shell, and run Get-ExchangeServer | Where-Object {$_.ServerRole -ne 'Edge'} | .\EOMT.ps1 -CVE 'CVE-2026-42897'. Two known issues apply once the mitigation is in place: OWA Print Calendar functionality will not work (workaround: use Outlook desktop client or screenshot the calendar), and inline images may not display correctly in the OWA reading pane (workaround: send images as attachments or use Outlook desktop client). OWA Light, the URL ending in /?layout=light, also stops working, though this feature was deprecated years ago and should not be in active use. Period 1 ESU customers who did not renew should begin an Exchange Online migration assessment this month; the permanent patch for CVE-2026-42897 will not reach them through the normal update path.
-
May 2026 Patch Tuesday: 137 CVEs, no zero-days in the release, but CVE-2026-41089 is an unauthenticated CVSS 9.8 RCE on domain controllers via Windows Netlogon, and four Word RCEs fire through the Outlook Preview Pane
Deploy May Patch Tuesday to your pilot ring today and promote to production by end of week. The absence of zero-days in the release is a genuine reprieve from Q1's pace; use it to deploy cleanly rather than to slow down. The Netlogon RCE and Preview Pane Word flaws are the items to verify patched first.
Why it matters: Microsoft's May 2026 Patch Tuesday is the first release since June 2024 without an actively exploited or publicly disclosed zero-day. That milestone is worth noting, and then setting aside, because the release still contains 30 critical-rated vulnerabilities across 137 total CVEs, and two of them carry the kind of profile that warrants accelerated deployment regardless of zero-day status. CVE-2026-41089 is a CVSS 9.8 stack-based buffer overflow in Windows Netlogon that allows an unauthenticated remote attacker to achieve code execution on any Windows server running as a domain controller by sending a specially crafted network request to the Netlogon service. No credentials required, no user interaction required, low attack complexity. Microsoft rates exploitation as 'Less Likely' given the technical complexity of a reliable exploit, but Netlogon is a core authentication service present on every domain controller in every Windows-based environment, and the attack surface is therefore as large as the installed base. The second item is CVE-2026-40361 and CVE-2026-40364, two of the four Word RCEs in this cycle rated 'Exploitation More Likely.' Both trigger through the Outlook Preview Pane without the recipient opening the attachment. A user receives a malicious Word document, previews it in Outlook, and code executes on the endpoint. The other two Word RCEs (CVE-2026-40366 and CVE-2026-40367) are rated less likely to be exploited but share the same Preview Pane attack vector. CVE-2026-41103, a CVSS 9.1 elevation of privilege in the Microsoft Single Sign-On Plugin for Jira and Confluence, deserves a line for environments running Atlassian on-premises with Microsoft SSO: an unauthenticated attacker can send a forged SSO response during login and obtain a valid session without Entra ID authentication. Microsoft rates it 'Exploitation More Likely.' Note also: Microsoft's MDASH AI vulnerability discovery system identified 16 of the vulnerabilities addressed in this cycle before any external researchers found them, which is the most useful thing to know about the AI-security intersection this week.
What to do: Deploy May Patch Tuesday to your pilot ring today if you have not already. The absence of zero-days means you have a full 24 to 48 hours of pilot observation before production deployment, which is the standard window; do not let 'no zero-days' become 'no urgency.' Verify the pilot ring includes at least one domain controller, at least one system running Outlook with Word installed, and at least one machine running the Atlassian SSO plugin if applicable. For domain controllers specifically, confirm Windows Server cumulative update KB5089553 (Server 2025), KB5089512 (Server 2022), KB5089562 (Server 2019), or KB5089558 (Server 2016) is applied and that the Netlogon service has restarted, which happens automatically on reboot following the cumulative update. For Microsoft 365 Apps, confirm the Monthly Enterprise Channel is on Version 2504 or later and that Semi-Annual Channel (Targeted) is on Version 2502 or later; both include the Word RCE patches. One known issue to watch: the May update introduced a BitLocker recovery key prompt on devices where BitLocker is enabled, TPM platform validation is configured to include PCR7 via Group Policy, and the Secure Boot certificate update is in progress. If you hit this in your pilot ring, Microsoft recommends temporarily setting the 'Configure TPM platform validation profile for native UEFI firmware configurations' policy to 'Not Configured' before deploying the update fleet-wide. This is also an early indicator that your Secure Boot remediation is proceeding correctly, which connects to the monthly-review item below.
This week
Worth investigating this week but not today.
-
CVE-2026-26084 in Fortinet FortiAuthenticator, unauthenticated RCE via the API endpoint, no confirmed exploitation yet but FortiAuthenticator is the appliance most environments use to enforce VPN MFA
Patch FortiAuthenticator to 7.0.4, 7.2.5, or 7.4.2 this week. If patching cannot happen immediately, disable API access on exposed interfaces via Network > Interfaces > Access Rights. FortiAuthenticator Cloud is not affected.
Why it matters: Fortinet disclosed CVE-2026-26084 (FG-IR-26-128) on May 12, an improper access control vulnerability in the FortiAuthenticator API that allows an unauthenticated attacker to execute unauthorized code or commands via crafted HTTP requests to the API endpoint. FortiAuthenticator Cloud is not affected; the vulnerability applies to on-premises FortiAuthenticator deployments only. No exploitation has been confirmed as of this writing, which is the reason this item sits in this-week rather than patch-today. The reason it warrants this-week urgency rather than a relaxed monthly treatment is what FortiAuthenticator does in the environments that run it: it serves as the RADIUS and LDAP authentication broker for FortiGate VPN, providing the MFA enforcement layer between users and the network perimeter. An unauthenticated RCE on the appliance that enforces MFA is effectively an unauthenticated path around MFA for every device that trusts that appliance for authentication decisions. CISA has added 24 Fortinet vulnerabilities to its Known Exploited Vulnerabilities catalog over the past several years, 13 of which were subsequently confirmed as ransomware campaign vectors. The gap between disclosure and exploitation for Fortinet products has historically been days to weeks rather than months. The dispatch has covered Fortinet zero-days in issues 001, 002, and 004; the pattern is consistent enough that the absence of confirmed exploitation at the time of disclosure is not a reason to wait for the KEV listing before acting.
What to do: Identify every on-premises FortiAuthenticator deployment in your environment. The affected versions are FortiAuthenticator 7.0.0 through 7.0.3, 7.2.0 through 7.2.4, and 7.4.0 through 7.4.1. The fixed versions are 7.0.4, 7.2.5, and 7.4.2. Apply the update through the FortiAuthenticator administration console under System > Maintenance > Backup and Upgrade. If the upgrade cannot be completed this week, apply the vendor-stated interim mitigation immediately: navigate to Network > Interfaces, select each interface that has API access enabled, and uncheck the API access option under Access Rights. This disables the vulnerable code path without affecting the primary authentication workflows that FortiAuthenticator handles for VPN and RADIUS clients. After patching, review the FortiAuthenticator log under Log & Report > Logs > Authentication Events for any requests to API endpoints from source IPs outside your expected administrative management ranges since May 12; the disclosure date is the earliest public knowledge of the vulnerability, but the flaw was present in prior versions. Confirm that the FortiAuthenticator administrative web interface is not reachable from the internet or from untrusted network zones; if it is, restricting that access is the higher-priority action even before the patch.
-
CISA's three-day KEV deadline is now operational, not a proposal: all four catalog additions from May 6 through May 14 carried three-day windows; the average in 2025 was 19.7 days
The three-day window is the current behavior for new KEV additions, not a future policy under discussion. If your vulnerability management SLA is built around a two-to-three-week remediation window, the SLA is already out of step with current federal practice and the exploitation timelines driving it.
Why it matters: The dispatch covered in issue 005 that Reuters reported CISA and the Office of the National Cyber Director were discussing shortening KEV remediation deadlines to three days. That discussion is now practice. All four KEV additions from May 6 through May 14 carried three-day federal remediation deadlines: CVE-2026-6973 (Ivanti EPMM, May 7, deadline May 10), CVE-2026-42208 (LiteLLM, May 8, deadline May 11), CVE-2026-0300 (Palo Alto PAN-OS, May 9, already covered in issue 005), and CVE-2026-42897 (Exchange OWA, May 15, deadline May 29, the first of the new additions to carry a deadline longer than three days). Federal News Network reported May 15 that the average KEV deadline across all of 2024 was more than 20 days; in 2025 it dropped to 19.7 days; so far in 2026 it is 14.4 days, with an accelerating trend. The BOD 22-01 binding deadline applies formally only to federal civilian executive branch agencies. The reason it matters for the SMB and MSP audience is not compliance: it is exploitation tempo. The three-day window reflects CISA's assessment of how quickly working exploits are appearing against newly disclosed vulnerabilities in the current environment, an assessment driven in part by the demonstrated capability of AI-assisted tooling to accelerate exploit development. A three-day window between a KEV listing and meaningful exploitation at scale against unpatched environments is consistent with the timelines documented across the items in recent issues of this dispatch: the cPanel zero-day window was 93 days of exploitation before disclosure, the Bitwarden CLI supply chain window was 93 minutes, and the PAN-OS flaw was exploited before the advisory was public.
What to do: This week, compare your current vulnerability management response SLA against a three-day deployment target for the specific class of vulnerabilities that appear in the dispatch: actively exploited flaws in internet-facing systems, perimeter devices, management platforms, and email infrastructure. Not every CVE warrants a three-day response. The KEV catalog and the dispatch's patch-today tier are the filters for what does. For those items, the operational question is whether your current process can actually execute in three days, not whether it is expected to. The gap is almost always in one of three places: the asset inventory does not surface affected systems quickly enough, the deployment path for the affected product requires testing time that has not been pre-invested, or the change control process adds days to a decision that should already be made by policy for KEV-tier items. Identify which gap applies to your environment by working backwards from the last three patch-today items you deployed: how long did each one actually take from the time you became aware to the time production was patched? If the honest answer is more than a week on average, the process is the problem and this week is a reasonable time to begin addressing it.
Monthly or quarterly review
Add to longer-term planning cycles.
-
June 26 Secure Boot certificate deadline is 40 days out; Windows Server requires manual deployment and a known BitLocker issue in May's update is an early warning signal worth understanding before you hit it in production
Run the UEFICA2023Status registry check and the Exchange Health Checker equivalent for Secure Boot on your server fleet this week. Windows Server does not receive the certificate updates automatically. The BitLocker recovery key prompt appearing after May's update on some endpoints is an indicator that the process is working, not that something went wrong, provided you handle it correctly.
Why it matters: The dispatch first flagged the June 26 Secure Boot certificate deadline in issue 001 as a monthly-review item, and it has appeared in subsequent issues as part of the Patch Tuesday context. Two specific developments this week make it worth a standalone item at the 40-day mark. First, the Windows Server gap: unlike Windows 11 and Windows 10 with Extended Security Updates, Windows Server does not receive the 2023 Secure Boot certificate updates automatically through Windows Update. Administrators must manually deploy the 2023 replacement certificates to all applicable servers and Generation 2 Hyper-V virtual machines before June 26. Systems that remain on the 2011 certificates after expiration will continue to boot normally, but they will enter a degraded security posture in which they cannot receive future Secure Boot-related updates, including the DBX revocation database updates that protect against newly discovered bootkit threats. The 2011 UEFI CA specifically expires June 26; the Windows Production PCA 2011 follows in October 2026, giving a second deadline that organizations holding off on the server work should not use as justification to defer. Second, the BitLocker issue: May's cumulative update is pushing the Secure Boot certificate rollout to Windows 10 ESU devices. On devices where BitLocker is enabled, the TPM platform validation Group Policy is configured to explicitly include PCR7, and the Windows UEFI CA 2023 certificate is present in the Secure Boot signature database but PCR7 binding is reported as 'Not Possible' by System Information, the update may prompt for the BitLocker recovery key on first restart. This is not a bug in the certificate update; it is the expected behavior when PCR7 measurements change as a result of the certificate update. The risk is organizational: if the recovery key is not accessible at the time of the prompt, the endpoint is locked. If this happens across a fleet deployment without advance preparation, the help desk call volume is memorable.
What to do: This month, complete three specific tasks before June 26. First, verify certificate status on every device in your Windows fleet using the UEFICA2023Status registry key at HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State; the value should read 'Updated.' Windows System Event Log Event ID 1808 confirms the new certificates are applied; Event ID 1801 means they have not been applied and requires investigation. For Windows 11 and Windows 10 ESU devices, the May cumulative update is delivering the certificate rollout in a phased manner; devices that have not yet received it should be monitored through your RMM for Event ID 1801 and prioritized for manual deployment if they do not update automatically before the June 26 deadline. Second, for Windows Server, manually deploy the 2023 Secure Boot certificates using the guidance in the Microsoft Windows Server Secure Boot playbook at aka.ms/GetSecureBoot. Generation 2 Hyper-V VMs require the same manual update as physical servers; Generation 1 VMs do not support Secure Boot and are not affected. VMware environments require a firmware file update on the hypervisor side rather than the guest OS. Complete this on a pilot server first, verify boot behavior, and then schedule the production fleet during your next maintenance window before June. Third, for the BitLocker issue: before deploying May's update fleet-wide, temporarily set the 'Configure TPM platform validation profile for native UEFI firmware configurations' Group Policy to 'Not Configured' on any device where BitLocker is enabled and PCR7 is explicitly included in the validation profile. This prevents the recovery key prompt while still allowing the Secure Boot certificate update to apply. Confirm BitLocker recovery keys are in Entra ID or Active Directory and accessible before any restart on a BitLocker-protected device that is receiving the Secure Boot update.