Exchange SE SU10V2: Microsoft patcht, Admins reparieren

Wer das September-Sicherheitsupdate für Exchange Server SE installiert hat, hat sich damit womöglich ein neues Problem eingehandelt. Auf dem Server fehlen danach zwei Dateien, und Microsoft nennt als mögliche Folgen fehlende Suchergebnisse, verzögerte Zustellung und hängende Outlook-Verbindungen. Die Neuauflage Exchange SE SU10V2 vom 2. Oktober schließt eine weitere Sicherheitslücke, bringt die beiden Dateien aber nicht mit.

Die Reparatur überlässt Microsoft den Admins. Wer sich an die offizielle Anleitung hält, lädt ein SQL-Server-Paket von rund 714 MB herunter, um zwei Dateien mit zusammen 773.924 Bytes herauszuholen. Frank Carius hat das auf MSXFAQ auseinandergenommen und kommt zu dem Satz: „Das wirkt alles wie mit der heißen Nadel gestrickt.“ Ich habe die Primärquellen nachgelesen und sehe das genauso.

Dieser Artikel sortiert, was passiert ist, wo Microsofts eigene Dokumente sich widersprechen und was Sie jetzt tun sollten. Am Ende steht ein PowerShell-Skript, das den Server prüft und die Reparatur Schritt für Schritt mit Rückfragen durchführt.

Was das Exchange-Sicherheitsupdate vom September 2026 schließt

Am 8. September 2026 hat Microsoft das Sicherheitsupdate SU10 für Exchange Server SE veröffentlicht (KB5121608, Build 15.2.2562.49). Der KB-Artikel nennt acht CVEs. Darunter ist CVE-2026-69356, eine Spoofing-Lücke mit CVSS 9.3: Ein Angreifer ohne Anmeldung schickt eine präparierte Kalendereinladung, und wenn das Opfer den Join-Link anklickt, kann Skriptcode in dessen angemeldeter OWA-Sitzung laufen. Dazu kommt mit CVE-2026-69641 eine Rechteausweitung mit CVSS 9.1. Liegenlassen kann man dieses Update nicht.

Am 2. Oktober folgte SU10V2 (KB5129955, Build 15.2.2562.53). Laut dem Blogpost des Exchange-Teams unterscheidet sich die zweite Fassung von der ersten in genau einer zusätzlichen Lücke: CVE-2026-96940, eine Rechteausweitung mit CVSS 8.8. Ein angemeldeter Angreifer könnte damit auf Postfächer anderer Benutzer derselben Organisation zugreifen und Mails samt Anhängen lesen. Microsoft stuft die Ausnutzung als „Exploitation More Likely“ ein. Angriffe sind laut Microsoft bisher nicht bekannt, die Lücke wurde intern gefunden.

Für Exchange 2016 und 2019 gibt es beide Fassungen nur im ESU-Programm. Den Dateifehler, um den es hier geht, dokumentiert Microsoft nur für Exchange Server SE.

KB5130098: Zwei fehlende Dateien und ein ContentEngine-Deadlock

Die Ursache steht in KB5130098 in einem Satz: Das September-Update installiert die Dateien nicht, die der aktualisierte koreanische WordBreaker braucht. Ein WordBreaker zerlegt Text für den Suchindex in Wörter, für jede Sprache gibt es einen eigenen. Es fehlen ko.token.rule.bin und ko.complex.rule.bin im Verzeichnis Bin\Search\Ceres\Native.

Betroffen sind laut Microsoft Umgebungen, die Mails mit koreanischem Text verarbeiten. Dort kann die ContentEngine in einen Deadlock laufen, also der Teil der Exchange-Suche, der Inhalte verarbeitet. Microsoft nennt drei Symptome: Suchergebnisse fehlen, die Zustellung verzögert sich, und MAPI- oder Outlook-Clients reagieren nicht mehr oder verlieren die Verbindung.

„Koreanisch haben wir nicht“ ist als Entwarnung zu dünn. Microsoft knüpft den Fehler an den Inhalt der Mails und nicht an die Sprache der Benutzer. Ob eine einzelne koreanische Spam-Mail genügt, sagt der KB-Artikel nicht. Ausschließen würde ich es nicht.

