Roughly 22,000 Exchange servers unpatched against replay authentication bypass CVE-2026-62911

A replay flaw, not a crypto break

A high-severity authentication bypass in Microsoft Exchange Server, tracked as CVE-2026-62911, was patched on 11 August 2026, yet tens of thousands of internet-reachable servers are still running vulnerable builds and a public exploit exists. That is the picture laid out in a dev.to analysis of the flaw and of the vulnerability class it belongs to.

The bug is classified as CWE-294, authentication bypass by capture-replay. As dev.to explains, this is not a cryptographic break: the weakness sits in how a credential presentation is bound to its session context. A vulnerable system accepts authentication material that was valid in an earlier session and honors it again in a new one.

Microsoft's advisory, as described in the article, frames the issue as an already-authorized attacker gaining elevated privileges over a network. The CVSS 3.1 base score is 8.0, with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H — network exploitability, low attack complexity, some existing privileges and user interaction required, and high impact on confidentiality, integrity and availability.

dev.to lists the affected products and fixed builds as follows:

• Exchange Server 2016 Cumulative Update 23 — 15.01.2507.072
• Exchange Server 2019 Cumulative Update 14 — 15.02.1544.044
• Exchange Server 2019 Cumulative Update 15 — 15.02.1748.049
• Exchange Server Subscription Edition RTM — 15.02.2562.046

Why messaging platforms keep producing these bugs

Exchange serves several client protocols — MAPI, Exchange Web Services, ActiveSync and Outlook on the web — each with its own authentication flow while sharing identity back ends. According to dev.to, that variety creates far more authentication code paths than a single-protocol service would have, and every path is a place where a session binding can be missed. Legacy protocol support compounds the problem: when an older client flow must keep working, hardening that would break it gets left out, and replay flaws are frequently what remains of that compatibility decision.

The standard defenses against replay, the article notes, are unique session identifiers, nonces that expire with the session, and channel bindings that tie authentication material to a specific connection. A replay becomes possible when a code path skips one of these defenses, or when captured material still satisfies a check in a context it never belonged to.

Detection built for the wrong signal

Replay attacks do not trigger the classic alarm of a burst of failed logins. They surface as a successful sign-in from somewhere unexpected, which means detection programs tuned to failure volume will miss them, while programs that examine the context of successful authentications will catch more of them.

On prevention, dev.to points to two practical measures: shifting authentication toward phishing-resistant methods reduces the value of any exchange an attacker manages to capture, and segmenting the network path between clients and mail servers limits the vantage points from which traffic can be observed.

How big the exposure is

CSIRT.CZ, cited in the article, reported roughly 22,000 internet-reachable Exchange servers that had not been patched, and noted that a public exploit is available. For scale, a ZoomEye query for Microsoft Exchange returns 569,453 matching assets globally, though filtering by the CVE identifier itself returned zero results because the search engine has not yet indexed that identifier against observed assets.

Why it matters

A CVSS 8.0 flaw that lets a moderately privileged attacker escalate over the network, combined with a working public exploit and around 22,000 unpatched internet-facing instances, makes this an immediate patching priority for anyone running the affected builds across Exchange 2016, 2019 and Subscription Edition.

Beyond this single CVE, the episode is a reminder that replay flaws are a recurring class rather than a one-off defect, repeatedly left behind by compatibility trade-offs in multi-protocol platforms. The durable lesson dev.to draws is to treat a successful authentication as an event that deserves context — where it came from, how, and through which protocol — rather than a simple pass or fail.