Exchange-Sicherheitsupdates vom September 2026: neun Schwachstellen, Wrapper-Problem behoben, v2 nachgeschoben
Das September-SU schliesst neun Schwachstellen in Exchange SE und 2019 (acht in Exchange 2016), darunter eine Spoofing-Lücke mit CVSS 9.3, und behebt das Wrapper-Problem in Hybrid-Umgebungen. Am 2. Oktober folgte eine v2 mit einer zusätzlichen CVE; dazu kommen drei Known Issues mit Workarounds und ein SettingOverride, der jetzt entfernt werden soll.
Aktueller Stand und alle Builds: Exchange-Buildnummern
Microsoft hat am 8. September 2026 Sicherheitsupdates (SUs) für Exchange Server veröffentlicht. Sie schliessen in Exchange SE und Exchange 2019 neun Schwachstellen, in Exchange 2016 acht. Keine davon war vorab öffentlich bekannt, keine wird laut Security Update Guide aktiv ausgenutzt, und Microsoft stuft alle als Important mit «Exploitation Less Likely» ein. Der höchste CVSS-Wert liegt mit 9.3 aber deutlich über dem des Vormonats. Besonders ist dieser Monat aus drei Gründen: Das SU behebt das seit Juni offene Problem der Wrapper-Nachrichten in freigegebenen Postfächern, es bringt drei neue bzw. fortbestehende Known Issues mit sich, und am 2. Oktober hat Microsoft eine Version 2 nachgeschoben, die eine zusätzliche Schwachstelle schliesst.
Für welche Exchange-Versionen das Update verfügbar ist
Die SUs vom 8. September 2026 stehen für folgende Versionen bereit:
- Exchange Server Subscription Edition (SE) RTM: KB5121608, Build 15.2.2562.49; öffentlich verfügbar.
- Exchange Server 2019 CU15: KB5121609, Build 15.2.1748.51; nur über das Period-2-ESU-Programm.
- Exchange Server 2019 CU14: KB5121610, Build 15.2.1544.46; nur über Period 2 ESU.
- Exchange Server 2016 CU23: KB5121611, Build 15.1.2507.73; nur über Period 2 ESU.
Exchange 2016 und 2019 sind out of support. Die SUs von Mai bis Oktober 2026 erhalten laut Microsoft nur Organisationen, die im Period-2-ESU-Programm eingeschrieben sind. Laut den KB-Artikeln reicht diese Berechtigung bis Oktober 2026. Hinzu kommt der Druck aus Exchange Online: Seit der zweiten Septemberwoche drosselt und blockiert Exchange Online den Hybrid-Mailfluss von Servern unter dem Oktober-2025-Stand, Details im Artikel zum Transport-Enforcement. Exchange Online selbst ist laut Ankündigung bereits geschützt; in Hybrid-Umgebungen braucht trotzdem jeder Exchange-Server das SU, ebenso Maschinen mit den Exchange Management Tools.
Den eigenen Stand können Sie mit der Übersicht der Exchange-Buildnummern abgleichen.
Die Schwachstellen im Überblick
| CVE | Typ | CVSS |
|---|---|---|
| CVE-2026-69356 | Spoofing (Cross-Site-Scripting) | 9.3 |
| CVE-2026-69641 | Elevation of Privilege | 9.1 |
| CVE-2026-69355 | Remote Code Execution | 8.8 |
| CVE-2026-55007 | Remote Code Execution | 8.1 |
| CVE-2026-69380 | Elevation of Privilege | 8.1 |
| CVE-2026-69378 | Denial of Service | 7.5 |
| CVE-2026-69361 | Spoofing (Server-Side Request Forgery) | 6.5 |
| CVE-2026-69375 | Tampering | 6.5 |
| CVE-2026-69382 | Information Disclosure | 5.9 |
CVE-2026-55007 betrifft Exchange 2016 nicht; der Security Update Guide führt dafür nur Exchange SE und 2019 CU14/CU15. Ein Detail zur Dokumentation: In den KB-Artikeln der vier September-SUs fehlt CVE-2026-69380 in der CVE-Liste. Der Security Update Guide nennt für diese CVE jedoch genau die vier September-Builds als Fix (Stand 7. Oktober 2026).
CVE-2026-69356 hat mit CVSS 9.3 den höchsten Wert. Laut Microsoft kann ein nicht authentifizierter Angreifer eine präparierte Kalendereinladung mit einem schädlichen Besprechungslink schicken; öffnet die Empfängerin oder der Empfänger die Besprechung und wählt den Link zum Teilnehmen, wird das Cross-Site-Scripting ausgelöst. Es braucht also eine Benutzerinteraktion, aber kein Konto in der Organisation.
CVE-2026-69380 (Elevation of Privilege, CVSS 8.1) setzt nur ein Konto mit wenig Rechten und ein zugewiesenes Postfach voraus. Laut FAQ im Security Update Guide kann sich ein Angreifer durch Schwächen bei der Prüfung von Anfragen und Identity-Tokens als ein anderer Benutzer ausgeben und die Postfächer aller Exchange-Benutzer übernehmen: Mails lesen, senden und Anhänge herunterladen. Ein einziges kompromittiertes Benutzerkonto genügt als Ausgangspunkt.
CVE-2026-69641 (Elevation of Privilege, CVSS 9.1) führt zum selben Ergebnis, der Übernahme aller Postfächer, setzt aber die Mitgliedschaft in einer hoch privilegierten Rollengruppe voraus.
Bei den beiden Remote-Code-Execution-Lücken ist die Ausgangslage unterschiedlich: CVE-2026-69355 (CVSS 8.8) verlangt ein authentifiziertes Konto mit geringen Rechten, CVE-2026-55007 (CVSS 8.1) lässt sich ohne Anmeldung über einen präparierten Visio-Anhang auslösen, setzt laut Microsoft aber anhaltend knappen Arbeitsspeicher auf dem Zielsystem voraus. Die übrigen vier Lücken: CVE-2026-69378 (DoS durch unkontrollierte Rekursion, ohne Anmeldung), CVE-2026-69361 (SSRF, der Server sendet HTTP-Anfragen an interne oder Loopback-Systeme), CVE-2026-69375 (ein authentifizierter Angreifer kann Dateiinhalte ersetzen) und CVE-2026-69382 (Offenlegung von Anmeldedaten über einen schwachen Kryptoalgorithmus, setzt ein bereits erbeutetes Authentifizierungs-Cookie voraus).
Version 2 vom 2. Oktober: CVE-2026-96940 nachgeliefert
Am 2. Oktober 2026 hat Microsoft «Version 2» der September-SUs veröffentlicht. Laut Ankündigung besteht der einzige Unterschied zur ersten Fassung im zusätzlichen Fix für CVE-2026-96940. Diese Elevation-of-Privilege-Lücke hat CVSS 8.8, ist weder öffentlich bekannt noch ausgenutzt, wird von Microsoft aber als einzige der zehn CVEs mit «Exploitation More Likely» bewertet. Ein authentifizierter Angreifer kann damit auf fremde Postfächer derselben Organisation zugreifen und Mails samt Anhängen lesen. Exchange Online ist serverseitig bereits korrigiert.
| Version | KB | Build v2 |
|---|---|---|
| Exchange SE RTM | KB5129955 | 15.2.2562.53 |
| Exchange 2019 CU15 | KB5129956 | 15.2.1748.53 |
| Exchange 2019 CU14 | KB5129957 | 15.2.1544.48 |
| Exchange 2016 CU23 | KB5129958 | 15.1.2507.75 |
Für die Praxis bedeutet das: Der Fix für CVE-2026-96940 steckt nur in den v2-Builds. Server, auf denen bereits das SU vom 8. September läuft, brauchen zusätzlich v2. Wer erst jetzt patcht, kann direkt v2 installieren, da SUs kumulativ sind. Ob Server mit dem ersten September-SU v2 zwingend installieren müssen, sagen die KB-Artikel nicht ausdrücklich; da die neue CVE nur mit v2 geschlossen wird, ist das die naheliegende Lesart.
Wrapper-Problem behoben: SettingOverride jetzt entfernen
Das seit dem Juni-SU bekannte Problem, dass in Hybrid-Umgebungen Wrapper-Nachrichten im Posteingang freigegebener Postfächer auftauchen, ist mit dem September-SU auf allen vier Versionen behoben. Im August-Artikel stand noch, dass der als Workaround dokumentierte SettingOverride bestehen bleiben kann. Nach der Installation des September-SUs gilt das Gegenteil: Microsoft empfiehlt im zugehörigen Support-Artikel, den Override zu prüfen und zu entfernen.
Get-SettingOverride "DisableBlockSharedAndUserMailboxHeaders"
Remove-SettingOverride "DisableBlockSharedAndUserMailboxHeaders"
Meldet der erste Befehl, dass das Objekt DisableBlockSharedAndUserMailboxHeaders nicht gefunden wurde, ist laut Microsoft nichts weiter zu tun.
Für Exchange SE behebt das SU zusätzlich einen Fehler bei Hybrid-Frei/Gebucht-Abfragen über Microsoft Graph: On-Premises-Benutzer sahen die Belegtzeiten von Exchange-Online-Postfächern um ihren eigenen UTC-Versatz verschoben, ohne Fehlermeldung.
Bekannte Probleme
Veröffentlichte Kalender (.ics) liefern HTTP 500 an Kalender-Apps. Das Problem besteht seit dem August-SU (Exchange SE ab Build 15.2.2562.46 sowie Exchange 2019 und 2016) und ist auch im September-SU und in v2 nicht behoben. Abonnements anonym veröffentlichter Kalender aktualisieren sich nicht mehr; im Browser funktioniert dieselbe URL. Ursache laut Microsoft: Exchange erkennt Clients am User-Agent, Kalender-Apps landen ohne Browser-Kennung in einem Codepfad, den das August-SU deaktiviert hat. Als Workaround beschreibt Microsoft eine URL-Rewrite-Regel auf der Site «Exchange Back End» im IIS, die bei .ics-Anfragen unter /owa/calendar/ den Parameter layout=premium anhängt; dafür muss das IIS-Modul URL Rewrite installiert sein. Die genauen Schritte (über den IIS-Manager oder direkt in der applicationHost.config) stehen im Support-Artikel KB5126672. Einen Termin für den Fix nennt Microsoft nicht (Stand 7. Oktober 2026).
Frei/Gebucht für delegierte Postfächer in Hybrid-Umgebungen (nur Exchange SE). Ist die Verfügbarkeitsabfrage ausschliesslich über die Graph API konfiguriert, schlagen Abfragen für Exchange-Online-Postfächer über delegierten On-Premises-Zugriff fehl. Outlook meldet «Your server location could not be determined», OWA zeigt «No information», in den EWS-Logs erscheint (403) Forbidden. Der dokumentierte Workaround leitet die Abfragen wieder über EWS statt über Graph:
Set-SettingOverride -Identity EnableRouteThroughMSGraphFeature -Parameters "Enabled=False"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
In der Ankündigung zu v2 führt Microsoft dieses Problem unter den behobenen Problemen. Wer den Workaround gesetzt hat, sollte nach der Installation von v2 im Support-Artikel KB5127092 prüfen, ob er zurückgenommen werden soll; eine Anleitung dazu stand dort zum Stand 7. Oktober 2026 noch nicht.
ContentEngine-Deadlock wegen fehlender koreanischer WordBreaker-Dateien (nur Exchange SE). Mit dem September-SU (Build 15.2.2562.49 und v2-Build 15.2.2562.53) werden die Regeldateien für den aktualisierten koreanischen WordBreaker nicht mitinstalliert. Die Folgen: fehlende Suchergebnisse, verzögerte Mailzustellung, Outlook- bzw. MAPI-Clients, die hängen oder die Verbindung verlieren. KB5130098 nennt als betroffen Umgebungen, die Mails mit koreanischsprachigem Inhalt verarbeiten. Das hängt nicht von der Sprache der eigenen Benutzer ab: Nachrichten mit koreanischem Text erreichen auch Organisationen ohne koreanische Korrespondenz, etwa als Spam oder Newsletter. Schweizer Umgebungen sind deshalb nicht von vornherein ausgenommen. Microsoft untersucht das Problem noch; Prüfung und Workaround stehen im nächsten Abschnitt.
Workaround für den WordBreaker-Deadlock
Der Workaround aus KB5130098 ergänzt zwei Regeldateien aus dem Paket von SQL Server 2025 Express RTM. Microsoft knüpft ihn an Bedingungen: Er ist nicht allein wegen der Symptome anzuwenden, sondern nur auf Servern, die alle Prüfkriterien erfüllen und denen beide Dateien fehlen. Der Exchange Health Checker prüft diese Dateien nicht; die Version v26.10.02 vom 2. Oktober 2026 enthält keine entsprechende Prüfung (Stand 9. Oktober 2026). Die Kontrolle erfolgt deshalb manuell.
1. Server prüfen
Das folgende Skript ändert nichts am System. Es liest den Installationspfad aus der Umgebungsvariablen ExchangeInstallPath und gibt die Werte aus, die KB5130098 als Voraussetzung nennt.
$native = Join-Path $env:ExchangeInstallPath 'Bin\Search\Ceres\Native'
$exsetup = Get-Item (Join-Path $env:ExchangeInstallPath 'Bin\ExSetup.exe')
$dll = Get-Item (Join-Path $native 'korwbrkr.dll')
[pscustomobject]@{
ExSetup = $exsetup.VersionInfo.FileVersion
KorwbrkrVersion = $dll.VersionInfo.FileVersion
KorwbrkrBytes = $dll.Length
KorwbrkrSha256 = (Get-FileHash -LiteralPath $dll.FullName -Algorithm SHA256).Hash
KoTokenRule = Test-Path (Join-Path $native 'ko.token.rule.bin')
KoComplexRule = Test-Path (Join-Path $native 'ko.complex.rule.bin')
}
Der Workaround ist nur zulässig, wenn alle Werte passen:
| Wert | Erwartet |
|---|---|
ExSetup | 15.02.2562.049 oder 15.02.2562.053 |
KorwbrkrVersion | 16.0.5194.1000 |
KorwbrkrBytes | 326544 |
KorwbrkrSha256 | 1C6BD8E144BA677EBCC83323AE59DB3881918170F9B3A5189B44611558B92C61 |
KoTokenRule, KoComplexRule | beide False |
Weichen Build, Version oder Hash der DLL ab, verweist Microsoft an den Support. Ist eine der beiden Regeldateien bereits vorhanden, brechen Sie ab und überschreiben nichts.
2. Regeldateien beschaffen
Die Dateien stammen aus SQLEXPR_x64_ENU.exe, dem englischen x64-Paket von SQL Server 2025 Express RTM (Version 17.0.1000.7, 748772024 Bytes). Microsoft empfiehlt, diesen Schritt auf einer Management-Workstation auszuführen, nicht auf dem Exchange-Server. SQL Server wird dabei nicht installiert: Das Paket wird nur entpackt, die Full-Text-MSI nur administrativ extrahiert. Prüfen Sie zuerst Signatur und Hash des Downloads:
Get-AuthenticodeSignature .\SQLEXPR_x64_ENU.exe |
Select-Object Status, SignerCertificate
Get-FileHash .\SQLEXPR_x64_ENU.exe -Algorithm SHA256
Erwartet werden der Status Valid mit einem Microsoft-Zertifikat und der SHA256-Wert 74AA90C11202A5524E769B9BC22531BAEF22D91E9B2D2E8C3CB99E89A65C5297. Danach entpacken und extrahieren:
$work = 'C:\Temp\KoreanRules'
$p = Start-Process .\SQLEXPR_x64_ENU.exe -ArgumentList '/q', "/x:$work\Media" -Wait -PassThru
$p.ExitCode
$msi = "$work\Media\x64\Setup\SQL_FULLTEXT.MSI"
$msiArgs = '/a', $msi, "TARGETDIR=$work\Files", '/qn', '/L*V', "$work\extract.log"
$p = Start-Process msiexec.exe -ArgumentList $msiArgs -Wait -PassThru
$p.ExitCode
Beide Exitcodes müssen 0 sein. Schlägt die Extraktion fehl, sichern Sie extract.log und brechen ab. Anschliessend Grösse und Hash der beiden Dateien prüfen:
Get-ChildItem "$work\Files" -Recurse -Include 'ko.token.rule.bin', 'ko.complex.rule.bin' |
Select-Object FullName, Length,
@{ n = 'SHA256'; e = { (Get-FileHash -LiteralPath $_.FullName -Algorithm SHA256).Hash } }
| Datei | Bytes | SHA256 |
|---|---|---|
ko.token.rule.bin | 56132 | 8F2BD853593913EB8F73DCD4FCAC4216F216A0FF76A4569DF071BE3C36773010 |
ko.complex.rule.bin | 717792 | 0390D1E9A76EF33283025CF8F164430E311584B9535949C4EA1A74B6BB107B87 |
Die Dateien liegen im extrahierten Baum unter ...\MSSQL\Binn\ftcomponents\wordbreakers. Übertragen Sie nur diese beiden Dateien in einen Staging-Ordner auf dem Exchange-Server, keine SQL-Medien und ausdrücklich nicht die korwbrkr.dll aus dem SQL-Paket.
3. Dateien kopieren
$native = Join-Path $env:ExchangeInstallPath 'Bin\Search\Ceres\Native'
$staging = 'C:\Temp\KoStaging'
foreach ($f in 'ko.token.rule.bin', 'ko.complex.rule.bin') {
Copy-Item -LiteralPath (Join-Path $staging $f) -Destination $native
Get-FileHash -LiteralPath (Join-Path $native $f) -Algorithm SHA256
}
Verwenden Sie Copy-Item, nicht Move-Item. Eine kopierte Datei erhält die vererbten Berechtigungen des Zielverzeichnisses, eine verschobene behält die Berechtigungen ihres Ursprungsordners. Die Dateien brauchen die normalen Leserechte von Native. Ersetzen Sie keine weiteren Dateien in diesem Verzeichnis.
4. Search Host Controller neu starten
Restart-Service -Name HostControllerService
Der Neustart unterbricht Suche und Content-Processing auf dem Server vorübergehend; Microsoft sieht dafür ein Wartungsfenster vor. Den Server selbst müssen Sie nicht neu starten. Beenden Sie keine Exchange-Prozesse zwangsweise: Startet der Dienst nicht sauber, ist laut Microsoft der Support der nächste Schritt.
5. Kontrolle
Der Host Controller startet den Prozess NodeRunner.exe der ContentEngine selbst; starten Sie ihn nicht manuell. Ob er läuft, zeigt diese Abfrage:
Get-CimInstance Win32_Process -Filter "Name = 'NodeRunner.exe'" |
Where-Object CommandLine -like '*ContentEngineNode1*' |
Select-Object ProcessId, CreationDate
Erscheint kein Prozess oder beendet er sich wiederholt, bearbeiten Sie keine weiteren Server. Andernfalls prüfen Sie in Outlook im Web mit einem Postfach, dessen aktive Datenbankkopie auf diesem Server liegt, ob neue Mails zugestellt und gefunden werden, auch Mails mit koreanischem Text. Kontrollieren Sie ausserdem den Dienst, der ursprünglich gestört war (Zustellung, Outlook-Verbindung). Den Rückstand im Suchindex beobachten Sie separat: Dass neue Mails gefunden werden, belegt nicht, dass ältere Elemente bereits verarbeitet sind. Weitere Server bearbeiten Sie einzeln und erst nach erfolgreicher Kontrolle des vorherigen.
Installation und Nachbereitung
Microsoft empfiehlt den bekannten Ablauf: mit dem Exchange Health Checker inventarisieren, bei veraltetem Stand mit dem Exchange Update Wizard den Pfad ermitteln, das SU installieren, den Server neu starten und prüfen, ob alle Exchange-Dienste laufen. Der Health Checker zeigt danach auch, ob das SU korrekt installiert ist. Der Security Update Guide führt für die Updates einen erforderlichen Neustart.
Nach der Installation stehen drei Nacharbeiten an:
-
Den Wrapper-SettingOverride
DisableBlockSharedAndUserMailboxHeadersentfernen, falls er gesetzt ist (siehe oben). -
Auf Exchange SE mit dem Prüfskript aus dem WordBreaker-Abschnitt kontrollieren, ob die beiden Regeldateien fehlen, und prüfen, ob das Frei/Gebucht-Problem auftritt. Die Workarounds nur anwenden, wenn die jeweiligen Bedingungen erfüllt sind.
-
Bei veröffentlichten Kalendern mit externen Abonnenten die URL-Rewrite-Regel aus KB5126672 einrichten, falls das noch nicht seit dem August-SU geschehen ist.
Aus dem Juli bleibt zudem die Kontrolle, ob die CVE-2026-42897-Mitigation (M2.1.0) noch aktiv ist; wie Sie sie entfernen, steht im Artikel zum Juli-SU.
Empfohlenes Vorgehen
Installieren Sie auf allen Exchange-Servern und Management-Tools-Maschinen direkt die v2-Builds vom 2. Oktober; Server mit dem SU vom 8. September brauchen v2 für CVE-2026-96940 zusätzlich. Die Spoofing-Lücke mit CVSS 9.3 und die Postfachübernahme über ein Benutzerkonto mit geringen Rechten (CVE-2026-69380) sind Grund genug, nicht auf den nächsten Patchday zu warten. Entfernen Sie danach den Wrapper-Override, prüfen Sie die drei Known Issues und lassen Sie den Health Checker laufen. Die fehlenden WordBreaker-Dateien meldet der Health Checker nicht; dafür ist das Prüfskript aus dem WordBreaker-Abschnitt nötig. Für Exchange 2016 und 2019 endet das ESU-Programm im Oktober 2026; die Migration auf Exchange SE lässt sich nicht weiter verschieben.
Kommentare
Die Kommentare werden von GitHub / Giscus geladen.