Dass der Fehler hierzulande ankommt, legen die Kommentare unter dem Borncity-Beitrag zum September-Update nahe. Am 15. September meldet dort ein Leser „extreme Performanceprobleme“ nach dem Patch, am 23. September beschreibt ein anderer ein zähes Outlook und eine Suche, die nicht mehr funktioniert. Am 30. September verlinkt der erste Leser KB5130098 als Lösung. Carius berichtet von mehreren Kunden mit sporadischen Problemen bei Suche, Versand und Outlook-Verbindungen. Ob jede dieser Meldungen auf die fehlenden Dateien zurückgeht, lässt sich von außen nicht sagen.

Unangenehm ist das Fehlerbild. Der Server fällt nicht aus, er wird unzuverlässig. Wer so etwas sieht, sucht zuerst im Netzwerk, am Client, am Proxy oder in der Virtualisierung, und darauf weist auch Carius hin.

Wo SU10V2 nach heißer Nadel aussieht

Erst die Befunde, dann meine Bewertung.

Microsoft kannte den Fehler vor der Neuauflage. Der Blogpost zum September-Update führt ihn seit dem 24. September als bekanntes Problem. SU10V2 erschien acht Tage später und listet denselben Fehler wieder als bekannt, mit dem Vermerk, er werde in einem künftigen Update behoben. Zwischen erster und zweiter Fassung lagen 24 Tage.

Die Neuauflage tauchte auf, bevor es Informationen gab. Am Vormittag des 2. Oktober wunderten sich Leser bei Borncity über ein Exchange-Update im Microsoft Update Catalog, zu dem sie auf Microsofts Seiten nichts fanden. Das Exchange-Team hat die Frage nach der seltsamen Veröffentlichungsreihenfolge in die FAQ seines Blogposts aufgenommen und antwortet dort, das Update sei „published ahead of its intended schedule“.

Die Dokumente passen nicht zusammen. Der KB-Artikel zu SU10V2 nennt für das Installationspaket denselben SHA256-Wert wie der Artikel zur ersten Fassung, obwohl es zwei verschiedene Dateien mit verschiedenen Builds sind (Stand 10. Oktober). Außerdem führt das Exchange-Team den Free/Busy-Fehler aus KB5127092 in seinem Blogpost unter den behobenen Problemen. Der KB-Artikel zu SU10V2 listet denselben Fehler unter den bekannten Problemen, und KB5127092 selbst nennt weiterhin nur einen Workaround.

Dann der Workaround. Microsoft verlangt, SQL Server 2025 Express herunterzuladen (748.772.024 Bytes), Signatur und Hash zu prüfen, das Paket im Extract-Modus zu entpacken, daraus SQL_FULLTEXT.MSI als administratives Image auszupacken, die zwei Dateien herauszusuchen und wieder die Hashes zu prüfen. Danach geht es auf dem Exchange-Server weiter: Build und DLL prüfen, kopieren, Hashes prüfen, Dienst neu starten. Carius hat nachgemessen, dass das entpackte Paket 1,67 GB belegt. Die beiden gesuchten Dateien machen rund ein Tausendstel des Downloads aus.

Und der HealthChecker, den Microsoft nach jedem Update empfiehlt, hilft hier nicht. In den Änderungen des Release vom 2. Oktober stehen die neue CVE und die neuen Build-Nummern. Eine Prüfung auf die fehlenden Dateien finde ich dort nicht, und Carius schreibt ebenfalls, dass der HealthChecker den Fehler noch nicht erkennt.

Jeder dieser Punkte ist für sich klein. Zusammen lese ich daraus, dass hier ein Paket unter Zeitdruck hinausgeschoben und die Dokumentation hinterhergetragen wurde. Den doppelten Hash halte ich für einen Kopierfehler, belegen kann ich das nicht. Mehr ärgert mich der Workaround. Zwei Dateien von zusammen keinen 800 KB hätte Microsoft als signierten Download oder als Hotfix anbieten können. Stattdessen bekommen Admins eine Anleitung mit Abbruchbedingungen an fast jedem Schritt und dem Hinweis, im Zweifel den Support anzurufen.

