CVE-2026-70571: a stack overflow in Exchange Server, and the mail perimeter that keeps it reachable

Exchange is the one server class that almost every organisation publishes to the internet, because mail has to arrive. That is what makes a stack-based buffer overflow in the product worth a separate conversation from the rest of the October 2026 batch. CVE-2026-70571 is classified as remote code execution, the vector is network, and the published summary attributes it to a stack-based buffer overflow.

What the published summaries state

The October 2026 update summaries list CVE-2026-70571 against Microsoft Exchange Server as a stack-based buffer overflow permitting remote code execution, with a CVSS score of 8.1 in the listings that carry one. A separate entry in the same batch, CVE-2026-70279, is described as a cross-site scripting issue in Exchange with a score of 9.3, and the two should not be conflated.
The public descriptions do not name the affected component, the triggering request or the privilege required at the point of the overflow. That last detail is the one I would most want and cannot establish, so treat the exposure question as open and plan for the stricter reading.

Why the mail perimeter never shrinks

Most internet-facing services can be narrowed. A management console can be moved behind a VPN. An API can be restricted to known clients. Mail cannot, because the sender is by definition unknown and the delivery path has to accept the connection before it can decide anything about the sender.
The practical result is a service that terminates untrusted input, parses it in a complex way, and is reachable from the entire internet by design. Memory-safety bugs in that position are historically the ones that get exploited quickly, and the public descriptions of this batch do not publish mitigations that remove the path.

Establishing what you actually run

Exchange deployments are rarely current, and the version surface is more complicated than a build number.
Start from the server build, then check the cumulative update and the security update separately, because Exchange ships them on different cadences and a recent CU does not imply the October security fix is present.
Then enumerate the internet-facing endpoints. Exchange exposes more than the client access protocol: the Outlook Web App path, the Exchange ActiveSync path, the autodiscover path, the MAPI over HTTP path and the management endpoints, which in older deployments were reachable from the internet. Each is a separate reachable surface even though they share a server.
The third check is the one most often skipped: whether any of those endpoints is reachable through a legacy path that was supposed to be decommissioned. Exchange deployments accumulate virtual directories, and a virtual directory that was disabled in the console may still accept connections at the protocol level.

What to do in the gap

The patch is the fix. Where the patch cannot land immediately, reduce the reachable surface to the protocols actually in use. Blocking legacy protocol paths at the load balancer removes them from the exposure without affecting modern clients, and that is a real reduction for a network-vector bug.
Then verify from outside rather than from the change log. A request to each blocked path from an external network position is the only confirmation that the block is effective, and that verification is cheap enough to run after every change.

Detection priorities

The public descriptions do not provide an exploitation signature, so detection has to come from the mail platform's own telemetry and from the host.
On the host, the useful signals are an IIS worker process that restarts outside a maintenance window, a crash dump from a process that has been stable, and any child process spawned by the mail transport service. The third is the one worth writing a rule for, because legitimate child processes from that service are a small and known set.
On the mail flow, correlate delivery patterns with server-side errors. A cluster of transport errors tied to one sending infrastructure is worth a look even when the content looks unremarkable, because a memory-safety exploit does not need the message to contain anything recognisable.

References

• Microsoft Security Update Guide, October 2026 release notes: https://msrc.microsoft.com/update-guide/releaseNote/2026-Oct
• Microsoft advisory entry for CVE-2026-70571: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70571
• Microsoft advisory entry for CVE-2026-70279: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70279
• Microsoft Exchange Server documentation: https://learn.microsoft.com/exchange/