An authenticated Exchange user can read someone else’s mail.

That is the cybersecurity problem Microsoft just patched out of band as CVE-2026-96940, a weak-authorization bug scored 8.8, and it should change how you treat every mailbox session you already trust.

Microsoft called it weak authorization. An authenticated attacker can elevate privileges and open mailboxes they were never granted. You need a working login. A glamorous exploit chain is optional.

Weak authorization turned neighbors into readers

Out-of-band patches exist because the next cumulative update is too late. If you still run Exchange Server on hardware you own, the store is yours to close. Hybrid mail flow will not patch the on-premises Client Access and mailbox roles for you.

The interesting part is who already counts as authenticated. A contractor mailbox you never disabled. A shared kiosk. A service account stuffed into EWS for a ticketing sync. A password that survived a helpdesk reset. Any of those can become a reader of mail that was never theirs.

You already spend money to keep strangers off Outlook on the web.

This bug lives after that fight is over. Mailbox isolation is an authorization decision sitting next to the item, then a pile of RBAC roles, impersonation flags, and protocol endpoints get a vote. When that vote is sloppy, your folder tree is a suggestion.

CVE-2026-96940 is the class of bug operators shrug at because it requires a login. That requirement should scare you. Most of your users are authenticated all day. So are the printers, scanners, and line-of-business jobs that speak SMTP and EWS with stored secrets.

The attacker is already on the side of the firewall you quote in board decks. Threat-protection that scores inbound attachments will miss a user reading another user’s Inbox through a legitimate protocol. Your SIEM may log it as ordinary mailbox access if you never tagged the source identity as out of policy.

This is a bad look for anyone who told leadership that MFA contains mail. MFA proves a person or a token. Authorization is the control that decides whether Legal’s archive opens.

Expect the same pattern on the next on-premises role. Your cyber security program should assume authenticated mailbox reads are in the threat model until logs prove they are not.

Cybersecurity still stops at the login prompt

Walk your last tabletop. You probably spent the hour on phishing, malware, and the moment the VPN fell. You spent less time on what a valid mailbox can do to every other mailbox.

Defense in depth on paper includes identity, protocol, and data. In the rack it often means a firewall rule, an agent, and a hope that Exchange RBAC still matches the org chart from 2019. Security hardening for mail usually means TLS and a spam filter. The authorization graph gets an annual access review that nobody finishes.

Privilege reviews that only look at Domain Admins miss Exchange Organization Management, mailbox import and export, and impersonation. Those roles print other people’s mail as surely as a leaked backup.

Brute-force still matters, which sounds backwards until you sit with it. If any successful login can become a mailbox reader, the cheapest path is still guessing, stuffing, or buying the password. Rate-limit Outlook on the web, EWS, and ActiveSync the way you would an admin plane.

Failed logons are yesterday’s dashboard.

Threat detection has to catch this identity opening a mailbox it does not own. That is a different query, and it is the query you will want during incident response.

Treat every mailbox session as a privileged hop

Do this on the metal you actually run. No product tour required.

Start with the servers you can name. Apply Microsoft’s out-of-band updates, then read the build numbers off each Client Access and mailbox role. A console that says pending reboot is still the old code.

If the change window is days away, cut protocols you do not use. Disable IMAP, POP, and stale EWS applications. Disable contractor mailboxes that still answer AUTH.

Export the RBAC and mailbox-permission set today. ApplicationImpersonation, FullAccess, and organization-wide roles left over from a migration are live keys. Rotate those passwords and app registrations before you go home.

Then hunt. Message tracking, IIS logs for EWS, and Mailbox Audit will show one identity opening another. Fan-out across many Inboxes is the pattern you want. Treat it as incident response, preserve the store, and keep the audit stream intact.

Turn audit on for executives and sample the long tail of ordinary users. Alert on mailbox owners that do not match HR, on user-agents that are not your approved Outlook builds, and on overnight reads of Legal and Finance.

Put the front door under the same brute-force pressure you use for VPN. Geo-fence Outlook on the web if your staff does not travel. ipban blocks on repeated failures, and IPBan Pro on Windows edge hosts if that is your stack, shrink the set of passwords that ever become authenticated. They leave the authorization bug in place. They make the foothold rarer.

Rehearse the playbook with a clean login as the given. Your team should know how to export audit, disable a mailbox without deleting evidence, and tell Legal which other Inboxes were touched.

Login success is the start of mailbox risk. Close the authorization hole, then keep watching who reads whom.

Sources

• Microsoft Exchange Flaw Lets Authenticated Attackers Read Other Users’ Mailboxes