# The Exchange Patch Needs an Entitlement Check

> Nearly 22,000 Exchange servers were still exposed after a fix shipped. The practical problem is bigger than one patch: teams must prove the running build, support entitlement, and replacement path together.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-06
- **Category:** For Developers
- **Tags:** Microsoft Exchange, Patching, Incident Response, Infrastructure Security
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/exchange-patch-needs-an-entitlement-check

---

A security update can exist while your server remains unable to receive it. Microsoft can publish the file, the change board can approve an update window, and the dashboard can stay green. If the server is on an old product line without the required support entitlement, none of that changes the code answering requests.

That gap became visible around Microsoft Exchange Server this week. On 2 September 2026, [Help Net Security reported that Shadowserver's daily internet scans still found nearly 22,000 servers exposed to CVE-2026-62911](https://www.helpnetsecurity.com/2026/09/02/microsoft-exchange-cve-2026-62911-critical-authentication-bypass-flaw/). Microsoft had released its fix on 11 August. By 28 August, the Dutch National Cyber Security Centre had raised its assessment after proof-of-concept code appeared online.

The numbers deserve urgency, but they do not justify panic. As of 6 September, the sources cited here do not establish widespread exploitation of this flaw in the wild. They do establish a public technique, a high-impact path through an internet-facing mail system, and a large population that appeared unpatched weeks after the update. That is enough to act.

The useful lesson reaches beyond Exchange. Patch management fails when it is treated as a calendar instead of a chain of proof. A team needs to know what is exposed, which exact build is running, whether that product line can receive the update, whether the installation succeeded on every node, and what the server could have touched before the fix. Miss one link and “patched” becomes a meeting outcome rather than a property of the system.

## What changed after the August update

Microsoft's August release covered seven Exchange vulnerabilities. CVE-2026-62911 is the one that changed the operational picture later because researchers published a working route around an authentication boundary. The vulnerability is described as capture-replay: material from an authentication exchange can be reused in a context where the server should demand a fresh, properly bound decision.

The official descriptions differ in emphasis, and that difference matters. [The Zero Day Initiative advisory published on 11 August](https://www.zerodayinitiative.com/advisories/ZDI-26-538/) says a remote attacker can escalate privileges on an affected Exchange installation. It says authentication is nominally required, but the existing mechanism can be bypassed, and the flaw can be combined with other weaknesses to execute code as SYSTEM, the powerful Windows service context.

[The Dutch NCSC update dated 28 August](https://advisories.ncsc.nl/2026/ncsc-2026-0289-1.txt) goes further in its operational warning. It says the public proof of concept allows an unauthenticated attacker to execute arbitrary code, gain access to Exchange mailboxes, and use the server as a starting point for further attacks on the victim's network. It raised the advisory from medium likelihood and high damage to high likelihood and high damage.

Microsoft's own CVE wording, repeated in public vulnerability records, describes an authorised attacker elevating privileges over a network. ZDI describes the authentication requirement as bypassable. NCSC describes the published chain as unauthenticated remote code execution. Each statement addresses a different layer: one entry names the underlying flaw, while the public technique combines it with other behavior to remove the practical login barrier and reach code execution.

A responsible response does not resolve the wording dispute by choosing the least alarming sentence or the most dramatic one. Treat an internet-reachable, vulnerable Exchange server as having a credible path to severe compromise. At the same time, do not tell executives that 22,000 organisations were breached or that every unpatched server has an intruder. Exposure is not proof of exploitation.

The dates establish the patch clock. ZDI says the issue was reported to Microsoft on 21 May and disclosed with the fix on 11 August. The NCSC added the proof-of-concept warning on 28 August. [Shadowserver says it began tagging CVE-2026-62911 in its Exchange scan on 27 August](https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-exchange-server-report/). The nearly 22,000 figure reported on 2 September therefore describes the early days of a new internet-wide check, not a timeless census.

That qualification should change how the number is used. Shadowserver says most of its Exchange vulnerability assessments are based on the version observed remotely. A scan can identify a build that appears vulnerable; it cannot inspect every compensating control, maintenance exception, or internal change record. The count is strong evidence of a broad patch gap. It is not a substitute for checking your own servers.

## Why this authentication failure has such a long reach

Exchange is easy to describe as an email server and dangerous to manage as if that were all it did. An on-premises Exchange server terminates connections from users, processes messages, exposes web applications, talks to directory services, handles service identities, and often participates in a hybrid relationship with Microsoft's cloud. It sits where public input meets some of an organisation's most trusted systems.

Capture-replay flaws attack a simple expectation: proof presented for one session should not become a reusable master key. A healthy authentication exchange binds the proof to enough context that copying it elsewhere fails. That context might include the intended service, a fresh challenge, the transport channel, or a session state that cannot be lifted and reused.

When binding is weak, an attacker can make one component vouch in a place where that answer was never intended to carry authority. Think of a receptionist who accepts a photocopy of yesterday's visitor badge because the name and logo look right. The badge was real. The decision to admit this person, at this door, now, was never made.

ZDI locates the specific flaw in Exchange's handling of authorisation requests and calls out improper session management. Its advisory assigns a CVSS score of 8.8, while the NCSC text refers to a score of 8.0. That numerical difference should not delay action. Both ratings describe serious network-reachable impact, and the public chain changes the practical conditions a defender must assume.

The SYSTEM outcome explains why this is not merely a mailbox privacy issue. Code running with that context can alter the server, inspect locally available secrets, create persistence, and act through the server's network position. What happens next depends on architecture. A tightly segmented mail server with narrow service rights presents a smaller blast radius than a flat network where the same administrative identities and management paths reach domain infrastructure, backups, and other servers.

Mail also provides unusually valuable intelligence. A compromised mailbox can reveal password-reset messages, invoices, internal projects, travel, customer disputes, and the language colleagues use with one another. That information can support convincing fraud even when the attacker cannot move deeper into the network. Restoring the server without reviewing mailbox access and account changes may leave the human part of the incident untouched.

This is why a patch window is only the first response boundary. The update removes a known route into future requests. It does not tell you whether someone used that route yesterday, what they changed, or which identities became untrustworthy. The absence of a public mass-exploitation claim keeps the investigation proportionate. It does not make an exposed high-value server clean by assumption.

A team should therefore separate three questions. Is the server vulnerable now? Was it reachable while vulnerable? Is there evidence that someone used the opportunity? The first is answered with build and configuration evidence. The second comes from network architecture and historical exposure. The third requires logs, endpoint evidence, identity review, and a clear statement about what those records can no longer prove.

## The support entitlement is part of the patch path

The awkward part of this incident sits in the product lifecycle rather than the exploit. Exchange Server 2016 and 2019 are out of ordinary support. The Dutch NCSC says those versions now receive security updates only through Microsoft's Extended Security Update program, commonly shortened to ESU.

Help Net Security quotes Microsoft's release guidance more precisely: only customers enrolled in Period 2 of the Exchange 2016 and 2019 ESU program are eligible for security updates released from May through October 2026. Exchange Server Subscription Edition remains the supported product line. That creates at least three operational states where a dashboard might simply say “Exchange”:

1. **Subscription Edition can receive the current security update.** The team still has to install it on the right baseline and prove the live build changed.

2. **Exchange 2016 or 2019 has the required Period 2 ESU entitlement.** The update path exists, but it may use packages and procedures specific to that program.

3. **Exchange 2016 or 2019 lacks that entitlement.** Waiting for the next normal patch cycle will not solve the problem. Exposure must be reduced while the organisation moves to a supported destination.

Those are materially different security states. Product name alone cannot drive remediation. Neither can a generic software-inventory flag that marks an operating system current while ignoring the application and its support contract.

At that point, procurement becomes security engineering. The right to download and deploy a fix can depend on a commercial record. If the asset owner, licensing owner, and security owner keep separate inventories, the gap may surface only during an emergency. A scanner finds an old build, operations opens a ticket, and the person on call discovers that the expected package is unavailable to that server.

The fix is not to blame procurement after the fact. Put entitlement in the asset model. For every internet-facing product, record the product line, exact version, support end date, update channel, entitlement owner, replacement target, and the date on which the final supported update arrives. Alert before any of those dates becomes a midnight discovery.

Support also has a technical meaning. A server may be licensed correctly and still sit on a cumulative-update baseline that cannot accept the security package directly. It may have prerequisites, language-specific files, hybrid dependencies, or a maintenance sequence that changes how the update is applied. [Microsoft's KB5121573 page for Exchange Server Subscription Edition SU9](https://support.microsoft.com/en-us/servicing/exchange/server/update/2026/5121573) lists the August CVEs, provides the standalone package, publishes its SHA-256 hash, and points administrators to deployment guidance.

That hash is useful, but its role is narrow. It lets a team compare the downloaded file with the value Microsoft published. It does not prove the package ran, every server rebooted into the new build, traffic returned to the updated node, or a forgotten disaster-recovery image was replaced. File integrity and fleet state are different controls.

A migration plan deserves the same precision. “Move off Exchange 2019” is not an executable response. Name the destination, owner, dependency map, test window, traffic cutover, rollback boundary, and final date when the old listener disappears. If a legacy server must remain reachable internally for a short period, document which systems may connect and remove its public route rather than relying on its obscurity.

The NCSC recommendation is direct: Exchange 2016 and 2019 systems without ESU support should be reachable only from internal networks and phased out where possible. Internal-only access reduces opportunity. It does not repair the vulnerability, and it does not make every internal account or device trustworthy. Treat it as containment while replacement proceeds.

## A successful installer is not fleet proof

Exchange rarely lives as one obvious machine under one obvious name. Organisations may have multiple mailbox servers, client-access paths, hybrid connectors, load balancers, standby systems, lab copies, recovery images, and old hosts kept alive for a migration that never quite finished. An update can succeed perfectly on the server an administrator touched while public traffic continues to reach another node.

Start from the outside. List every public name, address, reverse proxy, load balancer, and network-address translation rule that can lead to Exchange. Resolve the names from more than one network. Compare the result with the configuration the operations team believes is current. A retired address that still forwards traffic is part of the production perimeter, whatever the asset database says.

Then map each route to a running Exchange instance and exact build. Do not accept a ticket comment saying “August patches installed.” Record the build observed on each node after the maintenance, the package identifier, the installation time, and the restart state. A load balancer health check that receives a login page proves availability, not the security-update level behind it.

Microsoft's August KB gives administrators a concrete verification aid. It says to run the Exchange Server Health Checker to confirm installation success and identify additional required actions. [Microsoft's Health Checker documentation](https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/) explains that the script collects server details and identifies common configuration issues. Run it from a controlled administrative session, preserve the output, and tie that output to the server identity in the change record.

The checker should support independent evidence rather than become a ceremonial green light. Compare the reported build with Microsoft's expected fixed build for that product line and cumulative update. Verify the Windows services returned normally. Send and receive test mail through the actual client and transport paths. Exercise hybrid free/busy or other features your environment uses, because Microsoft's KB also lists known issues affecting shared-mailbox wrappers, published calendars, and delegated mailbox availability in some hybrid setups.

Known issues belong in the maintenance plan rather than an indefinite postponement of a high-impact security update. A team can test the affected feature, prepare a workaround, communicate expected disruption, and still close the exposed route. Quietly leaving the server vulnerable because someone fears a calendar problem trades a bounded operational risk for an open security risk.

Proof also includes negative space. Find the instances that did not report. A server absent from the health-check collection, endpoint manager, or configuration query should fail the gate rather than disappear from the denominator. Ten compliant results out of ten respondents says little when the load balancer has twelve backends.

The same rule applies to disaster recovery. A clean production fleet can be rolled back into vulnerability if the recovery image, automation template, or warm standby still carries the old build. Update those sources after production validation. Otherwise the next outage can quietly undo the security work.

A useful completion statement names both scope and evidence: all seven request-serving nodes and two standby nodes report the fixed build; external names resolve only to those nodes; the Health Checker outputs are attached; client, transport, and hybrid tests passed; the previous images are retired. That sentence can be audited. “Exchange patched” cannot.

## Decide how much incident work the exposure earns

Patching and investigation should begin together, but the investigation depth should follow the server's actual exposure. An Exchange host that was never reachable from untrusted networks and accepts connections only through a filtering tier has a different risk profile from an Outlook Web Access endpoint listening directly on the public internet. The same CVE does not produce the same incident plan everywhere.

Build a dated exposure window. Begin with 11 August, when the fix and public advisory arrived, unless internal intelligence supports an earlier date. Mark 28 August, when NCSC reported public proof-of-concept code. Record when each server actually received the fix and when any temporary network restriction began. If logs do not cover the whole period, say so plainly.

Public proof of concept raises the likelihood that scanning and attempted exploitation will follow. It does not prove your host was targeted successfully. Search web, proxy, firewall, and endpoint records for abnormal requests, unexpected child processes, new services, unusual scheduled tasks, changed files in web-accessible directories, and new outbound connections from the Exchange server. Use vendor and trusted incident-response guidance for exact indicators as they become available rather than inventing a signature from a headline.

Identity evidence matters as much as process evidence. Review privileged role changes, newly created accounts, suspicious mailbox permissions, forwarding rules, transport rules, application consents, and authentication events that do not fit normal administration. An attacker interested in durable access may prefer a quiet account or forwarding rule over a noisy program that runs on every boot.

Hybrid environments add another trust path. Determine which cloud and on-premises identities, certificates, connectors, and service relationships the Exchange server could use. If evidence suggests SYSTEM-level compromise, treat secrets available to that machine as potentially exposed. Rotate according to reach and evidence, not by resetting every password in the company without a plan.

There are two common mistakes here. The first is declaring an incident solely because a scanner sees an old version. That confuses vulnerability with compromise and can waste the team's attention. The second is closing the ticket solely because the update now appears installed. That ignores the period when an internet-facing server was both vulnerable and valuable.

A calibrated decision can be written as a matrix. Public reachability, duration, proof-of-concept availability, logging quality, endpoint coverage, observed anomalies, and the server's authority each increase or decrease the investigation depth. The resulting action might range from a focused log review to isolation, credential rotation, forensic acquisition, and rebuild.

If suspicious evidence appears, preserve first and clean second where operations permit. Snapshot volatile and durable evidence using your incident process, remove the host from traffic, contain reachable identities, and rebuild from a trusted source. Running an antivirus scan and returning the same machine to service may remove one file while preserving a changed account, stolen credential, or altered configuration.

Absence of evidence needs a confidence statement. “No indicators found in 30 days of complete endpoint and proxy telemetry” is stronger than “nothing in the Windows event log we still have.” Both can be honest. Only one supports a high-confidence conclusion.

Mail systems create business pressure to shorten investigation. Every minute offline affects communication. Prepare a degraded mode before the incident: alternate contact routes, queued delivery behavior, emergency administrator access, and an agreed threshold for taking a node out of service. A response plan that assumes unlimited downtime will be abandoned when the server is actually busy.

## What to do before the next maintenance meeting

The best response is a short sequence with named outputs. It should work for a small operations team and still scale to a larger fleet. The order below puts containment and proof ahead of paperwork without losing the audit trail.

1. **Inventory every reachable Exchange path.** Record public names, addresses, proxies, load balancers, published services, hybrid connectors, and the server nodes behind them. Include standby and recovery systems. The output is a route-to-node map, not a list of friendly server names.

2. **Classify product line and entitlement.** For each node, record Exchange 2016, Exchange 2019, or Subscription Edition; the cumulative-update baseline; the exact running build; and whether the node has the update entitlement it needs. Escalate any 2016 or 2019 server whose Period 2 ESU status is unknown.

3. **Reduce reach for any node that cannot be fixed now.** Remove direct public access where the service design allows it, restrict upstream routes to required gateways, and make the exception expire. If the system lacks ESU support, use containment to buy migration time rather than presenting it as a permanent fix.

4. **Install the vendor update on every covered node.** Follow Microsoft's package and prerequisite guidance for the exact product line. Verify the downloaded file against the vendor-published hash where provided. Preserve installation logs and restart results.

5. **Prove the running state.** Run Microsoft's Exchange Health Checker, compare each live build with the fixed level, test real mail and hybrid functions, and confirm that external traffic reaches only verified nodes. Fail the change if any expected node is silent.

6. **Review the vulnerable interval.** Search network, web, endpoint, Windows, Exchange, and identity records according to reach and retention. Look for server execution, persistence, mailbox-rule changes, privilege changes, and abnormal outbound connections. Record what the available logs cannot answer.

7. **Contain and rebuild if evidence crosses the threshold.** Remove affected nodes from traffic, preserve evidence, rotate secrets according to the server's authority, and restore from a trusted state. Review mailboxes and identities, not just files on disk.

8. **Put the replacement date in the operating calendar.** Exchange 2016 and 2019 are living on a temporary security-update path. Assign the migration owner, approved destination, dependency tests, cutover date, and the date public routes to the old product disappear.

This sequence avoids two bad shortcuts. It does not wait for perfect attribution before closing a known vulnerable route. It also does not let a successful installer erase the need to understand earlier exposure.

For a managed-service customer, the same steps become questions for the provider. Which exact Exchange product and build serves our mail? Was CVE-2026-62911 fixed on every production and standby node? Does the older product require ESU, and is that entitlement active? When did the final node become fixed? What evidence was reviewed for the preceding interval? What is the replacement date?

A provider should be able to answer without revealing sensitive internal details. “We patch regularly” is not an answer to a versioned, dated vulnerability. Ask for attestation tied to the affected service, fixed build, completion date, and scope.

Engineering leaders should also check how patch completion is measured across other products. If the metric counts closed tickets, approved changes, or downloaded packages, it is measuring work. The security property is the fraction of in-scope, request-serving instances proven to run fixed code. Those denominators are rarely identical.

## A patch chain you can actually defend

CVE-2026-62911 is serious because it sits on a public-facing system with deep organisational reach. The public proof of concept shortened the comfortable part of the patch window. The reported population of nearly 22,000 apparently vulnerable servers shows that publishing a fix does not cause deployment.

The more durable finding is the support gap. Exchange 2016 and 2019 can receive this late-life update only through a specific ESU path, and that path ends. A security program that knows the CVE but not the entitlement has found the hazard without confirming that remediation is possible.

Treat patching as a chain: exposure, product line, entitlement, package, installation, running build, traffic path, and earlier trust. Each link produces evidence. When one link is unknown, mark the server unknown rather than rounding it up to safe.

As of 6 September 2026, the cited sources support prompt remediation and a proportionate review. They do not support claiming that every exposed server has been compromised. That distinction protects credibility while leaving no excuse for delay.

The next maintenance meeting should end with fewer adjectives and more nouns: server names, build numbers, package IDs, health-check reports, route maps, exposure dates, and a migration owner. That is what turns Microsoft's update into your control.

For one practical security briefing each month, join the newsletter. One email per month, and no noise between them.

## Sources

- [Microsoft Support: Description of the security update for Microsoft Exchange Server Subscription Edition RTM, August 11, 2026](https://support.microsoft.com/en-us/servicing/exchange/server/update/2026/5121573), accessed 2026-09-06
- [Microsoft CSS-Exchange: Exchange Server Health Checker](https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/), accessed 2026-09-06
- [Netherlands National Cyber Security Centre: NCSC-2026-0289 revision 1](https://advisories.ncsc.nl/2026/ncsc-2026-0289-1.txt), accessed 2026-09-06
- [The Shadowserver Foundation: Vulnerable Exchange Server Report](https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-exchange-server-report/), accessed 2026-09-06
- [TrendAI Zero Day Initiative: ZDI-26-538](https://www.zerodayinitiative.com/advisories/ZDI-26-538/), accessed 2026-09-06
- [Help Net Security: Nearly 22,000 Microsoft Exchange servers remain exposed to critical security flaw](https://www.helpnetsecurity.com/2026/09/02/microsoft-exchange-cve-2026-62911-critical-authentication-bypass-flaw/), accessed 2026-09-06

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._