Was für Microsofts Vorgehen spricht

Fairerweise: Es gibt gute Gründe, ein Sicherheitsupdate lieber früh als vollständig auszuliefern. CVE-2026-96940 erlaubt den Zugriff auf fremde Postfächer, und Microsoft hält eine Ausnutzung für wahrscheinlich. Wer so eine Lücke kennt, soll den Fix nicht zurückhalten, bis ein Problem im Suchindex gelöst ist. Die fehlenden Dateien nachzuliefern hätte neue Tests gebraucht und den Sicherheitspatch verzögert.

Das Exchange-Team hat außerdem Mitte August erklärt, warum die Schlagzahl gestiegen ist. Microsoft sucht konzernweit mit KI-Werkzeugen nach Schwachstellen, die Teams arbeiten die Funde ab, und seit Mai kam für Exchange jeden Monat ein Update. Sicherheit habe Vorrang vor allem anderen, deshalb lässt auch CU1 auf sich warten.

Auch der umständliche Workaround hat eine Logik. Die Dateien stammen aus einem signierten Microsoft-Paket, und jede Prüfung in der Anleitung verhindert, dass jemand die falsche Datei in ein produktives Exchange kopiert.

Mein Einwand bleibt. Das erklärt die Reihenfolge, die Qualität erklärt es nicht. Wer Admins auffordert, ein Update bei erster Gelegenheit einzuspielen, muss Pakete liefern, die vollständig installieren.

Was das für Kommunen und kleine IT-Abteilungen bedeutet

Ich schreibe das als jemand, der die IT einer Gemeinde betreut. In Verwaltungen dieser Größe gibt es selten einen Exchange-Spezialisten. Das Update läuft nach Feierabend, und wenn am nächsten Morgen Outlook hakt, beginnt die Fehlersuche bei null. Ein Fehler, der nur manchmal auftritt und nach Netzwerk aussieht, kostet dort Tage.

Meine Reihenfolge wäre diese:

  1. SU10V2 trotzdem installieren. Die Sicherheitslücken wiegen schwerer als der Dateifehler, und der lässt sich beheben.
  2. Danach prüfen, ob die beiden Dateien fehlen. Das dauert Sekunden und ändert nichts am System.
  3. Wenn sie fehlen, die Reparatur einplanen. Maßgeblich sind laut Microsoft Build, DLL-Version und die fehlenden Dateien. Symptome allein reichen als Begründung nicht.
  4. Den Neustart des Dienstes in ein Wartungsfenster legen und bei mehreren Servern einzeln vorgehen.
  5. Nach dem Patchday am 13. Oktober erneut prüfen. Ob das nächste Update die Dateien mitbringt und wie es mit bereits kopierten Dateien umgeht, hat Microsoft nicht gesagt.

Skript: fehlende WordBreaker-Dateien prüfen und reparieren

Frank Carius bietet auf MSXFAQ ein Prüfskript und ein ZIP mit den beiden Dateien an. Ich wollte einen Schritt weitergehen und den ganzen Workaround aus KB5130098 in ein Skript packen, das vor jedem Eingriff fragt. Repair-ExchangeKoreanWordBreaker.ps1 arbeitet in neun Schritten:

  1. Exchange-Installation und Build prüfen (nur 15.02.2562.049 und 15.02.2562.053)
  2. Installierte korwbrkr.dll prüfen: Version, Größe, SHA256
  3. Prüfen, ob die beiden Regeldateien fehlen
  4. Regeldateien beschaffen
  5. Beschaffte Dateien gegen Microsofts Hashes prüfen und in einen Staging-Ordner legen
  6. Dateien in das Exchange-Verzeichnis kopieren
  7. Kopien am Zielort verifizieren: SHA256, Größe, vererbte Berechtigungen
  8. Dienst HostControllerService neu starten
  9. Wiederanlauf des ContentEngine-Prozesses kontrollieren

