De fout die teams vaak maken na een Exchange-advisory
Een Exchange-patch voelt al snel als een afgerond werkpakket: update plannen, change doorvoeren, klaar.
Maar in de praktijk is dat meestal alleen de technische helft. De andere helft is lastiger: weten welke mailboxrechten, uitzonderingen en beheerrollen je organisatie eigenlijk heeft laten ontstaan. Niet in theorie, maar in de configuratie van vandaag.
Dat onderscheid wordt zichtbaar in NCSC-2026-0349, het actuele advies over negen verholpen kwetsbaarheden in Microsoft Exchange Server. De melding is relevant, maar vooral omdat ze laat zien hoe snel een mailomgeving verandert van “ondersteunende infrastructuur” naar een plek waar identiteit, autorisatie en bedrijfsvoering samenkomen.
Waarom CVE-2026-69380 meer vraagt dan alleen een patch
De zwaarste kwetsbaarheid in het advies is CVE-2026-69380, met een CVSS-score van 9,9. Het gaat om een autorisatiekwetsbaarheid. Volgens het NCSC kan een geauthenticeerde kwaadwillende met beperkte rechten en een toegewezen mailbox via het netwerk zijn rechten verhogen en zich als andere gebruikers voordoen.
Dat detail is belangrijker dan de score alleen. Dit is geen klassiek “iemand van buitenaf breekt in”-scenario. Het risico zit juist in een account dat al legitiem lijkt, maar meer kan dan het zou moeten kunnen.
Voor softwareleiders is dat een ongemakkelijke categorie, omdat veel organisaties hun controles vooral richten op toegang aan de rand: MFA, conditional access, perimeter, admin-accounts. Maar mailboxrechten zijn vaak historisch gegroeid. Tijdelijke uitzonderingen blijven staan. Rollen worden gedeeld. Beheeraccounts krijgen net iets te veel ruimte “omdat het anders operationeel lastig wordt”.
Juist daar ontstaat de frictie. Niet in de patch zelf, maar in de vraag of je nog kunt uitleggen waarom een account deze mailbox mag raken, deze rol heeft, of deze uitzondering nog steeds nodig is.
Mailboxovername raakt direct aan bedrijfsprocessen
De impact van deze kwetsbaarheid is concreet genoeg om niet abstract te blijven. Als een kwaadwillende mailboxen van Exchange-gebruikers kan overnemen, e-mails kan lezen en verzenden en bijlagen kan downloaden, dan gaat het niet alleen om data. Het gaat om handelen namens iemand anders.
En dat raakt direct aan hoe teams werken.
Denk aan finance die goedkeuringen per mail afhandelt. Aan support die escalaties via gedeelde mailboxen verwerkt. Aan sales die contractdetails en klantafspraken in de inbox heeft staan. Aan directieleden die besluiten, context en vertrouwelijke bijlagen via mail ontvangen.
In zulke omgevingen is mailboxtoegang niet “een accountdetail”. Het is een operationele bevoegdheid. Als die bevoegdheid verschuift, verschuift ook de betrouwbaarheid van wat er in de mailbox staat.
Daarom is de eerste vraag na zo’n advisory niet: hebben we gepatcht? De eerste vraag is: welke mailboxen en rollen zijn in de praktijk breder dan we denken?
De tweede kwetsbaarheid laat zien dat de grens niet bij de server stopt
Het advies noemt ook CVE-2026-69356, met een CVSS-score van 9,3. Dit is een XSS-kwetsbaarheid. Een ongeauthenticeerde kwaadwillende kan een speciaal geprepareerde agenda-uitnodiging versturen. Als een gebruiker de vergaderlink opent, kan er scripts worden uitgevoerd binnen de Outlook on the Web-sessie en kunnen mailboxgegevens worden ingezien of gewijzigd.
Dat is een nuttig tegenwicht tegen het idee dat dit soort risico’s alleen in de backend zitten. De werkelijke aanvalsvlakte loopt ook via normaal gebruikersgedrag: een uitnodiging openen, een link volgen, een sessie gebruiken zoals bedoeld.
Voor teams die Exchange als stabiele basis zien, is dat een belangrijk signaal. De kwetsbaarheid zit niet alleen in de serverversie. Ze zit in de combinatie van server, sessie, gebruiker en gewoonte.
En precies daar wordt het lastig om op routine te vertrouwen. Want routine is in mailomgevingen vaak een vorm van efficiëntie. Maar routine is ook de reden dat uitzonderingen onzichtbaar blijven.
Wat ik als eerste zou controleren
Als ik deze melding naast een live omgeving leg, kijk ik niet eerst naar de patchstatus. Ik kijk naar bewijs van toegangsgrenzen.
Welke mailboxrechten zijn ooit tijdelijk toegekend en nooit teruggedraaid? Welke service- of beheeraccounts hebben meer zichtbaarheid dan hun taak vraagt? Welke gedeelde mailboxen zijn zo ingericht dat niemand nog precies weet wie wat kan doen? En welke Outlook on the Web-paden zijn nog niet getest op gedrag dat afwijkt van de normale gebruikersflow?
Dat is geen zware audit om de audit. Het is de kleinste zinvolle interventie, omdat je daarmee snel ziet of de organisatie haar mailomgeving nog begrijpt als een set expliciete rechten, of vooral als een verzameling historische afspraken.
Dat verschil bepaalt hoeveel waarde een patch echt heeft. Een bijgewerkte server met onduidelijke rechtenstructuur is beter dan een kwetsbare server, maar nog steeds geen omgeving die je goed kunt verdedigen of uitlegbaar kunt beheren.
De echte les voor softwareleiders
De belangrijkste les uit NCSC-2026-0349 is niet dat Exchange kwetsbaar is. De les is dat autorisatieproblemen zelden op zichzelf staan. Ze leggen bloot waar een organisatie rechten heeft laten uitdijen tot niemand nog scherp kan uitleggen wie welke mailbox werkelijk kan raken.
Dat is relevant voor CTO’s, founders en eigenaren omdat mail vaak buiten de zichtlijn van productteams valt. Het voelt als commodity-infrastructuur. Maar in de praktijk is het een plek waar identiteit, besluitvorming en vertrouwelijke informatie samenkomen.
Wie daar alleen op patchtempo stuurt, mist het grotere punt. De vraag is niet alleen of de software up-to-date is. De vraag is of je toegangsmodel nog klopt met hoe je organisatie vandaag werkt.
En als dat antwoord niet direct helder is, dan is dat meestal het eerste probleem dat aandacht verdient.