Microsoft released October 2026 security updates for Exchange Server Subscription Edition, with updates for Exchange Server 2019 and 2016 available only to organizations enrolled in the Extended Security Update program. The release includes a fix for CVE-2026-70571, which Microsoft rates Critical. Microsoft has also clarified that the vulnerability is not known as a zero-day, but that distinction is not a reason to delay patching an internet-facing mail system.
Exchange remediation is a sequence, not a single installer. Administrators must confirm eligibility and prerequisites, patch the Windows Server layer carefully, install the correct Exchange package, restart where required, and validate mail flow, services, hybrid functions, and the final Exchange build.
Confirm the supported update path
Inventory every Exchange node by product, cumulative update or Subscription Edition level, operating system, role, database copy, load-balancer membership, and ESU entitlement. Exchange Server 2016 and 2019 are out of normal support; October packages for those versions are available only through ESU. A server without the right entitlement is not a patching exception—it is a migration and risk-ownership problem.
Use Microsoft’s October Exchange release post as the live source for supported packages and revisions. The post was updated after initial publication, so preserve the version and time of the guidance used for the change.
Coordinate Windows and Exchange updates
Exchange runs on Windows Server, and the two servicing layers cannot be managed independently. Microsoft’s October communication includes updated guidance about Windows Server security updates on Exchange hosts. Before production rollout, check the current Exchange Team post and the applicable Windows Server KB for known issues and revised sequencing.
Patch a representative non-production or passive node first. Verify that the server returns to service cleanly before progressing through the availability group or load-balanced pool. Do not patch every member simultaneously. Preserve capacity for mail transport, client access, and database activation throughout the change.
Use the correct installation context
Download the package from Microsoft, verify its signature and hash where Microsoft supplies one, and run it from an elevated command prompt using the documented Exchange servicing procedure. Security software, pending reboots, low disk space, unhealthy services, or a previously incomplete update can all turn a routine SU into a prolonged outage.
Before installation, record the Exchange build, Windows build, free space, service state, database copy health, queue depth, certificates, and load-balancer status. Export or preserve recent setup logs. A current, tested recovery path matters more than a screenshot showing that backups ran.
Validate the application after restart
After each node returns, check more than service startup. Validate internal and external mail flow, message queues, Outlook connectivity, Outlook on the web, Exchange Web Services or Graph-based hybrid functions, free/busy, calendar publishing where used, transport rules, connectors, and administrative access.
Run Microsoft’s Exchange Server Health Checker and save the output with the change record. Compare the installed build against Microsoft’s current build table. Confirm that load balancers have returned the node to service and that monitoring has not been muted or left in maintenance mode.
Investigate anomalies instead of forcing the rollout
If transport, search, hybrid availability, or client access behaves differently after the update, stop the ring expansion. Compare the issue with Microsoft’s current known-issue guidance, Windows Server update state, .NET version, and recent Exchange SU history. Avoid uninstalling security updates reflexively on an exposed server; isolation, rollback planning, and compensating controls should be deliberate.
CVE-2026-70571 is documented in the Microsoft Security Update Guide. Track the vulnerability separately from package deployment so the organization can prove which servers were affected, which fixed build is running, and when exposure ended.
Close every node, not only the active pair
Include disaster-recovery servers, management hosts, hybrid-only servers, lab systems connected to production identity, and nodes removed temporarily from load balancing. An abandoned Exchange server can retain credentials, certificates, directory permissions, and an attack surface even when it carries little mail.
Completion means every supported node runs the intended Windows and Exchange builds, application checks pass, health-check findings have owners, and unsupported servers have an approved migration or isolation plan. That evidence is the difference between installing an SU and actually reducing Exchange risk.
