Es gibt in diesem Sommer eine Sorte Exchange-Server, die vollkommen unauffällig ist. Die Dienste laufen, die Warteschlangen sind leer, das Monitoring ist grün, und im Ereignisprotokoll steht nichts Interessantes. Das letzte Sicherheitsupdate hat dieser Server im Februar bekommen. Nicht wegen eines kaputten WSUS und nicht wegen eines fehlgeschlagenen Setups, sondern weil im Frühjahr ein Vertrag nicht verlängert wurde.
Das Update vom 11. August 2026 ist ein guter Anlass, diesen Zustand einmal aktiv zu suchen. Microsoft hat sieben Schwachstellen geschlossen, einen Webclient ersatzlos abgeschaltet und damit nebenbei sichtbar gemacht, wer beim Thema Exchange on premises überhaupt noch versorgt wird.
Die Frage vor der Frage: bekommt der Server überhaupt noch etwas?
Exchange Server 2016 und 2019 sind seit dem 14. Oktober 2025 aus dem Support. Sicherheitsupdates gibt es seither nur noch über das kostenpflichtige ESU-Programm, und dieses Programm hat Microsoft in zwei getrennte Abschnitte geschnitten. Period 1 lief von Oktober 2025 bis April 2026, Period 2 läuft von Mai bis Oktober 2026.
Entscheidend ist der Übergang zwischen beiden. Period 2 verlängert sich nicht von selbst. Wer in Period 1 gebucht hatte, musste aktiv erneut bestellen, jede ESU-Bestellung ab dem 15. April 2026 zählt automatisch als Period 2. Wo das nicht passiert ist, besteht seit Mai kein Anspruch mehr auf die Updates. Das betrifft rückwirkend Mai, Juni und Juli und jetzt eben auch den August.
Der unangenehme Teil daran ist, dass es keine technische Sperre gibt. Kein Dienst verweigert den Start, keine Konsole zeigt eine Warnung, kein Lizenzzähler läuft ab. Der Patchstand friert einfach ein, und die einzige Stelle, an der man das sieht, ist die Buildnummer. In Umgebungen, in denen Exchange als erledigtes Thema gilt und nur noch jemand danebensteht, wenn es klemmt, kann das eine Weile unbemerkt bleiben. Bis der nächste externe Schwachstellenscan kommt oder der Versicherer nachfragt.
Exchange Server SE ist davon nicht betroffen. Dort ist das August-SU regulärer Bestandteil des Abonnements, ohne Zusatzvertrag und ohne Stichtag. Wer bereits ESU gekauft hat und beim Bezug der Pakete hängt, wird von Microsoft an ExchangeandSfBServerESUInquiry@service.microsoft.com verwiesen.
Und für Period 3 muss niemand Budget einplanen: Microsoft hat ungewöhnlich klar gesagt, dass es nach Oktober 2026 keine weitere Verlängerung gibt. Nach dem August-Update bleiben damit noch zwei reguläre Patchdays, September und Oktober. Danach ist Schluss.
Was am 11. August behoben wurde
Sieben CVEs, verteilt über Remote Code Execution, Rechteausweitung, Spoofing, Denial of Service und eine fehlende Autorisierungsprüfung. Keine davon war zum Veröffentlichungszeitpunkt öffentlich bekannt oder wurde ausgenutzt, Microsoft bewertet alle sieben als Exploitation Less Likely.
| CVE | Typ | CVSS |
|---|---|---|
| CVE-2026-62913 | Remote Code Execution | 8.8 |
| CVE-2026-62911 | Elevation of Privilege | 8.0 |
| CVE-2026-62914 | Spoofing | 7.3 |
| CVE-2026-62910 | Elevation of Privilege | 7.2 |
| CVE-2026-62912 | Denial of Service | 6.5 |
| CVE-2026-62915 | Security Feature Bypass | 6.5 |
| CVE-2026-65813 | Elevation of Privilege | 6.5 |
Diese Einstufung sagt etwas über die Wahrscheinlichkeit aus, nicht über die Folgen. Und die beiden oberen Einträge ergänzen sich unangenehm gut. CVE-2026-62913 ist ein Pufferüberlauf auf dem Heap, der einem authentifizierten Benutzer mit geringen Rechten Codeausführung erlaubt, ganz ohne Zutun eines Opfers. CVE-2026-62911 ist eine Authentifizierungsumgehung per Capture-Replay. Zusammengenommen ergibt das den Weg, den man in Exchange-Vorfällen der vergangenen Jahre immer wieder gesehen hat: ein einzelnes übernommenes Postfachkonto als Startpunkt, der Server als Ziel.
Bei CVE-2026-62911 lohnt außerdem ein Blick auf die Herkunft. Die Lücke wurde auf der Pwn2Own in Berlin demonstriert. Nach solchen Wettbewerben werden technische Details erfahrungsgemäß irgendwann veröffentlicht, und der Abstand zwischen Veröffentlichung und einem brauchbaren Proof of Concept ist bei Exchange traditionell kurz. Wer den Rollout auf den nächsten Wartungssamstag schiebt, sollte das im Hinterkopf behalten.
OWA Light wird nicht repariert, sondern entfernt
Der einzige Eintrag mit sichtbarer Wirkung für Anwender ist CVE-2026-62914. Microsoft hat sich hier gegen einen Fix und für den Rückbau entschieden: Mit diesem Update und allen folgenden wird der OWA-Light-Client bei der Installation dauerhaft deaktiviert. Es gibt keinen Schalter, mit dem man ihn zurückholt. Abgekündigt war der Client seit rund zwei Jahren, im Juli kam der Hinweis, dass die Entfernung im August erfolgt.
Wen das trifft, ist von außen schwer zu sehen, deshalb vor dem Rollout kurz nachdenken statt hinterher Tickets sortieren. Erfahrungsgemäß hängen an OWA Light drei Gruppen: Anwender, die mit Screenreadern arbeiten und die schlanke Oberfläche bewusst gewählt haben, Standorte mit wirklich schmaler Anbindung, und, oft vergessen, automatisierte Anmeldungen. Synthetische Transaktionen und selbstgebaute Verfügbarkeitsprüfungen greifen gern auf die einfache Anmeldeseite zu, weil die sich ohne JavaScript-Engine bedienen lässt. Solche Prüfungen fallen nach dem Update aus, und zwar mit einem Fehlerbild, das aussieht wie ein Ausfall von OWA insgesamt.
Für Umgebungen, in denen das Update noch nicht sofort installiert werden kann, nennt Microsoft eine Zwischenlösung, die genau diese eine Schwachstelle entschärft:
Set-OwaMailboxPolicy -Identity "Default" -OwaLightEnabled $false
Set-OwaVirtualDirectory -Identity "OWA (Default Web Site)" -LogonPageLightSelectionEnabled $falseDas deckt CVE-2026-62914 ab und sonst nichts. Die übrigen sechs Lücken bleiben offen, die Zwischenlösung kauft also Zeit für die Terminplanung, nicht für das Quartal.
Patchstand feststellen
Vor dem Rollout steht die Bestandsaufnahme, und die ist bei Exchange unangenehmer, als sie sein müsste. Get-ExchangeServer zeigt nur den Stand des Cumulative Update und verschweigt jedes darauf installierte Sicherheitsupdate. Ein Server, der seit Februar keinen Patch mehr gesehen hat, sieht in dieser Ausgabe genauso aus wie einer, der gestern aktualisiert wurde. Belastbar ist allein die Dateiversion von ExSetup.exe.
Das lässt sich für die gesamte Organisation in einem Durchlauf über die administrative Freigabe abfragen, ohne zusätzliche Werkzeuge und ohne WinRM:
$aktuell = @{
'15.02.2562.046' = 'Exchange SE RTM, Aug26SU'
'15.02.1748.049' = 'Exchange 2019 CU15, Aug26SU'
'15.02.1544.044' = 'Exchange 2019 CU14, Aug26SU'
'15.01.2507.072' = 'Exchange 2016 CU23, Aug26SU'
}
Get-ExchangeServer | Where-Object { $_.ServerRole -ne 'Edge' } | ForEach-Object {
$exe = "\\$($_.Name)\C$\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe"
$build = (Get-Item $exe -ErrorAction SilentlyContinue).VersionInfo.ProductVersion
$stand = 'NICHT AKTUELL'
if ($aktuell.ContainsKey($build)) { $stand = $aktuell[$build] }
[PSCustomObject]@{ Server = $_.Name; Build = $build; Stand = $stand }
} | Sort-Object Stand, Server | Format-Table -AutoSizeBei abweichendem Installationspfad muss der Pfad im Skript angepasst werden, Edge-Transport-Server sind bewusst ausgenommen, weil sie nicht im Active Directory der Organisation stehen und ohnehin gesondert behandelt werden. Vergessen werden regelmäßig auch die Arbeitsplätze, auf denen nur die Exchange Management Tools installiert sind. Die tauchen in dieser Liste nicht auf, brauchen das Update aber ebenfalls.
Wer es umfassender mag, nimmt den Exchange Health Checker aus Microsofts CSS-Exchange-Repository. Das Skript prüft neben dem Build auch .NET-Version, TLS-Konfiguration, Zertifikate und eine ganze Reihe bekannter Fehlkonfigurationen und ist damit die gründlichere, aber auch deutlich gesprächigere Variante. Für die reine Frage, welcher Server beim Patchstand hinterherhinkt, reicht der Einzeiler oben.
Zur Einordnung die Zielwerte nach dem August-Update im gewohnten Kurzformat:
| Version | KB | Build |
|---|---|---|
| Exchange Server SE RTM | KB5121573 | 15.2.2562.46 |
| Exchange Server 2019 CU15 | KB5121574 | 15.2.1748.49 |
| Exchange Server 2019 CU14 | KB5121575 | 15.2.1544.44 |
| Exchange Server 2016 CU23 | KB5121576 | 15.1.2507.72 |
Für Exchange Online besteht kein Handlungsbedarf, dort ist der Fix längst eingespielt.
Beim Rollout selbst
An den Eigenheiten der Exchange-Sicherheitsupdates hat sich seit Jahren nichts geändert, sie sorgen trotzdem zuverlässig für dieselben Anrufe.
Das Paket muss zum Cumulative Update des jeweiligen Servers passen, ein Update für CU15 lässt sich nicht auf CU14 anwenden. Innerhalb eines Zweiges sind die SUs kumulativ, ausgelassene Monate müssen also nicht nachgeholt werden, das jüngste Paket genügt.
Installiert wird aus einer erhöhten Eingabeaufforderung, nicht per Doppelklick auf die MSP-Datei. Ohne Adminrechte bricht das Setup je nach Konstellation entweder mit einer wenig aussagekräftigen Meldung ab oder, schlimmer, mittendrin. Das Ergebnis ist dann ein Server mit halb aktualisierten Komponenten und Diensten, die nicht mehr starten. Die Meldung, dass sich die Anwendung nicht starten lässt, ist fast immer genau dieser Fall und kein Defekt im Update.
Nach dem Neustart lohnt der Blick in die Dienstliste, bevor der nächste Server drankommt. In einer DAG bedeutet das: einen Knoten nach dem anderen, Datenbanken vorher aktiv umziehen, hinterher zurück. Die Versuchung, an einem ruhigen Abend alles parallel zu erledigen, endet regelmäßig damit, dass niemand mehr sagen kann, welcher Knoten den Fehler eingeschleppt hat.
Ein Blick auf die Erfahrungen anderer schadet ebenfalls nicht. Ob ein SU in der Fläche Ärger macht, steht am Erscheinungstag noch in keinem KB-Artikel, sondern taucht zuerst in den einschlägigen Foren auf. Der monatliche Patch-Tuesday-Thread in r/sysadmin ist dafür nach wie vor die schnellste Quelle. Zum August-Update ist dort bislang nichts aufgelaufen, was gegen einen zügigen Rollout spricht.
Aus dem Juni-Update ist dagegen ein Problem weiterhin offen: In Hybrid-Umgebungen erscheinen in freigegebenen Postfächern sogenannte Wrapper-Nachrichten im Posteingang. Microsoft beschreibt Ursache und Abhilfe in KB5105719. Wer hybrid betreibt und den Effekt noch nicht kennt, liest den Artikel besser vorher.
Was im Herbst passiert
Für Exchange Server SE war der 11. August ein gewöhnlicher Patchday mit einer Funktionsänderung, die man den Anwendern ankündigen sollte. Für Exchange 2016 und 2019 war es der drittletzte.
Der Weg nach vorn ist bekannt und unterschiedlich aufwendig. Von Exchange 2019 aus ist der Umstieg auf SE als In-Place-Upgrade vorgesehen, technisch entspricht das der Installation eines Cumulative Update und ist an einem Wartungsfenster machbar. Von Exchange 2016 aus führt der Weg über eine Neuinstallation daneben und die Verlagerung der Postfächer, wahlweise mit dem Zwischenschritt über 2019. Das ist kein Nachmittagsprojekt: Zertifikate, Empfangs- und Sendeconnectoren, die Einstellungen der virtuellen Verzeichnisse und vor allem die Drittanbieter im Umfeld wollen mitgenommen werden. Backup, Virenschutz, Archivierung und Signaturlösungen haben ihre eigenen Freigabelisten, und die Erfahrung sagt, dass genau dort die Wochen verloren gehen.
Wer diese Planung jetzt aufsetzt, hat bis Oktober noch Luft für ein Testfenster und eine saubere Abstimmung mit den Fachbereichen. Wer im Oktober damit anfängt, plant nicht mehr, sondern verwaltet ein Risiko.