Exchange: een ingelogde gebruiker kan andermans mailbox lezen (CVE-2026-96940)

6 oktober 2026 Kwetsbaarheden 6 min lezen

Op 2 oktober 2026 bracht Microsoft de beveiligingsupdates van september voor Exchange Server opnieuw uit, als “V2”. Reden: een kwetsbaarheid die in de eerste release ontbrak, CVE-2026-96940. Een aanvaller die al kan inloggen, kan er mailboxen van andere gebruikers binnen dezelfde organisatie mee lezen, inclusief berichten en bijlagen. Wie de septemberupdate al had geïnstalleerd, is dus niet klaar.

Dit artikel scheidt wat uit de bronnen komt van wat mijn eigen analyse is, want er is nog weinig technische informatie openbaar.

Wat bekend is

Uit de berichtgeving en de aankondiging van Microsoft:

Type: zwakke autorisatie in Exchange Server. Een geauthenticeerde gebruiker kan toegang krijgen tot mailboxen waar hij niets mee te maken heeft. Cross-tenant toegang is niet mogelijk.
Ernst: CVSS 8.8 volgens The Hacker News, dat ook meldt dat Microsoft de kwetsbaarheid als “Exploitation More Likely” beoordeelt. Help Net Security noemt alleen “high” en geen score.
Getroffen: Exchange Server Subscription Edition RTM, Exchange Server 2019 CU14 en CU15, en Exchange Server 2016 CU23. Exchange Online heeft een fix aan de servicekant gekregen, daar hoef je niets te doen.
Misbruik: Microsoft is niet bekend met actief misbruik, maar wijst erop dat dit type kwetsbaarheid eerder is misbruikt.
Ontdekt door: een Microsoft-onderzoeker, intern. Het ging dus niet om een melding van buitenaf.
Oplossing: de V2-updates op alle Exchange-servers én op machines met de Exchange Management Tools. In hybride omgevingen betekent dat ook de lokale servers.

Wat niet openbaar is: hoe de autorisatiecontrole precies wordt omzeild, via welk protocol (EWS, MAPI, OWA) en welke requests daarvoor nodig zijn. Ook zijn er geen indicatoren van misbruik gepubliceerd. Alles wat hieronder over detectie staat, is daarom een startpunt en geen handtekening van deze specifieke aanval.

Waarom dit ertoe doet

“Alleen” een geauthenticeerde aanvaller klinkt als een beperking, maar in de praktijk is een geldig account de meest voorkomende beginsituatie. Gestolen wachtwoorden, een phishingmail die één medewerker te pakken krijgt, een hergebruikt wachtwoord: daarna is de stap naar de mailbox van de directie, de afdeling HR of een zorgverlener één kwetsbaarheid verwijderd.

Dat verandert de waarde van een gecompromitteerd laag-privilege account. Zonder deze kwetsbaarheid leest een aanvaller één mailbox. Met deze kwetsbaarheid leest hij elke mailbox die hij kan aanwijzen. Voor een zorginstelling is dat direct relevant: in mailboxen staan patiëntgegevens, en onbevoegde toegang daartoe kan een meldplichtig datalek zijn. Dit is mijn inschatting, geen oordeel van het NCSC of de Autoriteit Persoonsgegevens.

Daar komt bij dat Exchange 2013 en ouder geen fix krijgen. Draait er nog zo’n server, dan is de enige echte oplossing vervangen of migreren.

Wat je nu doet

Controleer je buildnummer. Staan de servers nog op de originele septemberupdate, dan mis je deze fix.
```
Get-ExchangeServer | Format-Table Name, AdminDisplayVersion, Edition -AutoSize
```
Vergelijk de uitkomst met de buildnummers in de aankondiging van Microsoft in de Exchange-blog. Ik noem hier bewust geen KB-nummers, die heb ik niet uit een betrouwbare primaire bron kunnen verifiëren.
Installeer de V2-updates op alle servers, plus op beheerwerkstations met de Management Tools. Plan een herstart in. Het Exchange Server Health Checker-script uit de CSS-Exchange-repository laat daarna zien of de server er goed voor staat.
Kijk terug. Er is geen bewijs van misbruik voor de patch, maar de update van 2 oktober is ook niet het startpunt van het risico. Een aanvaller die de fout al kende, had ruimte tussen de eerste septemberrelease en nu. Hoe ver je terugkijkt, hangt af van hoe lang je logs bewaard blijven.

Detectie: wat je kunt doen zonder handtekening

Omdat het aanvalspad niet openbaar is, zoek je naar het gevolg: een gebruiker die plotseling veel mailboxen raakt die niet de zijne zijn.

