What happened
Microsoft published the Exchange V2 security updates on October 2, 2026, adding CVE-2026-96940 ahead of the intended release schedule. The Exchange Team said the difference from the original September release is the addition of this vulnerability and recommended deployment at the earliest opportunity. On October 5, 2026, CERT-FR published affected-build guidance and directed customers to obtain the vendor fixes.
CVE-2026-96940 is an authenticated, network-reachable Exchange Server privilege-escalation flaw scored 8.8 by Microsoft. Microsoft said it found the vulnerability internally and was not aware of active exploitation. Fixed builds are 15.01.2507.075 for Exchange 2016 CU23, 15.02.1544.048 for Exchange 2019 CU14, 15.02.1748.053 for Exchange 2019 CU15 and 15.02.2562.053 for Exchange Server Subscription Edition RTM. Exchange Online customers are protected, but hybrid organisations must update any on-premises Exchange servers and Exchange management-tools workstations.
KB5129955 publishes SHA-256 40B3825435C072298896563DA623E288F79A9B913E2B674FFC7CA4A38547857F for ExchangeSubscriptionEdition-KB5129955-x64-en.exe. Documented issues include HTTP 500 responses for published .ics calendars, delegated-mailbox free/busy failure in Graph-only hybrid deployments and a ContentEngine deadlock involving missing Korean WordBreaker rule files. Attribution posture: Microsoft names no actor and says it is not aware of active exploitation of CVE-2026-96940.
Why this matters now
Exchange remains a privileged communications and identity-adjacent platform. An authenticated attacker who can elevate privileges may gain materially broader access than the original account permitted, making the flaw relevant to organisations already contending with stolen credentials, compromised mailboxes or malicious insiders. Lack of known exploitation lowers immediate incident probability but does not remove the control-plane consequence.
The deployment decision is complicated by product lifecycle and operational side effects. Exchange Server 2016 and 2019 customers require the applicable Extended Security Update entitlement, while Exchange Online customers are already protected. The V2 packages also carry documented calendar, hybrid free/busy and ContentEngine issues that platform owners must test rather than using them as an indefinite reason to defer.
National CERT advisories on October 5 convert an unusual early vendor release into a clearer enterprise action. Security leaders should distinguish urgency from evidence of attack: Microsoft says the flaw was internally discovered and it is not aware of exploitation. The correct posture is expedited remediation, targeted monitoring for authenticated abuse and an explicit exception process where business impact blocks immediate deployment.
The decision for security leaders
Assign the messaging platform owner to reconcile all Exchange servers, hybrid components and management workstations against the fixed builds. Confirm that legacy servers can actually obtain the update through the required ESU programme. Where entitlement, compatibility or maintenance constraints block deployment, document the exception, compensating controls, accountable executive and earliest achievable closure date.
Require accelerated but evidence-based testing of calendar publication, hybrid delegated-mailbox free/busy and ContentEngine workloads. A known issue is a deployment constraint to manage, not automatic justification for deferral. Pair the update with review of authenticated administrative activity because the vulnerability’s prerequisite makes compromised or misused accounts the relevant detection context.
Evidence of closure
- Build inventory confirms every supported Exchange component meets its fixed threshold.
- Package validation matches the vendor-published SHA-256 hash.
- Post-deployment tests pass for calendar, hybrid free/busy and ContentEngine workloads.
- Exception register records an approved disposition for every unpatched legacy server.
The Security.io assessment
The unusual release timing can be misread as evidence of an active emergency. Microsoft explicitly says the flaw was found internally and that it is not aware of exploitation. Security.io therefore assesses this as an urgent exposure-management decision rather than a confirmed incident. The privilege impact, Exchange’s placement and legacy-version complications justify inclusion despite the absence of active exploitation.
The national guidance published inside the edition window materially improves the affected-build decision, while the Microsoft package documentation makes operational trade-offs visible. Closure requires installed-build evidence and workload validation. A vulnerability scanner result or successful installer exit code is insufficient if hybrid functions failed, management tools remained outdated or an unsupported server never received the package.
Questions for the morning meeting
- Which on-premises Exchange servers and management workstations remain below the fixed builds?
- Are Exchange 2016 and 2019 systems enrolled in the required ESU programme?
- Can the published known issues be tolerated or mitigated during deployment?
- What telemetry would reveal abuse by an already authenticated account?