Get-ExchangeServer.Microsoft’s Security Update Guide published the CVE on August 11, while the company’s corresponding Exchange support articles place it in the same seven-CVE security bundle for all currently serviced on-premises Exchange tracks. Microsoft identifies CVE-2026-65813 as an elevation-of-privilege issue, but its public advisory does not presently disclose a CVSS score, attack vector, prerequisite permissions, vulnerable component, exploitation status, or a workaround short of installing the update.
That absence is material. “Elevation of privilege” says what an attacker can gain after successful exploitation; it does not establish whether the attacker begins locally, through authenticated Exchange access, from a compromised endpoint, or through another vulnerability in a chain. Administrators should treat the patch as urgent maintenance for Exchange servers, but should not turn the thin advisory into an unsupported claim of unauthenticated remote compromise.
The August 11 packages that contain the fix
Microsoft’s Exchange support documentation confirms that CVE-2026-65813 is included in four separate August 2026 packages:
- Exchange Server Subscription Edition RTM SU9, KB5121573, updates the product to build 15.2.2562.46.
- Exchange Server 2019 CU15 SU10, KB5121574, updates the product to build 15.2.1748.49.
- Exchange Server 2019 CU14 SU13, KB5121575, updates the product to build 15.2.1544.44.
- Exchange Server 2016 CU23 SU24, KB5121576, updates the product to build 15.1.2507.72.
The dual Exchange 2019 packages matter. A shop on CU14 cannot install the CU15 security update as a shortcut, and a CU15 deployment should not be given the CU14 package. Exchange security updates are CU-specific: the executable has to match the cumulative-update branch installed on each server.
Microsoft’s build-number record also confirms that the August 11 release moved each supported branch by a single security-update build from the July 14 packages. Subscription Edition moved from 15.2.2562.45 to 15.2.2562.46; Exchange 2019 CU15 from 15.2.1748.48 to 15.2.1748.49; CU14 from 15.2.1544.43 to 15.2.1544.44; and Exchange 2016 CU23 from 15.1.2507.71 to 15.1.2507.72.
This is a cumulative Exchange security release. An administrator who skipped the July 2026 security update does not need to install July first; the appropriate August package supersedes its July predecessor on the same CU branch. That reduces deployment steps, but it does not solve an environment that has fallen behind on its cumulative update level or is outside Microsoft’s servicing terms.
Exchange 2016 and 2019 support is now a licensing issue
CVE-2026-65813 lands at an awkward moment for organizations still running Exchange 2016 or Exchange 2019. Microsoft’s August support pages state plainly that both products have reached end of support. Their August fixes are available only to organizations enrolled in the Period 2 Extended Security Update program, which Microsoft says runs through the end of October 2026.
That creates a practical split in the affected population. Exchange Server Subscription Edition customers can deploy the August update through the normal supported channel. Exchange 2016 and 2019 customers with ESU entitlement have a supported patch route for this CVE, but only for the currently listed CU branches. Customers without ESU access cannot treat a newly disclosed vulnerability as a reason to remain indefinitely on a retired release; Microsoft directs them to migrate to Exchange Server Subscription Edition to continue receiving current security updates.
The important consequence is that the August release is both a security event and an inventory test. If the team responsible for Exchange cannot immediately answer whether every 2016 and 2019 server is covered by ESU, it has an exposure-management problem before it has an installation problem. An unsupported Exchange server left on the internet is not made safe by having a later Windows Server patch level, a perimeter firewall, or a partially updated management workstation.
Microsoft’s own update guidance recommends applying Exchange security updates to every Exchange server and to systems running Exchange Management Tools only. The latter is easy to miss in organizations that retain an administrative workstation or management VM after decommissioning a mailbox server. Matching the management tools to the server’s patch state avoids incompatibilities, and it prevents a forgotten administrative host from becoming the outlier that breaks a recovery or management procedure.
What Microsoft has not said about CVE-2026-65813
The public record establishes that CVE-2026-65813 exists and that Microsoft has shipped a fix. It does not yet provide enough detail to rank this particular flaw against the other six vulnerabilities addressed in the same package, nor enough to produce useful detection logic tied specifically to this CVE.
Microsoft has not publicly identified:
- The Exchange service, endpoint, library, or feature containing the flaw.
- Whether exploitation requires an authenticated mailbox user, a low-privileged domain account, local code execution, or another foothold.
- Whether the issue affects internet-facing Client Access services directly.
- Whether Microsoft has observed exploitation in the wild.
- Whether proof-of-concept code, detailed exploit research, or indicators of compromise exist.
- Whether an Exchange Emergency Mitigation Service rule has been issued for this CVE.
The last item deserves attention. Microsoft describes the Exchange Emergency Mitigation service as a way to push temporary signed mitigations to eligible Mailbox-role servers when a threat needs rapid containment, including URL Rewrite rules or disabling vulnerable Exchange components. Microsoft’s published mitigation inventory lists the earlier CVE-2026-42897, but does not list CVE-2026-65813 as of August 12. That does not prove the new vulnerability is low risk; it means administrators should not assume that an enabled mitigation service has protected an unpatched server.
A vendor withholding root-cause information immediately after release is not unusual, particularly for a server product with a long history of being targeted after patch details become public. But it shifts the defensible response away from debating a severity score and toward patching the disclosed affected versions, then checking whether the deployment actually completed.
No independent technical analysis or public exploit reporting for CVE-2026-65813 was available in searches conducted on August 12. Until that changes, claims that this is either “only local” or an internet-scale Exchange compromise path should be treated as speculation.
Verify the security update, not merely the CU
Exchange’s version reporting can create a false sense of completion. Get-ExchangeServer reports the installed cumulative-update version but does not show the installed security update level. A server can therefore look current enough in a quick inventory while missing the August package containing CVE-2026-65813.
Microsoft’s build documentation recommends inspecting ExSetup.exe or using the Exchange Health Checker. On an Exchange server, an administrator can use the Exchange Management Shell to inspect the installed file version:
Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}
The ProductVersion or FileVersion should match the branch-specific August build. For the four packages containing CVE-2026-65813, the expected targets are 15.02.2562.046 for Subscription Edition, 15.02.1748.049 for Exchange 2019 CU15, 15.02.1544.044 for Exchange 2019 CU14, and 15.01.2507.072 for Exchange 2016 CU23.
That check should be performed on every server individually. In a DAG, the patching sequence still needs to respect the organization’s maintenance procedures, database activation state, monitoring dependencies, backup integrations, and any installed transport or antivirus agents. The security update may be cumulative, but Exchange server maintenance is not a matter of copying one successful result across the whole fleet.
Microsoft also directs administrators to run the Exchange Server Health Checker after installation. That is more than paperwork: Exchange updates can require follow-up actions, and the tool helps surface missing security updates, configuration concerns, and whether the installed build is where it should be.
The release still carries a hybrid-mail warning
The August KB articles retain a known-issue notice for a problem first linked to the June 2026 Exchange security update. In certain hybrid deployments, a message sent from an on-premises mailbox as, or on behalf of, an Exchange Online shared mailbox can be delivered to that shared mailbox’s Inbox as an attached wrapper message rather than behaving normally in Sent Items.
Microsoft’s documented scenario involves Exchange Online-hosted shared mailboxes, on-premises mailboxes with Send As or Send on Behalf permissions, and the MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled parameters enabled. Microsoft has published a Setting Override workaround that disables the change introduced in the June update, and says it is still investigating the underlying issue.
The August security update pages do not say that the August packages correct that hybrid behavior. For organizations matching the conditions, the right approach is to test the mail flow after applying the security update and retain the documented workaround in the change plan. Do not defer the CVE-2026-65813 patch merely because a prior Exchange security release caused a known operational problem; patch it, but treat the hybrid-mail test as a deployment gate.
CVE-2026-65813 is currently a sparse advisory with a concrete remediation path. The actionable deadline is not a future score revision or an eventual exploit write-up: it is verifying that every supported Exchange server has reached its August 11, 2026 security-update build, and that every Exchange 2016 or 2019 server still in service has a legitimate path to patches after October.