Mailbox auditing

Controleer eerst of auditing aanstaat en wat er wordt vastgelegd:

Get-OrganizationConfig | Format-List AuditDisabled
Get-Mailbox -ResultSize Unlimited | Where-Object { -not $_.AuditEnabled } |
    Select-Object Name, AuditEnabled
Get-Mailbox directie01 | Format-List AuditOwner, AuditDelegate, AuditAdmin

Let op wat dit wel en niet oplevert. Mailbox auditing legt standaard vooral wijzigingen vast (verplaatsen, verwijderen, versturen namens), niet per se het enkel lezen van een bericht. Het gedetailleerde “mail gelezen”-event (MailItemsAccessed) is een functie van Exchange Online en niet iets wat je on-premises erbij krijgt. Als de aanvaller alleen leest, kan het zijn dat je hier weinig of niets van terugziet. Dat is geen reden om het over te slaan, wel om niet te vertrouwen op één bron.

Voor een specifieke, verdachte mailbox:

Search-MailboxAuditLog -Identity directie01 -LogonTypes Delegate, Admin `
    -StartDate (Get-Date).AddDays(-30) -ShowDetails -ResultSize 500 |
    Select-Object LastAccessed, LogonUserDisplayName, Operation, FolderPathName

Exchange HttpProxy-logs

Betrouwbaarder om “wie raakte welke mailbox” te reconstrueren zijn de HttpProxy-logs op de Client Access-kant. Daar staat per request onder meer de geauthenticeerde gebruiker en de mailbox waar het request naartoe wordt geleid (AuthenticatedUser, AnchorMailbox). Het onderstaande script telt per gebruiker hoeveel verschillende mailboxen hij via EWS aanraakte. Dit is een startpunt: de veldnamen en het formaat van AnchorMailbox kunnen per versie verschillen, dus test het eerst op een omgeving waar je de uitkomst kunt controleren.

$dir  = Join-Path $env:ExchangeInstallPath 'Logging\HttpProxy\Ews'
$logs = Get-ChildItem $dir -Filter *.log |
        Where-Object LastWriteTime -gt (Get-Date).AddDays(-14)

$rows = foreach ($f in $logs) {
    $fields = ((Select-String -Path $f.FullName -Pattern '^#Fields:' -List).Line `
                -replace '^#Fields:\s*') -split ','
    Get-Content $f.FullName | Where-Object { $_ -notmatch '^#' } |
        ConvertFrom-Csv -Header $fields
}

$rows | Where-Object { $_.AnchorMailbox -like '*@*' } |
    Group-Object AuthenticatedUser |
    Select-Object Name,
        @{ n = 'Mailboxes'; e = { ($_.Group.AnchorMailbox | Sort-Object -Unique).Count } },
        @{ n = 'Requests';  e = { $_.Count } } |
    Sort-Object Mailboxes -Descending | Select-Object -First 20

Wat je hier verwacht te zien: servicedesk-accounts, secretaresses en beheerders raken legitiem veel mailboxen. Waar je op let, is een gewoon gebruikersaccount dat boven aan de lijst staat, of een account dat in korte tijd van één mailbox naar tientallen gaat. Zet dat af tegen een basislijn van een normale periode, anders zie je alleen ruis.

Overige signalen

Aanmeldingen van het account vanaf een ongebruikelijk IP-adres of op een ongebruikelijk tijdstip, vóórdat het mailboxverkeer begint.
Pieken in EWS-verkeer vanaf één account in je IIS- en HttpProxy-logs.
Nieuwe inboxregels of doorstuurregels op de getroffen mailboxen, een klassieker na mailboxinbraak: Get-InboxRule -Mailbox <naam>.

Bewaar logs voordat je ze laat roteren als je misbruik vermoedt. Na een herstart of een logrotatie is het bewijs weg.

Mijn conclusie

Dit is geen kwetsbaarheid waarvoor je ’s nachts uit bed moet, maar wel een die je deze week afhandelt. Er is geen misbruik bekend, de aanvaller heeft een geldig account nodig, en Exchange Online is al gedicht. Tegelijk is de drempel laag zodra iemand een account heeft, en de schade, namelijk inzage in mail van derden, is precies het soort incident dat je als zorginstelling wilt voorkomen.

De les gaat verder dan deze CVE. Een heruitgegeven update is een trap die je makkelijk mist: de originele release staat als geïnstalleerd in je patchrapportage, terwijl de fix er niet in zit. Controleer bij Exchange dus altijd op buildnummer en niet alleen op “update geïnstalleerd”.