Die Schritte 1 bis 3 lesen nur. Vor dem Download, vor dem Kopieren und vor dem Dienstneustart erklärt das Skript, was es vorhat, und macht ohne ein J nichts. Weicht ein Wert von Microsofts Angaben ab, bricht es ab und ändert nichts – so verlangt es auch der KB-Artikel, der in diesen Fällen an den Support verweist. Ist nur eine der beiden Dateien vorhanden, gilt dasselbe.

Woher die Dateien kommen, wählen Sie selbst. Sie können einen lokalen Ordner angeben, das ZIP von MSXFAQ laden lassen oder den offiziellen Weg über das SQL-Paket gehen, den das Skript dann komplett abwickelt. In allen drei Fällen verwendet es nur Dateien, die in Größe und SHA256 exakt Microsofts Angaben entsprechen. Dem ZIP muss man deshalb nicht blind vertrauen.

Microsoft empfiehlt, Download und Entpacken auf einer Admin-Workstation zu erledigen und nicht auf dem Exchange-Server. Dafür gibt es den Schalter -PrepareOnly.

powershell

# Nur prüfen, nichts ändern (Exit-Code 10 = Server ist betroffen)
.\Repair-ExchangeKoreanWordBreaker.ps1 -CheckOnly

# Prüfen und interaktiv reparieren, die Quelle der Dateien wird abgefragt
.\Repair-ExchangeKoreanWordBreaker.ps1

# Auf der Admin-Workstation: Dateien aus dem ZIP-Archiv von MSXFAQ holen und prüfen
.\Repair-ExchangeKoreanWordBreaker.ps1 -PrepareOnly -Source MSXFAQ

# Auf der Admin-Workstation: Dateien aus dem Microsoft-Paket holen und prüfen
.\Repair-ExchangeKoreanWordBreaker.ps1 -PrepareOnly -Source Microsoft

# Auf dem Exchange-Server: die übertragenen Dateien verwenden
.\Repair-ExchangeKoreanWordBreaker.ps1 -Source Local -SourcePath D:\Transfer\KoreanRules

Gestartet wird in einer Windows PowerShell 5.1 mit Administratorrechten. Jeder Lauf schreibt ein Protokoll nach C:\Temp\KoreanRules\Lauf-<Zeitstempel>\Protokoll.log. Die Meldungen sind absichtlich ohne Umlaute geschrieben, damit das Skript unabhängig von der Dateikodierung läuft.

Das Skript kommt ohne Gewähr. Fangen Sie mit -CheckOnly an und lassen Sie die Reparatur zuerst auf einem einzelnen Server laufen. Die Sollwerte stammen aus KB5130098 mit Stand 6. Oktober. Ändert Microsoft den Artikel oder liefert ein Update die Dateien nach, ist das Skript überholt.

Ein laufender Prozess beweist noch keine Erholung, das betont auch Microsoft. Stellen Sie nach dem Neustart über OWA eine normale Mail und eine mit koreanischem Text zu, suchen Sie danach und behalten Sie den Rückstau der Indizierung im Auge.

Fazit

Das Sicherheitsupdate gehört auf den Server, in der zweiten Fassung. Der Dateifehler ist kein Grund, eine Lücke offen zu lassen, über die jemand fremde Postfächer lesen könnte. Er ist aber ein Grund, nach der Installation ein paar Minuten zu investieren, bevor sich die ersten Kollegen über die Outlook-Suche beschweren.

Von Microsoft erwarte ich mehr als den Hinweis auf ein künftiges Update. Zwei Dateien nachzuliefern kann nicht so schwer sein, und eine Anleitung, die einen SQL-Server-Download voraussetzt, ist für kleine IT-Abteilungen eine Zumutung.

Prüfen Sie Ihren Exchange-Server heute mit -CheckOnly. Wenn die Dateien fehlen, planen Sie die Reparatur für das nächste Wartungsfenster ein. Und wenn Sie einen Supportvertrag haben, machen Sie ein Ticket auf. Je mehr Kunden nachfragen, desto eher bekommt das künftige Update ein Datum.


Quellen:

Nach oben scrollen