IT-News – mars solutions GmbH

PHP Sicherheitslücke PHP2Shell: Updates für alle Webserver

Technischer Support — Wed, 21 Oct 2026 15:16:32 +0000

PHP Sicherheitslücke PHP2Shell: Updates für alle Webserver

Technischer Support
Oktober 21, 2026
17:16

Zwei kritische Schwachstellen im PHP-Kern erlauben es Angreifern, ohne Anmeldung eigenen Code auf Webservern auszuführen. Beide Lücken sind mit 9.2 von 10 Punkten bewertet. Das PHP-Projekt hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, das BSI fordert Betreiber auf, die PHP Sicherheitslücke noch am selben Tag zu schließen. Betroffen sind alle PHP-Installationen, die Webanfragen verarbeiten, also auch Content-Management-Systeme wie WordPress, Drupal oder Joomla, Onlineshops und Eigenentwicklungen.

Das Wichtigste in Kürze

Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 ermöglichen Codeausführung aus der Ferne, ohne Anmeldung und ohne Zutun eines Nutzers.
Betroffen sind PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei Apache mod_php.
Abgesichert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr.
Das BSI hält eine großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich.
Konfigurationsänderungen senken das Risiko nur teilweise. Vollständigen Schutz bietet laut PHP-Projekt nur das Update.

So funktioniert die PHP Sicherheitslücke

Die beiden Lücken werden in Fachkreisen unter dem Namen PHP2Shell zusammengefasst, in Anlehnung an Log4Shell. Sie liegen nicht in einer einzelnen Anwendung, sondern im PHP-Interpreter selbst. Damit ist jede Website betroffen, deren Server PHP in einer verwundbaren Version ausführt.

CVE-2026-109618 betrifft die Behandlung von Speicherengpässen. Läuft PHP bei der Verarbeitung einer Anfrage in sein Speicherlimit, bricht es die Anfrage ab. Laut dem Advisory des PHP-Projekts geschieht das in manchen Fällen, bevor der Speicher der Anfrage vollständig vorbereitet ist. Beim anschließenden Aufräumen arbeitet PHP dann mit ungültigen Daten. Angreifer können den Speicherengpass gezielt auslösen, etwa über präparierte Datei-Uploads im Multipart-Format.

CVE-2026-109619 betrifft Zustände, die eine Anfrage überdauern. Ein Worker-Prozess bearbeitet nacheinander viele Anfragen. Bestimmte Informationen aus einer abgebrochenen Anfrage bleiben erhalten und verweisen auf bereits freigegebenen Speicher. Greift die nächste Anfrage im selben Prozess darauf zu, lässt sich Code einschleusen. Bestätigte Wege führen laut PHP-Projekt über die Funktion session.upload_progress, die in der Standardkonfiguration aktiv ist, und unter PHP 8.5 über fatal_error_backtraces.

Wichtig für IT-Admins

Der Code läuft mit den Rechten des Webserver- bzw. PHP-Worker-Kontos. Was dieses Konto lesen darf, etwa Konfigurationsdateien mit Datenbankzugängen, ist für Angreifer erreichbar.

Zahlen, Daten, Fakten

von 10 Punkten nach CVSS 4.0

0 .2

abgesicherte Versionszweige

der Websites nutzen PHP (W3Techs)

0 ,3 %

Welche PHP-Versionen betroffen sind

Laut den Advisories des PHP-Projekts sind alle Versionen vor den folgenden Ständen verwundbar:

Versionszweig	Abgesicherte Version	Sicherheitsupdates bis
PHP 8.5	8.5.12	31.12.2029
PHP 8.4	8.4.27	31.12.2028
PHP 8.3	8.3.36	31.12.2027
PHP 8.2	8.2.35	31.12.2026
PHP 8.1 und älter	kein offizielles Update	bereits beendet

Das BSI geht davon aus, dass alle bekannten PHP-Versionen mindestens bis zurück zu PHP 5 verwundbar sind. Für die Zweige 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam lediglich Quellcode-Korrekturen für Selbstbauer bereitgestellt. Einige Linux-Distributionen und Anbieter von Langzeit-Support liefern eigene Pakete nach.

Hinweis

Distributionen übernehmen Korrekturen häufig in ihre bestehenden Pakete, ohne die Versionsnummer anzuheben. Ein Ubuntu-System kann also abgesichert sein und trotzdem eine ältere Versionsnummer anzeigen. Maßgeblich sind Paketversion und Changelog, nicht allein die Ausgabe von php -v.

Warum PHP2Shell jetzt eilt

Die Veröffentlichung war ursprünglich unter Embargo geplant. Nachdem die CVE-Nummern am 20. Oktober öffentlich kursierten, zog das PHP-Projekt den Termin vor und kündigte die Updates für den 21. Oktober an. Laut Tenable kursiert bereits Exploit-Code, dessen Wirksamkeit aber nicht unabhängig bestätigt ist. Das BSI meldet bislang keine bestätigten Angriffe, verweist aber auf unbestätigte Berichte über funktionierende Exploits.

BSI-Vizepräsident Thomas Caspers rechnet damit, dass Angreifer die Updates mit KI-gestützten Werkzeugen schnell auswerten und daraus Angriffe ableiten. Das Zeitfenster zwischen Veröffentlichung und erster Ausnutzung schrumpft damit auf wenige Stunden. Wer am Tag der Veröffentlichung nicht aktualisiert, sollte von einem erhöhten Risiko ausgehen.

Hinweise zum Vorgehen für IT-Admins

1

Bestand erfassen

Alle Server mit PHP ermitteln, auch interne Systeme wie Intranet, Ticketsystem oder Warenwirtschaft mit Weboberfläche. Öffentlich erreichbare Systeme zuerst behandeln.

2

Updates einspielen

Auf die abgesicherten Versionen bzw. die korrigierten Distributionspakete aktualisieren. Der Security-Tracker der jeweiligen Distribution zeigt, ob das Paket bereits bereitsteht. Laut PHP-Projekt liefert das Remi-Repository am Veröffentlichungstag noch keine Updates.

3

Dienste neu starten

PHP-FPM, Apache bzw. FrankenPHP neu starten, damit keine Prozesse mit der alten Bibliothek weiterlaufen.

4

Patchstand prüfen

Paketversion und Changelog kontrollieren, nicht nur die Versionsanzeige.

5

Auffälligkeiten beobachten

Exponierte Webserver verstärkt auf ungewöhnliche Prozesse, neue Dateien im Webverzeichnis und auffällige POST-Anfragen prüfen, wie es auch das BSI empfiehlt.

Prüfbefehle für Debian und Ubuntu (Beispiel PHP 8.3):

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

Für RHEL, AlmaLinux und Rocky Linux:

rpm -qa 'php*' | sort
rpm -q --changelog php-fpm | head -5

Ob noch Prozesse mit der alten, inzwischen ersetzten Bibliothek laufen, zeigt diese Abfrage. Eine leere Ausgabe bedeutet, dass alle Prozesse neu gestartet wurden:

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Übergangsmaßnahmen bis zum PHP-Update

Lässt sich ein System nicht sofort aktualisieren, nennt das PHP-Projekt Maßnahmen, die das Risiko verringern. Keine davon schließt die Lücken vollständig.

session.upload_progress.enabled = 0 administrativ in der php.ini oder im FPM-Pool setzen und alle Worker neu starten. Über ini_set() oder .user.ini wirkt die Einstellung nicht.
Unter PHP 8.5 zusätzlich fatal_error_backtraces = 0 administrativ setzen.
Multipart-Anfragen am Webserver blockieren, wenn die Anwendung keine Datei-Uploads benötigt.
post_max_size begrenzen: laut PHP-Projekt 8 MB ohne Uploads, 32 MB mit Uploads.
Einstellungen, die pro Anfrage gesetzt werden (php_value in .htaccess, PHP_VALUE vom Webserver), in die zentrale Konfiguration verlagern.

Wichtige Hinweise

Das Unterdrücken von Fehlermeldungen über error_reporting oder display_errors schützt laut PHP-Projekt nicht. Prozessgrenzen über RLIMIT_AS oder RLIMIT_DATA lösen den fehlerhaften Programmpfad sogar aus. Das CERT-EU empfiehlt laut Tenable, aus dem Internet erreichbare Anwendungen bis zum Update vom öffentlichen Netz zu trennen. Cloudflare hat Filterregeln ausgerollt, bezeichnet sie aber selbst nur als Überbrückung.

Bedeutung für Geschäftsführung und Entscheider

PHP ist die Grundlage eines großen Teils aller Websites. Betroffen sind damit nicht nur IT-Unternehmen, sondern jede Organisation mit Website, Onlineshop, Bewerberportal oder Kundenportal. Ein erfolgreicher Angriff verschafft Zugriff auf den Webserver und häufig auf die angebundene Datenbank mit Kunden-, Bestell- oder Bewerberdaten. Sind personenbezogene Daten betroffen, greift die Meldepflicht nach DSGVO innerhalb von 72 Stunden.

Der Aufwand für das Update selbst ist bei aktuellen Systemen gering und in der Regel in kurzer Zeit erledigt. Schwieriger wird es bei Systemen mit PHP 8.1 oder älter. Hier fehlt ein reguläres Update, eine Umstellung auf eine unterstützte Version ist ein eigenes Vorhaben. Bis dahin ist zu entscheiden, ob solche Systeme vorübergehend vom Netz gehen.

Liegt die Website bei einem Hoster oder einer Agentur, ist zu klären, wer für das PHP-Update zuständig ist und bis wann es erfolgt. Für die Geschäftsführung ergibt sich daraus eine konkrete Frage an IT und Dienstleister: Welche Systeme laufen mit PHP, und sind sie heute aktualisiert worden? Zusätzlich lohnt der Blick auf das Supportende von PHP 8.2 am 31. Dezember 2026.

PHP2Shell zeigt, wie wichtig eine klare Zuständigkeit für Updates ist. Wer welche Systeme in welcher Frist aktualisiert und den Patchstand dokumentiert, sollte vor dem nächsten Notfall feststehen. Wer das nicht intern abdecken kann, kann diese Aufgabe an einen IT-Dienstleister übergeben, etwa im Rahmen von Full Managed-IT.

FAQ zur PHP Sicherheitslücke

Ist meine Website betroffen, wenn sie bei einem Hoster liegt?

Ja, das ist möglich. Entscheidend ist die PHP-Version auf dem Server, nicht der Standort. Bei Managed Hosting spielt in der Regel der Hoster das Update ein, bei eigenen Servern oder virtuellen Maschinen der Betreiber selbst. Klären Sie die Zuständigkeit und lassen Sie sich den Patchstand bestätigen.

Reicht es, PHP-Einstellungen zu ändern?

Nein. Die Übergangsmaßnahmen decken nur bekannte Angriffswege ab. Das PHP-Projekt stellt klar, dass es keine vollständige Absicherung über die Konfiguration gibt.

Was gilt für PHP 8.1 und ältere Versionen?

Diese Versionen erhalten vom PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 stehen Quellcode-Korrekturen bereit, einige Distributionen und Langzeit-Support-Anbieter liefern eigene Pakete. Dauerhaft hilft nur die Umstellung auf eine unterstützte Version.

Wird PHP2Shell bereits ausgenutzt?

Bestätigte Angriffe meldete das BSI am 21. Oktober 2026 noch nicht, es gibt jedoch Berichte über funktionierende Exploits. Das BSI rechnet mit einer breiten Ausnutzung innerhalb weniger Stunden nach den Updates.

Woran erkenne ich, ob das Update wirkt?

An der Paketversion und am Changelog des PHP-Pakets, in dem die CVE-Nummern genannt sein sollten. Zusätzlich müssen alle PHP-Prozesse neu gestartet sein.

Fazit

PHP2Shell betrifft keine Randanwendung, sondern die technische Grundlage eines großen Teils aller Websites. Zwei kritische Lücken, ein vorzeitig bekannt gewordener Fehler und die Erwartung des BSI, dass Angriffe innerhalb von Stunden folgen, lassen keinen Spielraum für den nächsten regulären Wartungstermin. Das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. die korrigierten Distributionspakete hat Vorrang vor allen Übergangslösungen. Systeme mit PHP 8.1 oder älter gehören auf die Liste der Altlasten, die jetzt nicht länger warten können.

Weitere interessante Beiträge

IT-News

Druckprobleme nach KB5120708: .NET-Update stoppt Druck und PDF-Export

27. August 2026

Zum Blogbeitrag

IT-News

Exchange-Ausfälle nach dem Oktober-Patchday

19. Oktober 2026

Zum Blogbeitrag

IT-News

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

5. August 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag PHP Sicherheitslücke PHP2Shell: Updates für alle Webserver erschien zuerst auf mars solutions GmbH.

Exchange-Ausfälle nach dem Oktober-Patchday

Technischer Support — Mon, 19 Oct 2026 09:50:55 +0000

Exchange-Ausfälle nach dem Oktober-Patchday

Technischer Support
Oktober 19, 2026
11:50

Am Patchday vom 13. Oktober 2026 hat Microsoft wie gewohnt Sicherheitsupdates für alle unterstützten Windows-Server-Versionen verteilt. Zwei Tage später häuften sich die Meldungen: Exchange-Server stellten rund einen Tag nach der Installation den Dienst ein. Postfächer waren nicht mehr erreichbar, E-Mails blieben in den Warteschlangen hängen.

Microsoft hat das Problem bestätigt, ein Registry-Eintrag schafft vorerst Abhilfe. Was genau passiert ist, wie der Workaround funktioniert und was der Fall über einen verlässlichen IT-Betrieb verrät, lesen Sie hier.

Das Wichtigste in Kürze

Die Windows-Server-Updates vom 13. Oktober 2026 (KB5126646, KB5126655, KB5126651, KB5126868) führen auf Exchange-Servern nach rund 24 Stunden zu Ausfällen
Betroffen sind Exchange Server 2016, 2019 und Subscription Edition im eigenen Rechenzentrum; die Exchange-Updates selbst sind nicht der Auslöser
Ursache ist ein neues Limit in der Windows-Komponente RPC Endpoint Mapper, das auf Exchange-Servern nach etwa einem Tag erreicht wird
Microsoft hat einen Registry-Eintrag als vorübergehenden Workaround freigegeben; die Windows-Updates sollen nicht deinstalliert werden
Der Fall zeigt, wie wichtig gestaffelte Updates, funktionsnahes Monitoring und klare Zuständigkeiten sind

Was nach dem Oktober-Patchday passiert ist

Die ersten Meldungen kamen am 15. Oktober 2026. Administratoren berichteten, dass ihre Exchange-Server etwa 22 bis 24 Stunden nach der Installation der Windows-Updates die Verbindung zu den Postfachdatenbanken verloren.

Benutzer konnten sich nicht mehr anmelden, Outlook im Web funktionierte nicht mehr und E-Mails blieben in den Warteschlangen hängen, bis der Mailfluss vollständig zum Stillstand kam.

Das Kritische daran: Im Exchange Admin Center wurden die Datenbanken weiterhin als verbunden angezeigt. Wer nur auf diese Ansicht schaute, sah also kein Problem. Im Anwendungsprotokoll tauchte dagegen das Ereignis 1006 mit der Meldung „MapiExceptionMdbOffline“ auf. In einigen Umgebungen mit Database Availability Groups erreichten die Mitglieder zudem kein Quorum mehr. Ein Neustart des Servers half – allerdings nur bis zum nächsten Tag.

Welche Systeme betroffen sind

Betroffen sind Exchange Server 2016, Exchange Server 2019 und die Exchange Server Subscription Edition (SE) im eigenen Rechenzentrum, sofern auf dem Server eines der folgenden Windows-Updates installiert ist:

Windows Server	Update vom 13.10.2026
Windows Server 2025	KB5126646
Windows Server 2022	KB5126655
Windows Server 2019	KB5126651
Windows Server 2016	KB5126868

Wichtig: Die Exchange-Sicherheitsupdates vom Oktober müssen dafür nicht installiert sein. Der Fehler entsteht allein durch das Windows-Update. Ob auch Exchange Online betroffen war, ist nicht bestätigt. Medienberichten zufolge wird der Zusammenhang mit einer zeitgleichen Störung vermutet.

Ursache und Workaround

Microsoft hat das Problem am 15. Oktober bestätigt – die offizielle Stellungnahme gibt es hier.

Für den Workaround kursieren zwei Werte: 65536, den Microsoft nennt und 16777215, den unter anderem ein verbreitetes PowerShell-Skript setzt.

Der Workaround von Microsoft

Deinstallieren Sie die Windows-Server-Updates vom Oktober 2026 nicht.
Führen Sie auf dem Exchange-Server in einer Eingabeaufforderung mit Administratorrechten folgenden Befehl aus:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Starten Sie den Server neu.
Beobachten Sie die Umgebung nach dem Neustart und prüfen Sie, ob das Problem erneut auftritt. Falls ja, erhöhen Sie den Grenzwert. In allen Kundenfällen, die wir bisher betreut haben, hat dieses Vorgehen das Problem gelöst.

65536 reicht in der Regel aus: Der Zähler steigt nach Beobachtungen von Administratoren annähernd gleichmäßig. Wird die alte Grenze von 512 nach rund einem Tag erreicht, hält der neue Wert rechnerisch etwa drei Monate, also deutlich über den nächsten Patchday hinaus, dessen Neustart den Zähler zurücksetzt
Höher ist nicht automatisch besser: Das neue Limit soll vermutlich eine Überlastung des RPC Endpoint Mappers verhindern. Je höher der Wert, desto stärker wird dieser Schutz wieder aufgeweicht. Bestätigt hat Microsoft diesen Zusammenhang bislang nicht
Ohne Neustart keine Wirkung: Der Eintrag greift erst nach einem Neustart des Servers. Ein Neustart einzelner Dienste genügt nicht
Ereignis 1006 im Blick behalten: Treten trotz Eintrag und Neustart erneut Fehler auf, den Wert gezielt erhöhen, statt ihn pauschal auf das Maximum zu setzen

Die Empfehlung: Mit dem von Microsoft genannten Wert starten, die Server beobachten und nur bei erneuten Ausfällen nachjustieren.

Was der Fall über den IT-Betrieb verrät

Fehlerhafte Updates gibt es immer wieder, auch bei sorgfältig arbeitenden Herstellern – zuletzt etwa beim .NET-Update, das Druck und PDF-Export stoppte. Spannend an diesem Fall ist weniger der Fehler selbst als die Frage, wie gut ein Unternehmen darauf vorbereitet ist. Vier Grundsätze lassen sich daraus ableiten, ganz gleich, ob die IT intern oder von einem Dienstleister betrieben wird.

1

Updates brauchen eine Testphase

Der Fehler trat erst nach rund 24 Stunden auf. Wer Updates direkt nach dem Patchday auf allen Servern gleichzeitig einspielt, bemerkt so ein Problem erst, wenn alles steht. Eine gestaffelte Verteilung, bei der zunächst ein Teil der Systeme aktualisiert und einige Tage beobachtet wird, hätte den Schaden deutlich begrenzt. Sicherheitsupdates sollen trotzdem zügig installiert werden – ein festgelegter Patch-Prozess mit klaren Ringen und Zeitfenstern bringt beides zusammen.

2

Monitoring muss genauer hinschauen als die Konsole

Die Datenbanken galten in der Verwaltungsoberfläche als verbunden, obwohl nichts mehr ging. Ein Monitoring, das nur prüft, ob ein Dienst läuft, hätte hier nicht angeschlagen. Aussagekräftiger sind Prüfungen, die die tatsächliche Funktion messen: wachsende Mail-Warteschlangen, bestimmte Ereignis-IDs im Protokoll oder Testnachrichten, die regelmäßig durch das System laufen.

3

Wissen aus der Community nutzen

Die entscheidenden Hinweise zu Ursache und Workaround kamen nicht aus offiziellen Mitteilungen, sondern aus Blogs, Foren und Kommentarspalten. Wer diese Quellen nach jedem Patchday aufmerksam verfolgt, ist oft einen Tag schneller als die offizielle Dokumentation. Im Tagesgeschäft fehlt dafür in vielen IT-Abteilungen schlicht die Zeit.

4

Dokumentation und Rückwege planen

Ein Registry-Workaround ist schnell gesetzt und ebenso schnell vergessen. Damit er beim nächsten Update nicht für Verwirrung sorgt, gehört er dokumentiert: auf welchen Servern, mit welchem Wert, ab wann. Genauso wichtig ist ein vorher getesteter Weg zurück, falls ein Update zurückgenommen werden muss, etwa über aktuelle Backups oder Snapshots.

Empfehlungen für IT-Admins

Wer Exchange im eigenen Haus betreibt, sollte jetzt die folgenden Punkte prüfen. Dass ungepatchte Exchange-Server keine Alternative sind, zeigt der Beitrag zur Exchange-Sicherheitslücke CVE-2026-62911.

Updatestand prüfen: Ist auf den Exchange-Servern eines der Oktober-Updates KB5126646, KB5126655, KB5126651 oder KB5126868 installiert?
Workaround setzen: Den Registry-Eintrag EpmapSavedContextCap anlegen und die Server danach neu starten, bei mehreren Servern nacheinander
Update nicht deinstallieren: Microsoft rät ausdrücklich davon ab, weil das Update Sicherheitslücken schließt
Funktion überwachen: Ereignis 1006 im Anwendungsprotokoll und die Länge der Mail-Warteschlangen im Blick behalten, nicht nur den Dienststatus
Änderung dokumentieren: Auf welchen Servern, mit welchem Wert und ab wann der Eintrag gesetzt wurde
Microsoft-Hinweise verfolgen: Sobald ein Korrekturupdate erscheint, den Workaround prüfen und gegebenenfalls zurücknehmen
Patch-Ringe einrichten: Künftige Updates zuerst auf einem Teil der Systeme einspielen und einige Tage beobachten

Wo Full Managed IT ansetzt

Die genannten Grundsätze sind keine Geheimnisse. Sie scheitern in der Praxis nicht am Wissen, sondern an der Kapazität. Gerade in mittelständischen Unternehmen kümmern sich oft ein oder zwei Personen um die gesamte IT, vom Drucker bis zum Exchange-Server.
Ein Patch-Prozess mit Testringen, ein feingliedriges Monitoring und das tägliche Verfolgen von Fachquellen lassen sich daneben kaum dauerhaft leisten.

Bei einem Full-Managed-IT-Modell liegen genau diese Aufgaben bei einem Team, das viele Umgebungen gleichzeitig betreut. Das hat ganz praktische Folgen:

Erfahrung aus vielen Umgebungen: Tritt ein Fehler bei einem Kunden auf, ist er für alle anderen sofort bekannt. Updates können bei Bedarf zurückgehalten werden, bevor sie Schaden anrichten
Feste Abläufe statt Einzelentscheidungen: Patch-Ringe, Wartungsfenster und Freigaben sind vorab festgelegt. Ein Update wie dieses landet nicht ungeprüft auf allen Systemen gleichzeitig
Überwachung rund um die Uhr: Wachsende Warteschlangen fallen auch nachts oder am Wochenende auf, also genau dann, wenn ein Fehler wie dieser 24 Stunden nach einem Update zuschlägt
Klare Verantwortung: Wer zuständig ist, steht fest. Im Ernstfall muss niemand erst klären, wer sich um den Server kümmert

Full Managed IT verhindert keine fehlerhaften Updates. Es sorgt aber dafür, dass ein solcher Fehler früh bemerkt, sauber eingegrenzt und dokumentiert behoben wird. Ob ein Unternehmen das selbst organisiert oder auslagert, hängt von Größe, Ressourcen und Anspruch ab. Die Fragen, die dieser Vorfall aufwirft, sollte sich aber jedes Unternehmen stellen: Wie schnell hätten wir den Ausfall bemerkt? Und wer hätte ihn behoben?

FAQ zu den Exchange-Problemen nach dem Oktober-Patchday

Welche Updates verursachen die Exchange-Probleme?

Microsoft nennt die Windows-Server-Updates vom 13. Oktober 2026 als vermutliche Ursache: KB5126646 für Windows Server 2025, KB5126655 für Windows Server 2022, KB5126651 für Windows Server 2019 und KB5126868 für Windows Server 2016.

Welche Exchange-Versionen sind betroffen?

Exchange Server 2016, Exchange Server 2019 und die Subscription Edition im eigenen Rechenzentrum. Die Exchange-Updates vom Oktober müssen dafür nicht installiert sein. Ob auch Exchange Online betroffen war, ist nicht bestätigt.

Woran erkenne ich, dass mein Server betroffen ist?

Etwa einen Tag nach der Installation verlieren die Postfachdatenbanken ihre Verbindung. Im Anwendungsprotokoll erscheint das Ereignis 1006 mit der Meldung MapiExceptionMdbOffline, Outlook im Web funktioniert nicht mehr und die Mail-Warteschlangen wachsen. Im Exchange Admin Center werden die Datenbanken trotzdem als verbunden angezeigt.

Sollte ich das Windows-Update deinstallieren?

Nein. Microsoft rät ausdrücklich davon ab, weil das Update Sicherheitslücken schließt. Stattdessen wird der Registry-Eintrag EpmapSavedContextCap unter HKLM\SOFTWARE\Microsoft\Rpc gesetzt und der Server anschließend neu gestartet.

Ist der Registry-Eintrag eine dauerhafte Lösung?

Nein. Microsoft bezeichnet ihn als vorübergehende Abhilfe. Einige Administratoren mussten einen höheren Wert setzen. Sobald Microsoft ein Korrekturupdate veröffentlicht, sollte der Eintrag geprüft und gegebenenfalls zurückgenommen werden.

Hätte sich der Ausfall verhindern lassen?

Den Fehler im Update selbst nicht. Seine Auswirkungen lassen sich aber deutlich begrenzen: mit gestaffelten Updates, die zunächst nur auf einem Teil der Systeme laufen, und mit einem Monitoring, das die tatsächliche Funktion von Exchange prüft und nicht nur den Dienststatus.

Fazit

Die Windows-Updates vom Oktober 2026 haben Exchange-Server in vielen Unternehmen lahmgelegt. Mit dem Registry-Workaround gibt es eine von Microsoft gestützte Übergangslösung, die endgültige Korrektur steht noch aus. Wer Exchange im eigenen Haus betreibt, sollte prüfen, ob die betroffenen Updates installiert sind, den Workaround gegebenenfalls umsetzen und die weiteren Mitteilungen von Microsoft verfolgen.

Über den konkreten Fall hinaus lohnt sich ein Blick auf den eigenen Patch- und Überwachungsprozess. Der nächste fehlerhafte Patch kommt bestimmt, und dann entscheidet die Vorbereitung darüber, ob daraus ein kurzer Hinweis oder ein ganzer Tag ohne E-Mail wird.

Weitere interessante Beiträge

IT-News

Revolut Datenleck: 680 Kunden nach gefälschter Behördenanfrage gehackt

17. September 2026

Zum Blogbeitrag

IT-News

Druckprobleme nach KB5120708: .NET-Update stoppt Druck und PDF-Export

27. August 2026

Zum Blogbeitrag

IT-News

Exchange Server Sicherheitsupdate: CVE-2026-96940 öffnet fremde Postfächer

5. Oktober 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Exchange-Ausfälle nach dem Oktober-Patchday erschien zuerst auf mars solutions GmbH.

Patchday Oktober 2026: Outlook-Lücken im Vorschaufenster und ein aktiver Zero-Day

Technischer Support — Wed, 14 Oct 2026 13:28:00 +0000

Patchday Oktober 2026: Outlook-Lücken im Vorschaufenster und ein aktiver Zero-Day

Technischer Support
Oktober 14, 2026
15:28

Am 13. Oktober 2026 hat Microsoft mehr als 1.400 Schwachstellen geschlossen, rund 70 davon kritisch. Eine Lücke in der Windows Shell wird bereits aktiv ausgenutzt, und fünf kritische Outlook-Lücken lassen sich schon dann ausnutzen, wenn eine E-Mail nur im Lesebereich angezeigt wird. Dazu kommen Supportenden für mehrere Windows-Versionen. Dieser Beitrag zeigt, was jetzt Vorrang hat, und zeigt, warum ein Patchday dieser Größenordnung vor allem eine Frage der Organisation ist.

Das Wichtigste in Kürze

Der Patchday Oktober 2026 schließt mehr als 1.400 Schwachstellen, davon rund 70 kritisch.
Aktiv ausgenutzt wird CVE-2026-96951 in der Windows Shell (CVSS 8.8): Die Lücke umgeht die Mark-of-the-Web-Warnung bei heruntergeladenen Dateien. Die US-Behörde CISA hat sie am 13. Oktober in ihren Katalog ausgenutzter Schwachstellen aufgenommen.
Fünf kritische Outlook-Lücken mit CVSS 9.8 führen Code bereits beim Anzeigen einer Nachricht im Vorschaufenster aus, ohne Klick des Empfängers.
Für Exchange Server (CVE-2026-70571) und Active Directory (CVE-2026-70229) stuft Microsoft eine Ausnutzung als wahrscheinlich ein.
Windows 11 24H2 Home/Pro erhält diesen Monat sein letztes Update, Windows Server 2022 verlässt den Mainstream-Support.

Umfang des Patchdays Oktober 2026

Nach dem Rekord-Patchday im September legt der Oktober noch einmal deutlich zu: 1.413 Schwachstellen umfasst der Patchday, darunter rund 70 kritische, fast alle übrigen sind als wichtig eingestuft. Zum Vergleich: Für den September zählt Microsoft inzwischen 999 Einträge.

Fast 60 Lücken lassen sich über das Netzwerk ohne Anmeldung und ohne Zutun eines Nutzers ausnutzen, darunter der Windows DHCP Server (CVE-2026-96934), zwei Lücken in Microsoft QUIC (CVE-2026-100219, CVE-2026-105016) und die Windows-Textdarstellung (CVE-2026-97814) – alle mit CVSS 9.8.

Microsoft gruppiert die Einträge in diesem Monat zusätzlich in sogenannte Risk Cohorts, also Gruppen mit gemeinsamen Prüffragen. Allein die Gruppe für Office und Mail-Clients umfasst 135 CVEs. Das ist keine offizielle Schweregrad-Kategorie, hilft aber bei der Frage, welche Systeme gemeinsam betrachtet werden sollten.

Zahlen zum Patchday Oktober 2026

1.413 geschlossene Schwachstellen, davon rund 70 kritisch
1 aktiv ausgenutzter Zero-Day mit CVSS 8.8
5 kritische Outlook-Lücken mit CVSS 9.8, ausnutzbar über das Vorschaufenster
fast 60 Lücken ohne Anmeldung und ohne Nutzerinteraktion über das Netzwerk angreifbar

Zero-Day in der Windows Shell

Die aktiv ausgenutzte Lücke CVE-2026-96951 betrifft die Windows Shell. Über eine Command Injection umgehen Angreifer die Mark-of-the-Web-Prüfung. Das ist der Mechanismus, der Dateien aus dem Internet kennzeichnet und vor dem Öffnen eine Sicherheitswarnung auslöst. Fällt diese Warnung weg, wirkt eine präparierte Datei aus einer E-Mail oder einem Download wie eine harmlose lokale Datei.

Der Nutzer muss die Datei öffnen oder einem Link folgen. Das klingt nach einer Hürde, ist in der Praxis aber genau der Schritt, auf den Phishing-Kampagnen ausgelegt sind. Die fehlende Warnung nimmt den Mitarbeitenden die letzte Gelegenheit, misstrauisch zu werden.

Vorab öffentlich bekannt, aber bislang nicht ausgenutzt, ist außerdem CVE-2026-108398 im .NET Framework (CVSS 8.8). Sie erlaubt angemeldeten Angreifern, die Anwendungssteuerung WDAC zu umgehen und Code in einem geschützten Prozess auszuführen.

Outlook: Gefahr schon im Lesebereich

Der zweite Schwerpunkt liegt bei Outlook. Fünf kritische Lücken mit CVSS 9.8 lösen Codeausführung bereits dann aus, wenn eine präparierte Nachricht im Vorschaufenster angezeigt wird. Der Empfänger muss die E-Mail weder öffnen noch einen Anhang anklicken.

CVE	Art der Lücke	CVSS
CVE-2026-70242	Heap-Überlauf	9.8
CVE-2026-70291	Heap-Überlauf	9.8
CVE-2026-97016	Heap-Überlauf	9.8
CVE-2026-88156	Stack-Überlauf	9.8
CVE-2026-97749	Double Free	9.8

Ähnlich gelagert ist CVE-2026-70300 in Word: Ein präpariertes WordPerfect-Dokument mit verknüpfter Grafik führt ebenfalls bei der Anzeige im Vorschaufenster Code aus. Laut Microsoft ist bislang keine dieser Lücken ausgenutzt worden. Für Office LTSC für Mac 2021 und 2024 stehen einzelne Updates (unter anderem zu CVE-2026-70291 und CVE-2026-88156) noch aus.

Wichtig für IT-Admins

Bei Lücken im Vorschaufenster hilft keine Schulung. Der Empfänger tut nichts Falsches, die Mail muss lediglich im Posteingang erscheinen.
Schutz bieten hier ausschließlich das Update selbst und eine vorgelagerte E-Mail-Filterung.

Exchange, Active Directory und weitere Serverdienste

Für Unternehmen mit eigener Serverlandschaft sind die folgenden Einträge relevant. Für die ersten beiden, Exchange und Active Directory, hält Microsoft eine Ausnutzung für wahrscheinlicher („Exploitation More Likely“).

CVE	Komponente	Typ	CVSS
CVE-2026-70571	Exchange Server	Remotecodeausführung über präparierte E-Mail	8.1
CVE-2026-70229	Active Directory Domain Services	Remotecodeausführung	8.1
CVE-2026-102866	SharePoint Server	Token-Fälschung, Identitätsübernahme	8.1
CVE-2026-102214	Hyper-V	Ausbruch aus der Gast-VM	8.8
CVE-2026-70147	PostScript-Druckertreiber	Remotecodeausführung	9.8

Auffällig sind zudem zwei Lücken im Network Policy Server (CVE-2026-100222 und CVE-2026-85806), die zwar mit CVSS 9.8 bewertet, von Microsoft aber nur als „wichtig“ eingestuft sind. Wer NPS etwa für WLAN- oder VPN-Authentifizierung einsetzt, sollte sich nicht allein auf die Einstufung des Herstellers verlassen.

Mehrere kritische Lücken in Cloud-Diensten wie Bookings, Dataverse und Azure App Service hat Microsoft bereits serverseitig behoben. Hier ist kein Handeln nötig.

Supportende: Diese Versionen fallen heraus

Neben den Sicherheitsupdates markiert der Oktober mehrere Lebenszyklus-Termine:

Windows 11 24H2 Home und Pro sowie Windows 10 Enterprise LTSB 2016 erhalten ihr letztes Update
Windows 11 23H2 Enterprise und Education werden am 10. November 2026 zum letzten Mal versorgt
Windows Server 2022 verlässt den Mainstream-Support, Sicherheitsupdates gibt es im erweiterten Support bis Oktober 2031
Windows 11 25H2 Home und Pro werden bis Oktober 2027 versorgt

Geräte, die auf einer auslaufenden Version stehen bleiben, bekommen ab dem nächsten Patchday keine Sicherheitsupdates mehr. Das ist kein abstraktes Risiko: Jede künftige Lücke bleibt auf diesen Geräten dauerhaft offen.

So gehen Sie beim Patchen vor

1

Zero-Day zuerst

Das Windows-Update gegen CVE-2026-96951 auf allen Clients verteilen.

2

Office direkt danach

Die Outlook- und Word-Lücken wirken ohne Klick, die Updates sollten nicht auf den nächsten Wartungstermin warten.

3

Exchange und Domänencontroller einplanen

CVE-2026-70571 und CVE-2026-70229 früh angehen, aber mit Testphase.

4

Testring nutzen

Eine repräsentative Gruppe vorab versorgen und beobachten. Dass das kein Formalismus ist, zeigen die Exchange-Ausfälle nach den Oktober-Updates, die erst rund einen Tag nach der Installation auftraten.

5

Versionsstände prüfen

Geräte auf Windows 11 24H2 Home/Pro identifizieren und das Upgrade auf 25H2 planen.

6

Erfolg messen

Installationsquote auswerten und Nachzügler gezielt nachziehen.

Was dieser Patchday über den IT-Betrieb verrät

Mehr als 1.400 Einträge in einem Monat lassen sich nicht mehr Stück für Stück lesen und bewerten. Der Oktober zeigt deutlich, dass sich Sicherheit nicht am einzelnen Update entscheidet, sondern daran, wie der Betrieb rund um die Updates organisiert ist. Genau hier liegen die Stärken eines vollständig gemanagten IT-Betriebs – unabhängig davon, ob er intern oder durch einen Dienstleister erbracht wird.

Wissen, was im Haus läuft: Die Prioritäten dieses Monats hängen davon ab, ob ein Unternehmen Exchange on-premises betreibt, NPS für das WLAN nutzt oder noch Geräte auf Windows 11 24H2 hat. Mit einem laufend aktuellen Inventar ist die Frage „Sind wir betroffen?" in Minuten beantwortet statt in Tagen.
Priorisieren nach Ausnutzbarkeit: Wer Herstellerhinweise, CISA-Meldungen und die eigene Umgebung zusammen betrachtet, erkennt schnell, dass hier Zero-Day und Outlook-Vorschaufenster vorgehen. Diese Bewertung gehört zu einem festen Prozess, nicht zu einer Einzelentscheidung unter Zeitdruck.
Testen, bevor es alle trifft: Die Exchange-Probleme nach den Oktober-Updates traten erst nach rund 24 Stunden auf. Testgruppen, Rollout-Wellen und ein Rückweg sind in einem gemanagten Betrieb von vornherein festgelegt.
Den Lebenszyklus im Blick behalten: Werden Versionsstände zentral verwaltet, ist der Wechsel von 24H2 auf 25H2 ein geplanter Schritt und kein Nachzügler-Projekt, das erst auffällt, wenn keine Updates mehr kommen.
Klare Zuständigkeit: Es ist eindeutig geregelt, wer am Patchday handelt, wer Ausnahmen genehmigt und wer prüft, ob alle Geräte versorgt sind. Wird die IT nebenher betreut, bleibt ein Patchday wie dieser im Zweifel liegen - nicht aus Nachlässigkeit, sondern weil das Tagesgeschäft Vorrang hat.
Mehrere Schutzschichten zusammen denken: Ein Betrieb, der Patchmanagement, E-Mail-Filterung, Endpoint-Schutz und Rechtevergabe gemeinsam steuert, überbrückt die Zeit zwischen Veröffentlichung und Installation deutlich besser als einzelne, voneinander getrennte Maßnahmen.

Ob ein Unternehmen diese Aufgaben selbst abbildet oder abgibt, hängt von Größe, Personal und Anspruch ab.
Entscheidend ist, dass sie überhaupt jemand verbindlich übernimmt.

Bedeutung für Geschäftsführung und Entscheider

Für die Geschäftsführung ist die Zahl 1.413 weniger wichtig als zwei Fragen: Wie schnell kommen kritische Updates auf allen Geräten an, und welche Systeme laufen auf Versionen, die keine Updates mehr erhalten? Beides lässt sich messen und sollte regelmäßig berichtet werden.

Die Outlook-Lücken machen deutlich, dass Mitarbeitende in solchen Fällen nichts falsch machen müssen, damit ein Angriff gelingt. Die Verantwortung liegt dann vollständig beim Betrieb der IT. Wer diese Verantwortung klar zuordnet und mit festen Abläufen hinterlegt, reduziert das Risiko deutlich stärker, als es einzelne Notfallmaßnahmen können.

FAQ zum Patchday Oktober 2026

Welche Updates aus dem Patchday Oktober 2026 sind am dringendsten?

Zuerst das Windows-Update gegen den aktiv ausgenutzten Zero-Day CVE-2026-96951, direkt danach die Office-Updates wegen der Outlook-Lücken im Vorschaufenster. Exchange Server und Domänencontroller sollten früh, aber mit Testphase folgen.

Hilft es, das Vorschaufenster in Outlook abzuschalten?

Das kann die Angriffsfläche bis zur Installation der Updates verkleinern, ersetzt das Update aber nicht. Es ist eine Übergangslösung, kein dauerhafter Schutz.

Muss für die Cloud-Lücken etwas getan werden?

Nein. Die kritischen Lücken in Diensten wie Bookings, Dataverse und Azure App Service hat Microsoft selbst behoben.

Was passiert mit Geräten auf Windows 11 24H2 Home oder Pro?

Sie erhalten nach dem Oktober-Update keine Sicherheitsupdates mehr. Ein Upgrade auf Windows 11 25H2 sollte zeitnah eingeplant werden.

Gibt es einen Fahrplan für den Patchday?

Wir haben einen Update-Fahrplan entwickelt, damit man sicher durch die Patchdays kommt.

Update-Fahrplan (PDF)

Fazit

Der Patchday Oktober 2026 ist größer als jeder zuvor, doch die Prioritäten sind klar: der Zero-Day in der Windows Shell, die Outlook-Lücken im Vorschaufenster und danach Exchange und Active Directory. Dazu kommen Supportenden, die Geräte dauerhaft ungeschützt lassen, wenn niemand den Wechsel plant.

Patchdays dieser Größenordnung zeigen, dass IT-Sicherheit heute weniger vom einzelnen Update abhängt als von einem Betrieb, der Inventar, Priorisierung, Tests und Zuständigkeiten verlässlich organisiert.

Weitere interessante Beiträge

IT-News

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

5. August 2026

Zum Blogbeitrag

IT-News

Proxmox-Bug: Datenverlust durch Fehler beim Restore vom Backup Server

17. August 2026

Zum Blogbeitrag

IT-News

Patchday September 2026: 964 Lücken und zwei aktive Zero-Days

16. September 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Patchday Oktober 2026: Outlook-Lücken im Vorschaufenster und ein aktiver Zero-Day erschien zuerst auf mars solutions GmbH.

Exchange Server Sicherheitsupdate: CVE-2026-96940 öffnet fremde Postfächer

Technischer Support — Mon, 05 Oct 2026 10:27:25 +0000

Exchange Server Sicherheitsupdate: CVE-2026-96940 öffnet fremde Postfächer

Technischer Support
Oktober 5, 2026
12:27

Microsoft hat am 2. Oktober 2026 außerplanmäßig ein Exchange Server Sicherheitsupdate veröffentlicht, die Version 2 der September-Updates. Es schließt CVE-2026-96940, eine Lücke mit einem CVSS-Wert von 8.8: Ein angemeldeter Angreifer kann damit Postfächer anderer Benutzer derselben Organisation lesen, samt Anhängen. Betroffen sind alle lokalen Exchange-Server, Exchange Online ist bereits geschützt. Für Exchange 2016 und 2019 gehört das Update zugleich zu den letzten, die es überhaupt noch gibt.

Das Wichtigste in Kürze

CVE-2026-96940 ist eine Rechteausweitung durch schwache Autorisierung in Exchange Server SE, 2019 und 2016, bewertet mit CVSS 8.8 („Important“).
Ein einziges gültiges Benutzerkonto reicht, um E-Mails und Anhänge fremder Postfächer derselben Organisation zu lesen.
Microsoft hält eine Ausnutzung für „eher wahrscheinlich“, aktive Angriffe sind laut Microsoft nicht bekannt.
Die Updates heißen KB5129955 (SE), KB5129956 und KB5129957 (2019) sowie KB5129958 (2016); für 2016 und 2019 gibt es sie nur mit ESU Period 2.
Nach Ende Oktober 2026 erhalten Exchange 2016 und 2019 laut Microsoft keine Updates mehr, auch nicht mit ESU.

Was das Exchange Server Sicherheitsupdate schließt

Die Lücke steckt in der Autorisierung von Exchange Server. Ein Angreifer, der sich mit einem gültigen Konto übers Netzwerk anmeldet, kann sich mehr Rechte verschaffen, als ihm zustehen, und auf Postfächer anderer Benutzer zugreifen. Laut Microsoft lassen sich dabei E-Mails und Anhänge lesen. Über die Grenzen der eigenen Organisation hinaus wirkt die Lücke nicht.

Gefunden hat Microsoft die Schwachstelle nach eigenen Angaben selbst. Das Exchange-Team schreibt, das Update sei früher als geplant veröffentlicht worden, und empfiehlt, es bei der nächsten Gelegenheit einzuspielen. Gegenüber dem regulären September-Update vom 8. September kommt nur CVE-2026-96940 hinzu. Da Exchange-Updates kumulativ sind, enthält die neue Version auch alle Korrekturen aus dem September; das Paket für Exchange 2016 listet insgesamt neun CVEs.

Exchange Online hat Microsoft serverseitig bereits korrigiert. In Hybrid-Umgebungen müssen die lokalen Exchange-Server trotzdem aktualisiert werden, auch wenn sie nur noch der Verwaltung dienen. Dasselbe gilt laut Microsoft für Arbeitsplätze mit den Exchange Management Tools.

Zahlen, Daten, Fakten

CVSS-Wert der Lücke

0 .8

Update-Pakete für alle Versionen

CVEs im Paket für Exchange 2016

Updates für 2016/2019 nach 10/2026

Ein Konto reicht für fremde Postfächer

Die Voraussetzung einer Anmeldung klingt nach einer hohen Hürde, ist es aber nicht. Erbeutete Zugangsdaten aus Phishing oder Password Spraying sind einer der häufigsten Einstiege in Unternehmensnetze. Mit CVE-2026-96940 genügt ein solches Konto, etwa das eines Praktikanten oder ein selten genutztes Dienstkonto, um die Postfächer der Geschäftsführung, der Buchhaltung oder der Personalabteilung zu lesen.

Wichtig für IT-Admins

Lokale Exchange-Server waren 2026 bereits mehrfach Ziel, zuletzt mit dem Exchange-Zero-Day CVE-2026-42897 und dem OWAReaper-Exploit. Die Einstufung „Ausnutzung eher wahrscheinlich“ bedeutet in Microsofts Bewertungsschema, dass sich ein funktionierender Angriff verlässlich entwickeln lässt. Mit jedem veröffentlichten Update steigt zudem die Chance, dass Angreifer die Korrektur auswerten und die Lücke nachbauen.

Exchange-Update erschien vor der Dokumentation

Das Paket für Exchange SE war früher sichtbar als seine Beschreibung. Laut frankysweb verteilte Microsoft KB5129955 ab dem 1. Oktober über WSUS, Windows Update und den Update-Katalog, ohne Support-Artikel und ohne Ankündigung. borncity riet zunächst, das undokumentierte Paket nicht zu installieren. Erst mit dem Beitrag des Exchange-Teams am 2. Oktober war klar, dass es sich um das Sicherheitsupdate gegen CVE-2026-96940 handelt.

Wer KB5129955 vorsorglich im WSUS zurückgehalten hat, kann die Sperre nach eigener Prüfung aufheben. Exchange-Updates sollten allerdings grundsätzlich nicht unbeaufsichtigt über WSUS laufen, sondern gezielt im Wartungsfenster installiert werden.

Exchange 2016/2019 vor dem ESU-Ende

Exchange 2016 und 2019 sind seit Oktober 2025 ohne regulären Support. Updates erhalten nur noch Organisationen, die im kostenpflichtigen Programm ESU Period 2 eingeschrieben sind, und das läuft von Mai bis Ende Oktober 2026. Microsoft hat im Juli ausdrücklich bestätigt, dass es keine weitere Verlängerung gibt. Nach Oktober 2026 erscheinen für diese Versionen keine Sicherheitsupdates mehr.

Wer ohne ESU arbeitet, bekommt das aktuelle Update gar nicht erst angeboten. Für diese Server rät Microsoft zum Umstieg auf Exchange Server SE. Von Exchange 2019 CU14 oder CU15 ist laut Microsoft ein In-Place-Upgrade auf SE RTM möglich, das technisch wenig Risiko birgt; die Lizenzanforderungen von Exchange 2019 und SE sind nach Microsoft-Angaben gleich. Exchange 2016 muss vorher migriert werden.

Exchange-Update: Vorgehen für IT-Admins

1

Bestand prüfen

Alle Exchange-Server und Rechner mit Exchange Management Tools erfassen und mit dem Exchange Server Health Checker auf fehlende CUs und SUs prüfen.

2

Voraussetzung klären

Das Update setzt Exchange SE RTM, Exchange 2019 CU14 oder CU15 beziehungsweise Exchange 2016 CU23 voraus. Ältere Stände zuerst auf das passende CU heben; bei 2016 und 2019 die ESU-Berechtigung prüfen.

3

Sichern und einspielen

Vor dem Update eine Sicherung anlegen. Das passende Paket (KB5129955 bis KB5129958) aus einer Eingabeaufforderung mit Administratorrechten installieren, nicht per Doppelklick.

4

Nach dem Update prüfen

Server neu starten und kontrollieren, ob alle Exchange-Dienste laufen. Deaktivierte Dienste weisen laut Microsoft auf eine unterbrochene Installation hin. Danach OWA und ECP testen und den Stand mit dem Health Checker erneut prüfen.

5

Bekannte Probleme beachten

Veröffentlichte Kalender (.ics) liefern nach dem Update einen HTTP-500-Fehler, eine Korrektur ist angekündigt. Wer Kalender extern veröffentlicht, sollte die Betroffenen vorab informieren.

6

Hybrid nachziehen

Wird nach dem Update das Auth-Zertifikat geändert, den Hybrid Configuration Wizard erneut ausführen.

Den installierten Stand zeigt auch dieser Befehl in der Exchange Management Shell:

Get-Command Exsetup.exe | ForEach-Object { $_.FileVersionInfo }

Bedeutung für Geschäftsführung und Entscheider

Für die Geschäftsführung ist CVE-2026-96940 vor allem ein Vertraulichkeitsrisiko. Wer ein beliebiges Benutzerkonto übernimmt, kann Verträge, Gehaltsdaten, Angebote und Gesprächsverläufe der Führungsebene mitlesen. Daraus entstehen typischerweise Rechnungsbetrug über echte Mailverläufe und – sobald personenbezogene Daten betroffen sind – eine Meldepflicht nach DSGVO binnen 72 Stunden.

Das Update selbst ist eine Routinearbeit im Wartungsfenster. Die eigentliche Entscheidung betrifft Unternehmen, die noch Exchange 2016 oder 2019 betreiben: Ende Oktober 2026 endet die letzte Möglichkeit, diese Server mit Sicherheitsupdates zu versorgen. Danach bleibt jede neue Lücke dauerhaft offen. Zur Wahl stehen der Umstieg auf Exchange Server SE oder die Migration der Postfächer nach Exchange Online. Beides braucht Planung, Budget und ein Wartungsfenster, und bis Ende Oktober bleiben nur noch wenige Wochen.

FAQ zum Exchange Server Sicherheitsupdate

Wird CVE-2026-96940 bereits ausgenutzt?

Nach Angaben von Microsoft nicht. Microsoft hat die Lücke intern gefunden und stuft eine Ausnutzung als „eher wahrscheinlich“ ein. Das Update sollte deshalb zeitnah eingespielt werden.

Müssen Exchange-Online-Kunden etwas tun?

Für Exchange Online selbst nicht, Microsoft hat die Korrektur serverseitig verteilt. In Hybrid-Umgebungen müssen Sie die lokalen Exchange-Server und die Rechner mit Exchange Management Tools trotzdem aktualisieren.

Wir haben das September-Update installiert. Reicht das?

Nein. CVE-2026-96940 ist erst in der Version 2 vom 2. Oktober enthalten. Da die Updates kumulativ sind, genügt es, die neue Version auf dem aktuellen CU zu installieren.

Wir betreiben Exchange 2019 ohne ESU. Was nun?

Für diese Konstellation stellt Microsoft kein Update bereit. Kurzfristig sollte der Zugriff aus dem Internet eingeschränkt werden; das senkt das Risiko, beseitigt es aber nicht, da auch interne Konten die Lücke nutzen können. Mittelfristig führt der Weg über ein In-Place-Upgrade auf Exchange Server SE oder eine Migration nach Exchange Online.

Kann KB5129955 automatisch über WSUS installiert werden?

Technisch ja, empfehlenswert ist es nicht. Exchange-Updates sollten mit Administratorrechten im Wartungsfenster installiert und anschließend geprüft werden, damit keine Dienste deaktiviert zurückbleiben.

Fazit

Das außerplanmäßige Exchange Server Sicherheitsupdate schließt eine Lücke, mit der ein einziges erbeutetes Konto ausreicht, um fremde Postfächer zu lesen. Angriffe sind noch nicht bekannt, Microsoft rechnet aber mit ihnen. Das Update gehört deshalb noch in dieser Woche in ein Wartungsfenster, mit Sicherung vorab und Prüfung danach. Für Exchange 2016 und 2019 ist es zugleich eines der letzten Updates überhaupt: Wer diese Server nach Ende Oktober 2026 weiterbetreibt, betreibt sie ohne Sicherheitsupdates.

Weitere interessante Beiträge

IT-News

Druckprobleme nach KB5120708: .NET-Update stoppt Druck und PDF-Export

27. August 2026

Zum Blogbeitrag

IT-News

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

5. August 2026

Zum Blogbeitrag

IT-News

Patchday Oktober 2026: Outlook-Lücken im Vorschaufenster und ein aktiver Zero-Day

14. Oktober 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Exchange Server Sicherheitsupdate: CVE-2026-96940 öffnet fremde Postfächer erschien zuerst auf mars solutions GmbH.

Cyberangriff LMU München: Stammdaten von Studierenden abgeflossen

Technischer Support — Tue, 22 Sep 2026 09:35:40 +0000

Cyberangriff LMU München: Stammdaten von Studierenden abgeflossen

Technischer Support
September 22, 2026
11:35

Die Ludwig-Maximilians-Universität München hat am 19. September 2026 einen Datenschutzvorfall öffentlich gemacht: Ein Angreifer ist unbefugt in ein IT-System mit Stammdaten zu Immatrikulationen eingedrungen – und hat die Daten nach heutigem Stand auch abgerufen.

Was beim Cyberangriff LMU München passiert ist, welche Daten das Haus verlassen haben und welche fünf Fragen jede Geschäftsführung daraus für den eigenen Betrieb ableiten sollte, lesen Sie hier.

Das Wichtigste in Kürze

Der Angriff wurde am Mittwoch, dem 16. September 2026, bemerkt; die Öffentlichkeit erfuhr davon am Samstag, dem 19. September - drei Tage später
Betroffen ist ein einzelnes Fachsystem mit Immatrikulationsstammdaten von Studierenden und Studienbewerbenden, nicht die gesamte Hochschul-IT
Abgeflossen sind identifizierende Daten, Kontaktdaten, Bankdaten, Krankenversicherungs- und BAföG-Nummern sowie Angaben zu Schul- und Studienabschlüssen, in Einzelfällen auch besondere Kategorien nach Artikel 9 DSGVO
Nicht betroffen sind nach Angaben der LMU Prüfungs- und Leistungsdaten sowie Passwörter und LMU-Benutzerkennungen
Es gibt bislang keine Anhaltspunkte für eine Veröffentlichung der Daten; das Bayerische Landeskriminalamt ermittelt, Spezialisten beobachten Darknet-Portale

So lief der Cyberangriff auf die LMU München ab

Nach Darstellung der Universität fiel der Vorfall am Mittwoch, dem 16. September 2026, auf. Ein unbefugter Angreifer hatte Zugriff auf Stammdaten aus einem System, das die Immatrikulation verwaltet. Die LMU formuliert es in ihrer Mitteilung deutlich: Man müsse derzeit davon ausgehen, dass diese Daten auch abgerufen wurden.

Die IT-Abteilung reagierte unmittelbar nach den ersten Anzeichen und nahm das betroffene System vollständig vom Netz, um weiteren Abfluss zu verhindern.

Parallel wurden externe IT-Forensiker eingeschaltet, die Sicherheitsüberwachung erweitert und das Bayerische Landeskriminalamt eingebunden.
Die technische Aufklärung dauert an.

Öffentlich gemacht wurde der Vorfall am Samstag, dem 19. September – drei Tage nach der Entdeckung. Diese Lücke wurde politisch kritisiert: Medienberichten zufolge wurde darauf verwiesen, dass die Datenschutz-Grundverordnung eine unverzügliche Benachrichtigung Betroffener verlange, und forderte Transparenz über Ursache und Ablauf. Die LMU verweist ihrerseits auf die enge Zusammenarbeit mit Ermittlungs- und Aufsichtsbehörden.

Zum Einfallsweg gibt es bislang keine belastbaren Angaben. Weder die Universität noch die Berichterstattung nennen eine ausgenutzte Schwachstelle, kompromittierte Zugangsdaten oder einen konkreten Softwarestand. Wer den Fall bewertet, sollte das im Blick behalten: Alles, was derzeit über das „Wie“ gesagt wird, ist Spekulation.

Diese Daten sind abgeflossen

Die LMU hat die betroffenen Datenkategorien ungewöhnlich sauber aufgeschlüsselt. Nach ihren Angaben sind betroffen:

Identifizierende Daten - Name, Geburtsdatum, Geschlecht, gegebenenfalls Geburtsort oder Geburtsland
Kontaktdaten - Semester- und Heimatanschrift, ggf. Telefonnummer, LMU-E-Mail-Adresse und gegebenenfalls eine weitere E-Mail-Adresse
Bankdaten - unter anderem IBAN und Name des Kontoinhabers
Sozial- und Verwaltungsdaten - Krankenversicherungsnummern und BAföG-Nummern
Bildungsdaten - Angaben zu Schul- und Studienabschlüssen sowie zum Studienverlauf
In Einzelfällen besondere Kategorien nach Artikel 9 DSGVO - etwa hinterlegte Gründe für eine Beurlaubung

Ausdrücklich nicht betroffen sind nach Angaben der Hochschule Prüfungsinformationen, konkrete Angaben zu Studieninhalten und individuellen Leistungen sowie Passwörter und LMU-Benutzerkennungen. Eine generelle Passwortänderung hält die LMU deshalb nicht für zwingend erforderlich.

Die Kombination ist das Problem, nicht die einzelne Angabe

Name, Geburtsdatum, Anschrift und IBAN ergeben zusammen einen vollständigen Identitätsbaukasten – genug für Bestellbetrug, Vertragsabschlüsse und Lastschriftmissbrauch im Namen der Betroffenen. Krankenversicherungs- und BAföG-Nummern machen jede spätere Phishing-Mail glaubwürdig, weil sie Wissen belegen, das ein Fremder nicht haben sollte.

Zahlen zum Cyberangriff auf die LMU München

16.09.2026

Tag der Entdeckung

3 Tage

bis zur öffentlichen Information am 19.09.2026

über 52.000

Studierende im Wintersemester 2025/26

0

bisher bekannte Veröffentlichungen der Daten

Eine offizielle Zahl der Betroffenen gibt es nicht. Die 52.000 sind die Einschreibezahl des vergangenen Wintersemesters und damit eine Größenordnung, keine Betroffenenzahl. Weil auch Studienbewerbende im System stehen und unklar ist, wie weit die Datenhistorie zurückreicht, kann der tatsächliche Kreis größer sein.

Warum ein Datenabfluss ohne Verschlüsselung gefährlich bleibt

Der Fall LMU hat kein Ransomware-Muster: keine verschlüsselten Server, keine Lösegeldforderung, keine Leak-Seite mit Countdown. Genau deshalb wird er unterschätzt.

Ein Verschlüsselungsvorfall ist laut und hat ein Ende. Ein Backup wird eingespielt, der Betrieb läuft wieder, der Schaden ist bezifferbar. Ein reiner Datenabfluss ist leise und hat kein Ende. Die Daten sind kopiert, sie lassen sich nicht zurückholen, und sie verlieren über Jahre kaum an Wert. Ein Geburtsdatum ändert sich nicht, eine IBAN selten, eine Anschrift nur beim Umzug.

Hinzu kommt die Verwertungskette. Zwischen Abfluss und Missbrauch liegen oft Monate:

Daten werden gebündelt und mit Material aus anderen Lecks angereichert.
Dann folgt personalisiertes Phishing – mit echten Namen, echten Vorgangsdaten, echtem Bezug.
Parallel laufen Identitätsmissbrauch und vorbereitete Anrufe bei Banken und Dienstleistern.

Wie stark echte Namen, echte Zuständigkeiten und echte Vorgangsdaten die Glaubwürdigkeit eines Angriffs erhöhen, zeigt der Beitrag zum Datenleck im Berliner Landesnetz.

Dass bisher nichts veröffentlicht wurde, ist deshalb kein Entwarnungssignal. Es bedeutet nur, dass der Angreifer bislang keinen Anlass hatte, Druck aufzubauen oder einen anderen Verwertungsweg gewählt hat.

Was Unternehmen aus dem Fall mitnehmen

1

Ein einzelnes Fachsystem reicht

Gehackt wurde nicht die zentrale IT, sondern ein System für einen einzelnen Prozess. In Unternehmen sind das die Bewerbermanagement-Lösung, das Zeiterfassungssystem, das Kundenportal, die Lohnbuchhaltung – Anwendungen, die außerhalb des Kernbetriebs laufen und selten im Fokus stehen. Sie enthalten trotzdem Stammdaten, Bankverbindungen und Sozialdaten.

2

Alte Daten wiegen schwer

Der wahrscheinlichste Grund, warum der Kreis der Betroffenen größer sein könnte als die aktuelle Studierendenzahl: Es stehen noch Bewerbungs- und Altdaten im System. Dasselbe gilt für abgelehnte Bewerber, ausgeschiedene Mitarbeitende und beendete Kundenbeziehungen. Jeder Datensatz ohne Löschfrist ist eine Verbindlichkeit, die nur im Schadensfall sichtbar wird.

3

Erkennung entscheidet über den Umfang

Die LMU hat den Zugriff bemerkt und das System innerhalb desselben Tages isoliert. Das ist der Unterschied zwischen einem begrenzten Vorfall und einem, der über Wochen läuft. Wer Exfiltration nicht sieht, erfährt davon erst aus der Presse oder von der Aufsichtsbehörde.

4

Kommunikation ist Teil der Abwehr

Die drei Tage bis zur Information sind der Punkt, an dem der Fall öffentlich angreifbar wurde – nicht der Angriff selbst. Wer erst im Ernstfall klärt, wer was wann sagt, verliert genau diese Zeit.

Empfehlungen für IT-Admins

Eine Universität mit 52.000 Studierenden wirkt weit weg vom Mittelstand. Das Muster ist es nicht. Die folgenden Punkte adressieren genau die Stellen, an denen der Fall LMU übertragbar ist – warum gestohlene Zugangsdaten dabei der meistgenutzte Einstieg bleiben, zeigt der Beitrag zu Identity Threats.

Fachsysteme inventarisieren: Welche Anwendung hält welche personenbezogenen Daten, wer betreibt sie, wie wird sie gepatcht? Schattenanwendungen ohne benannten Verantwortlichen sind der häufigste Startpunkt
Segmentieren: Ein System mit Stammdaten braucht keinen Weg zu jedem anderen System. Isolation ist das, was aus einem Vorfall einen begrenzten Vorfall macht
Zugriffe auf Datenbestände protokollieren und auswerten: nicht nur Anmeldungen, sondern Massenabfragen und Exporte. Ein ungewöhnlich großer Datenabzug ist das Signal, das den Unterschied macht
Löschkonzept tatsächlich anwenden: Aufbewahrungsfristen definieren, automatisiert durchsetzen und regelmäßig prüfen. Nicht vorhandene Daten müssen nicht geschützt werden
Zugänge absichern: Multifaktor-Authentifizierung auch für Fachanwendungen und Fernzugriffe, keine geteilten Dienstkonten
Phishing-Nachlauf einplanen: Nach einem Datenabfluss steigt die Qualität der Angriffe auf die Betroffenen. Mitarbeitende und Kunden gezielt vorwarnen - das Muster beschreibt der Beitrag zu Phishing und Spam im Unternehmen
Meldeweg vorbereiten: Die 72-Stunden-Frist nach Artikel 33 DSGVO läuft ab Kenntnis, nicht ab abgeschlossener Forensik. Eine Erstmeldung mit unvollständigem Bild ist zulässig und richtig

Bedeutung für Geschäftsführung und Entscheider

Der Cyberangriff LMU München ist kein Ausfallszenario. Es gab keinen Stillstand, keine Erpressung und keine bezifferbare Betriebsunterbrechung – und trotzdem einen dauerhaften Schaden, der sich nicht mehr einsammeln lässt.
Diese Art von Vorfall taucht in den meisten Notfallplanungen nicht auf, weil dort die Verfügbarkeit im Mittelpunkt steht und nicht die Vertraulichkeit.

Rechtlich ist die Lage klar. Artikel 33 DSGVO verlangt die Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnis, Artikel 34 die Benachrichtigung der Betroffenen bei hohem Risiko. Bei Bankdaten und Sozialdaten ist dieses hohe Risiko schwer zu bestreiten. Dazu kommt die Nachweispflicht aus Artikel 32: Wer nicht dokumentiert hat, welche Schutzmaßnahmen bestanden, kann sie im Nachgang nicht belegen.

In welchen Systemen liegen Bankverbindungen, Sozialdaten und Ausweisdaten unserer Mitarbeitenden, Bewerber und Kunden?
Wie lange bewahren wir diese Daten auf - und wer prüft, ob die Löschung tatsächlich stattfindet?
Würden wir einen Massenexport aus einem dieser Systeme bemerken, und woran?
Wer entscheidet innerhalb von 72 Stunden über eine Meldung an die Aufsichtsbehörde, und wer vertritt diese Person im Urlaub?
Wer informiert Betroffene, Kunden und Presse - mit welchem Text, freigegeben von wem?

Wer bei mehr als einer Frage passen muss, hat keine Technik-, sondern eine Organisationslücke. Sie ist deutlich günstiger zu schließen als ein Vorfall, der sie sichtbar macht. Einen kompakten Einstieg bietet der Beitrag mit 10 IT-Sicherheitstipps für Unternehmen.

FAQ zum Cyberangriff auf die LMU München

Wie viele Menschen sind betroffen?

Eine offizielle Zahl nennt die LMU nicht. Im Wintersemester 2025/26 waren über 52.000 Studierende eingeschrieben. Da auch Studienbewerbende im betroffenen System gespeichert sind, kann der Kreis größer sein.

Welche Daten sind abgeflossen?

Nach Angaben der LMU: Name, Geburtsdatum, Geschlecht, gegebenenfalls Geburtsort, Semester- und Heimatanschrift, Telefonnummer, E-Mail-Adressen, IBAN und Kontoinhaber, Krankenversicherungs- und BAföG-Nummern sowie Angaben zu Schul- und Studienabschlüssen. In Einzelfällen auch besondere Kategorien nach Artikel 9 DSGVO.

Sind Passwörter oder Prüfungsdaten betroffen?

Nein. Die LMU gibt an, dass Passwörter, LMU-Benutzerkennungen sowie Prüfungs- und Leistungsdaten nicht betroffen sind. Ein regelmäßiger Passwortwechsel bleibt trotzdem sinnvoll.

War es ein Ransomware-Angriff?

Es gibt keine Hinweise darauf. Systeme wurden nicht verschlüsselt, eine Lösegeldforderung ist nicht bekannt, und die Daten wurden bislang nicht veröffentlicht. Spezialisten beobachten einschlägige Darknet-Portale.

Was sollten Betroffene jetzt tun?

Kontoauszüge und Lastschriften engmaschig prüfen, bei unbekannten Abbuchungen sofort widersprechen. E-Mails, Anrufe und Nachrichten mit LMU-Bezug kritisch behandeln, keine Anhänge oder Links ungeprüft öffnen und weder Bankdaten noch Passwörter herausgeben. Die LMU hat für Rückfragen die Adresse cybersicherheit@lmu.de eingerichtet.

Kann so etwas auch einem mittelständischen Unternehmen passieren?

Ja. Kompromittiert wurde ein einzelnes Fachsystem mit Stammdaten. Bewerbermanagement, Lohnbuchhaltung, Zeiterfassung und Kundenportale sind in Unternehmen die direkte Entsprechung - mit denselben Datenkategorien und oft mit weniger Aufmerksamkeit.

Fazit

Der Cyberangriff LMU München zeigt den Vorfall, den niemand einplant: keine Verschlüsselung, kein Stillstand, keine Erpressung – und trotzdem ein Schaden, der bleibt. Ein einzelnes Fachsystem mit Stammdaten hat gereicht, um Namen, Anschriften, Bankverbindungen und Sozialdaten Zehntausender Menschen aus dem Haus zu tragen.

Gut gelaufen ist die Reaktion: bemerkt, isoliert, forensisch untersucht, Behörden eingebunden, Datenkategorien offen benannt. Angreifbar wurde der Fall dort, wo Organisation statt Technik gefragt war – bei der Frage, wie schnell und wie offen kommuniziert wird.

Für Unternehmen ist die Übertragung unbequem einfach: Jedes System, das Bankdaten und Sozialdaten hält, ist ein lohnendes Ziel, auch wenn es nur einen Nebenprozess bedient. Wer heute nicht sagen kann, wo diese Daten liegen, wie lange sie bleiben und wer im Ernstfall binnen 72 Stunden entscheidet, sollte genau dort anfangen – nicht beim nächsten Sicherheitsprodukt.

Weitere interessante Beiträge

IT-News

Exchange Server Sicherheitsupdate: CVE-2026-96940 öffnet fremde Postfächer

5. Oktober 2026

Zum Blogbeitrag

IT-News

Patchday Oktober 2026: Outlook-Lücken im Vorschaufenster und ein aktiver Zero-Day

14. Oktober 2026

Zum Blogbeitrag

IT-News

Microsoft 365 Ausfall: zwölf Stunden ohne Mail, Teams und SharePoint

1. September 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Cyberangriff LMU München: Stammdaten von Studierenden abgeflossen erschien zuerst auf mars solutions GmbH.

Revolut Datenleck: 680 Kunden nach gefälschter Behördenanfrage gehackt

Technischer Support — Thu, 17 Sep 2026 09:12:33 +0000

Revolut Datenleck: 680 Kunden nach gefälschter Behördenanfrage gehackt

Technischer Support
September 17, 2026
11:12

Die Digitalbank Revolut hat Ausweiskopien, Verifizierungs-Selfies, IBANs und vollständige Transaktionslisten von rund 680 Kunden an Kriminelle herausgegeben – nicht nach einem Einbruch in die IT-Systeme, sondern nach E-Mails, die aus der echten Domain einer Regierungsbehörde kamen.

Betroffen ist auch eine niedrige zweistellige Zahl deutscher Kunden. Der Fall trifft jedes Unternehmen, das Auskunftsersuchen von Behörden beantwortet: Gescheitert ist hier keine Technik, sondern ein Prozess.

Was beim Revolut Datenleck genau passiert ist, warum SPF, DKIM und DMARC nicht geholfen haben und wie Sie ein Auskunftsersuchen im eigenen Haus sicher prüfen, lesen Sie hier.

Das Wichtigste in Kürze

Rund 680 Kunden sind betroffen, schwerpunktmäßig in der Schweiz und Frankreich, dazu über 30 weitere europäische Länder und eine niedrige zweistellige Zahl in Deutschland
Herausgegeben wurden Ausweis- und Führerscheinkopien, Verifizierungs-Selfies, Geburtsdatum, Adresse, Telefonnummer, IBAN, Kontoauszüge und vollständige Transaktionslisten inklusive Bitcoin-Bewegungen
Die Anfragen kamen über ein echtes Behördenpostfach im italienischen PEC-System und bestanden alle technischen Absenderprüfungen
Aufgefallen ist der Betrug erst, als Revolut eine Anfrage separat bei der Behörde gegenprüfte
Die Täter fordern rund 6.000 Monero und drohen mit Veröffentlichung; die britische Datenschutzaufsicht ICO untersucht den Vorfall

So lief das Revolut Datenleck ab

Medienberichten zufolge traten die Angreifer als italienische Strafverfolgungsbehörde auf und baten Revolut über mehrere Wochen hinweg wiederholt um vertrauliche Kontodaten einzelner Kunden – Adressen, Telefonnummern, Transaktionshistorien. Revolut kam diesen Anfragen nach.

Die E-Mails liefen über „La Posta Elettronica Certificata“ (PEC), das rechtsverbindliche Zustellsystem für offiziellen Schriftverkehr in Italien, vergleichbar mit einem Einschreiben. Die Täter hatten kein Postfach gefälscht: Sie verfügten über ein Konto innerhalb der echten Behördeninfrastruktur.

Die Auswahl der Opfer war geziel: Die Gruppe, die unter dem Pseudonym „iamnotavillain“ auftritt, beschrieb die Betroffenen als „Krypto-Wale“ und gab an, sie über Blockchain-Analysen identifiziert zu haben – also über öffentlich einsehbare Zahlungsströme. Anschließend fragte sie genau zu diesen Personen Kontodaten bei Revolut ab.

Aufgeflogen ist der Betrug erst, als Revolut eine der Anfragen separat bei der genannten Behörde gegenprüfte. Das Unternehmen sperrte die Adresse, informierte Strafverfolgungs-, Datenschutz- und Finanzaufsichtsbehörden und kontaktierte die Betroffenen. IT-Systeme und Kundengelder seien nicht betroffen, teilte Revolut mit; man habe einen ausgeklügelten externen Betrugsversuch identifiziert.

Die britische Datenschutzaufsicht ICO bestätigte, dass sie den Vorfall untersucht. Revolut untersteht als Bank der litauischen Zentralbank und der EZB.

Inzwischen fordern die mutmaßlichen Täter Lösegeld: rund 6.000 Monero, nach Marktwert etwa drei Millionen Dollar, verbunden mit einem öffentlichen Countdown und der Drohung, die Unterlagen an andere Kriminelle weiterzugeben. Einzelne Betroffene berichteten in sozialen Medien, direkt kontaktiert worden zu sein.

Zahlen zum Revolut Datenleck

rund 680

betroffene Kunden

über 30

betroffene europäische Länder

6

Monate Zugriff auf Behördenpostfächer, nach Angaben der Täter

6.000

Monero Lösegeldforderung

Die Angaben gehen leicht auseinander: Die „Financial Times“ und die daran anschließende Berichterstattung nennen rund 680 Betroffene, das „manager magazin“ spricht von mindestens rund 700 Fällen, Revolut selbst nur von einer begrenzten Zahl. Die Größenordnung ist in allen Quellen dieselbe.

Warum die gefälschte Behördenanfrage funktionierte

Die entscheidende Stelle ist unscheinbar: Die Nachrichten bestanden die technischen Absenderprüfungen. Weil das Konto innerhalb der echten Behördendomain lag, waren SPF, DKIM und DMARC sauber – genau die Mechanismen, auf die Unternehmen sich beim Erkennen gefälschter Absender verlassen. Laut heise verschickte Revolut die Unterlagen deshalb, bevor separat geprüft wurde, ob die Anfrage tatsächlich von der Behörde stammte.

Dazu kommt die Besonderheit von Auskunftsersuchen: Sie sind ein Ausnahmeprozess.

Sie kommen selten – es gibt keine Routine und oft keinen festgelegten Ablauf.
Sie kommen von einer Autorität – Nachfragen wirkt unhöflich oder riskant.
Sie sind häufig als eilbedürftig markiert – Zeitdruck verhindert die Gegenprüfung.
Sie landen selten bei der IT-Sicherheit, sondern im Support oder in der Verwaltung.

Genau diese Kombination ist der klassische Hebel des Social Engineering – und sie wirkt unabhängig davon, wie gut die technische Abwehr eines Unternehmens ist.

SPF, DKIM und DMARC prüfen die Domain, nicht den Menschen

Die drei Verfahren belegen, dass eine Nachricht von einer bestimmten Domain kommen darf. Sie belegen nicht, dass die Person hinter dem Postfach dazu berechtigt ist. Ein übernommenes echtes Behördenpostfach besteht jede dieser Prüfungen.

Gefälschte Behördenanfragen sind kein Einzelfall

Das Muster ist international bekannt. Das FBI warnte bereits 2024 vor einer Zunahme gefälschter Auskunfts- und Notfallanfragen: Kriminelle kompromittieren Postfächer von Polizei- und Regierungsstellen, häufig per Phishing, und handeln die Zugänge anschließend in einschlägigen Foren. Unter den Unternehmen, die auf solche Anfragen hereingefallen sind, waren nach Berichten von Sicherheitsforschern auch Apple, Meta, Discord und Verizon.

Für deutsche Unternehmen ist die Lage keine andere. Auskunftsersuchen kommen von Polizei, Staatsanwaltschaften, Finanz-, Zoll- und Sozialbehörden – und selten bei der IT-Sicherheit. Sie landen im Support, in der Buchhaltung, im Personalbüro oder in der Geschäftsleitung – dort, wo der Reflex, einer Behörde schnell und vollständig zu helfen, am stärksten ist.

Wie leicht sich solche Anschreiben mit Daten aus früheren Lecks anreichern lassen, zeigt der Beitrag zum Datenleck im Berliner Landesnetz: Echte Namen, echte Zuständigkeiten und echte Vorgangsdaten machen eine Anfrage erst überzeugend.

So prüfen Sie Auskunftsersuchen richtig

1

Zuständigkeit klären

Existiert die Behörde, und ist sie für den genannten Sachverhalt überhaupt zuständig? Stimmen Anschrift und Kontaktdaten mit den öffentlich veröffentlichten überein?

2

Formalien verlangen

Aktenzeichen, benannter Ansprechpartner, Rechtsgrundlage und konkreter Umfang der Anfrage. Fehlt eines davon, wird nichts herausgegeben.

3

Über einen zweiten Kanal rückfragen

Rückruf oder Rückschreiben ausschließlich über die offiziell veröffentlichten Kontaktdaten der Behörde – niemals über Telefonnummern oder Adressen aus der Anfrage selbst.

4

Rechtsgrundlage prüfen lassen

Datenschutzbeauftragte oder Rechtsabteilung bewerten, ob und in welchem Umfang eine Herausgabe zulässig ist.

5

Datenminimierung anwenden

Nur genau das herausgeben, was verlangt und rechtlich gedeckt ist. Kein Sammelexport, keine Beilagen der Vollständigkeit halber.

6

Vier-Augen-Prinzip und Protokoll

Jede Herausgabe von einer zweiten Person freigeben lassen und vollständig dokumentieren: wer, wann, an wen, welche Daten, auf welcher Grundlage.

7

Eilbedürftigkeit misstrauisch behandeln

Zeitdruck ist das häufigste Merkmal gefälschter Anfragen. Eine echte Behörde akzeptiert eine kurze Rückfrage zur Verifikation.

Empfehlungen für IT-Admins und Datenschutz

Technische Filter greifen hier nicht, weil die Nachricht echt ist – dasselbe Muster zeigt sich bei Phishing- und Spam-Wellen im Unternehmen. Wirksam ist daher der organisatorische Teil, und warum der Mensch dabei die beste Kontrolle ist, zeigt der Beitrag zum Sicherheits-Upgrade vor dem Bildschirm.

Prozess schriftlich festlegen: Eine benannte Stelle nimmt Auskunftsersuchen an, alle anderen leiten weiter und antworten nicht selbst
Empfänger schulen: Support, Buchhaltung, Personal und Empfang kennen den Ablauf
Rückkanal vorbereiten: Verifizierte Kontaktdaten der regelmäßig anfragenden Behörden hinterlegen
Herausgaben protokollieren: Wer welche personenbezogenen Daten wann an wen übermittelt hat, muss ohne Suchen nachweisbar sein
Meldeprozess vorbereiten: Die 72-Stunden-Frist der DSGVO läuft ab Kenntnis, nicht ab abgeschlossener Analyse
Awareness aktuell halten: Autoritäts- und Dringlichkeitsdruck gehören in jede Schulung, nicht nur der klassische Link-Klick

Bedeutung für Geschäftsführung und Entscheider

Revolut hatte kein Technikproblem. Das Unternehmen hatte eine Lücke zwischen einer plausiblen Anfrage und einer belastbaren Prüfung.
Genau diese Lücke existiert in den meisten Unternehmen, weil Auskunftsersuchen zu selten vorkommen, um einen eingeübten Ablauf zu haben.

Das Risiko ist unmittelbar. Werden Ausweiskopien, Adressen und Kontodaten herausgegeben, entstehen daraus Identitätsmissbrauch, gezielter Betrug und – wie im aktuellen Fall – Erpressung der betroffenen Personen. Hinzu kommen die Pflichten aus der DSGVO: Meldung an die Aufsichtsbehörde binnen 72 Stunden, Benachrichtigung der Betroffenen bei hohem Risiko und die Nachweispflicht, dass die Herausgabe geprüft wurde.

Der Aufwand für die Gegenmaßnahmen ist gering. Eine verbindliche Zuständigkeit, eine kurze Prüfliste und das Vier-Augen-Prinzip sind Organisationsarbeit von wenigen Stunden, kein IT-Projekt. Die Frage an die Geschäftsführung lautet deshalb nicht, ob die Systeme sicher sind, sondern: Wer im Unternehmen darf personenbezogene Daten an eine Behörde herausgeben – und wie wird diese Anfrage geprüft, bevor die Datei das Haus verlässt?

FAQ zum Revolut Datenleck

Wurde Revolut gehackt?

Nein. Die IT-Systeme wurden nach Angaben des Unternehmens nicht kompromittiert, Kundengelder sind nicht betroffen. Die Daten wurden regulär herausgegeben - auf eine Anfrage, die aus einem echten, von Kriminellen kontrollierten Behördenpostfach kam.

Welche Daten sind abgeflossen?

Name, Geburtsdatum, Adresse, Telefonnummer, IBAN, Kopien von Ausweis oder Führerschein, Verifizierungs-Selfies, Kontoauszüge sowie vollständige Transaktionslisten einschließlich Bitcoin-Bewegungen.

Warum haben SPF, DKIM und DMARC nicht geholfen?

Weil sie die Domain prüfen, nicht die Person dahinter. Die Nachricht kam tatsächlich von der Behördendomain und bestand die Prüfung korrekt. Gegen ein übernommenes echtes Postfach schützt nur eine Rückfrage über einen zweiten Kanal.

Kann so etwas auch einem mittelständischen Unternehmen passieren?

Ja. Auskunftsersuchen von Polizei, Staatsanwaltschaft oder Finanzbehörden erreichen Unternehmen jeder Größe, meist außerhalb der IT. Ohne festgelegten Prüfweg entscheidet die einzelne Person am Postfach - genau darauf zielen diese Angriffe.

Was ist zu tun, wenn bereits Daten herausgegeben wurden?

Vorgang vollständig dokumentieren, Umfang der Übermittlung feststellen, Datenschutzbeauftragte einbinden und die Meldepflicht nach DSGVO binnen 72 Stunden prüfen. Anschließend die betroffene Behörde über den offiziellen Kanal informieren und Strafanzeige erstatten.

Fazit

Das Revolut Datenleck ist kein Beispiel für schlechte IT-Sicherheit, sondern für einen Prozess ohne zweite Instanz. Eine formal einwandfreie Anfrage aus einer echten Behördendomain schlägt jede Absenderprüfung – und wird dann zu dem, was sie vorgibt zu sein: eine legitime Herausgabe.

Der wirksame Schutz ist banal und kostet fast nichts: eine benannte Zuständigkeit, eine kurze Prüfliste und der Rückruf über einen unabhängigen Kanal, bevor Daten das Haus verlassen. Unternehmen sollten das Revolut Datenleck zum Anlass nehmen, einmal durchzuspielen, was passieren würde, wenn morgen eine eilige Anfrage einer Staatsanwaltschaft im Support-Postfach liegt.

Weitere interessante Beiträge

IT-News

Patchday September 2026: 964 Lücken und zwei aktive Zero-Days

16. September 2026

Zum Blogbeitrag

mars-News

mars Events - Sommer / Herbst 2026

30. September 2026

Zum Blogbeitrag

IT-News

PHP Sicherheitslücke PHP2Shell: Updates für alle Webserver

21. Oktober 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Revolut Datenleck: 680 Kunden nach gefälschter Behördenanfrage gehackt erschien zuerst auf mars solutions GmbH.

Patchday September 2026: 964 Lücken und zwei aktive Zero-Days

Technischer Support — Wed, 16 Sep 2026 08:35:35 +0000

Patchday September 2026: 964 Lücken und zwei aktive Zero-Days

Technischer Support
September 16, 2026
10:35

Der Patchday September 2026 ist der bislang umfangreichste in der Geschichte von Microsoft: Am 8. September 2026 lieferte der Hersteller Updates für 964 Schwachstellen aus, davon 104 als kritisch eingestuft. Zwei davon werden bereits aktiv ausgenutzt, beide erlauben Angreifern eine Rechteausweitung bis auf Systemebene. Erschwerend kommt hinzu, dass Microsoft das Hotpatching im September aussetzt – verwaltete Geräte brauchen diesmal einen klassischen Neustart. Dieser Beitrag ordnet ein, welche Updates Vorrang haben und worauf beim Ausrollen zu achten ist.

Das Wichtigste in Kürze

Der Patchday September 2026 schließt nach Auswertung von Tenable 964 Schwachstellen, davon 104 kritisch und 860 wichtig - mehr als jeder Patchday zuvor.
Zwei Zero-Days werden aktiv ausgenutzt: CVE-2026-81963 im Windows Update Stack und CVE-2026-85880 in der ALPC-Komponente, beide mit CVSS 7.8.
Beide Lücken stehen im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA; dortige Bundesbehörden müssen bis zum 22. September 2026 patchen.
Besonders kritisch sind drei Serverdienste: Windows DNS Server (CVE-2026-69730, CVSS 9.8), Remote Desktop Services (CVE-2026-69525, CVSS 9.8) und Kerberos (CVE-2026-69676, CVSS 8.8).
Hotpatching pausiert im September: Für verwaltete Windows-Geräte ist ein Neustartfenster einzuplanen, ab Oktober 2026 soll der gewohnte Zyklus zurückkehren.

Rekordumfang beim Patchday September 2026

Der Patchday September 2026 sprengt den bisherigen Rahmen deutlich. Der Sicherheitsanbieter Tenable zählt 964 behobene Schwachstellen, davon 104 als kritisch und 860 als wichtig bewertet. Damit übertrifft dieser Termin den bisherigen Höchstwert aus dem Juli 2026. Je nach Zählweise kommen andere Auswertungen auf bis zu 973 Einträge, weil Microsoft im Security Update Guide auch Zulieferungen aus Fremdkomponenten führt.

Bei den Schwachstellentypen dominiert die Rechteausweitung: 44,7 Prozent der Einträge entfallen laut Tenable auf Elevation of Privilege, 26,8 Prozent auf Remotecodeausführung. Für die Praxis heißt das, dass die Mehrzahl der Lücken einen bereits vorhandenen Zugang voraussetzt – genau das Szenario, das nach einer erfolgreichen Phishing-Mail eintritt.

Bemerkenswert ist auch die Jahresbilanz: Für 2026 summieren sich die Microsoft-Schwachstellen bereits auf mehr als 2.600 und damit auf mehr als das Doppelte des bisherigen Rekordjahres 2020. Sicherheitsfachleute führen die Flut auch auf KI-gestützte Codeprüfungen zurück, die viele kleinere Mängel finden. Gefährlich werden diese vor allem in Kombination, wenn Angreifer mehrere Schwächen zu einer Angriffskette verbinden.

Zahlen zum Patchday September 2026

964 geschlossene Schwachstellen, davon 104 kritisch und 860 wichtig
2 aktiv ausgenutzte Zero-Days, beide mit CVSS 7.8
44,7 Prozent Rechteausweitung, 26,8 Prozent Remotecodeausführung
22. September 2026 als Patch-Frist der CISA für US-Bundesbehörden

Zwei Zero-Days werden aktiv ausgenutzt

Die erste aktiv ausgenutzte Lücke, CVE-2026-81963, steckt ausgerechnet im Windows Update Stack, also in der Komponente, die Updates installiert. Über einen Link-Following-Fehler können Angreifer ihre Rechte bis auf Systemebene ausweiten. Laut Tenable ist es die erste Schwachstelle dieser Komponente, die seit 2022 als Zero-Day angegriffen wird. Beobachtet wird sie in Ransomware-Angriffsketten: Die Täter verschaffen sich per Phishing einen ersten Zugang und eskalieren anschließend ihre Rechte.

Die zweite Lücke, CVE-2026-85880, betrifft den Advanced Local Procedure Call (ALPC), einen internen Kommunikationsmechanismus von Windows. Auch hier geht es um eine Rechteausweitung, diesmal über eine Umgehung der Authentifizierung. Es ist laut Tenable der erste ALPC-Patch seit April 2023.

Wichtig für IT-Admins

Eine Rechteausweitung ist kein Einstiegspunkt, sondern ein Verstärker. Angreifer brauchen zuerst einen Fuß in der Tür, etwa ein übernommenes Benutzerkonto. Genau deshalb sind diese beiden Lücken für Ransomware-Gruppen so wertvoll: Sie verwandeln ein einzelnes kompromittiertes Konto in die Kontrolle über das ganze System.

Die US-Cybersicherheitsbehörde CISA hat beide Schwachstellen als aktiv ausgenutzt bestätigt und ihren Bundesbehörden eine Frist bis zum 22. September 2026 gesetzt. Für Unternehmen in Deutschland ist diese Frist nicht bindend, taugt aber als realistischer Maßstab für die eigene Planung.

Kritische Lücken in Windows-Serverdiensten

CVE	Komponente	Typ	CVSS
CVE-2026-69730	Windows DNS Server	Remotecodeausführung	9.8
CVE-2026-69525	Remote Desktop Services	Remotecodeausführung	9.8
CVE-2026-69676	Windows Kerberos	Remotecodeausführung	8.8
CVE-2026-69380	Microsoft Exchange	Rechteausweitung	8.1

Unabhängig von den Zero-Days verdienen diese vier Einträge besondere Aufmerksamkeit, weil sie zentrale Serverdienste treffen und Microsoft drei davon als „Exploitation More Likely“ einstuft. DNS und Kerberos sind Kernbestandteile jeder Active-Directory-Umgebung, Remote Desktop Services sind in vielen mittelständischen Netzen der Weg für den Fernzugriff. Fällt einer dieser Dienste in falsche Hände, steht der Domänencontroller offen. Für Exchange gilt weiterhin, was der Beitrag zur Exchange-Sicherheitslücke CVE-2026-62911 beschrieben hat: Der Rückstand beim Patchen ist bei On-Premises-Servern besonders groß.

Hotpatching pausiert im September

Für Umgebungen mit Hotpatching gibt es eine organisatorische Besonderheit. Microsoft hat bereits Ende August angekündigt, den Hotpatch-Zyklus im September auszusetzen: Tiefer liegende Sicherheitskomponenten lassen sich nicht ohne Neustart austauschen. Verwaltete Windows-Geräte benötigen deshalb in diesem Monat einen klassischen Neustart, ab Oktober 2026 soll der gewohnte Ablauf zurückkehren.

Planen Sie das Neustartfenster aktiv ein und kündigen Sie es an. Umgebungen, die sich an neustartfreie Monate gewöhnt haben, verlieren sonst Zeit mit Rückfragen aus der Belegschaft – oder es bleiben Geräte im halb gepatchten Zustand zurück.

Bekannte Probleme rund um die Updates

Für Windows-Clients verteilt Microsoft die folgenden Sammelupdates. Behoben sind damit unter anderem die Darstellungsfehler bei Mauszeiger und Desktophintergrund aus dem Vorschau-Update vom 27. August 2026 sowie Abstürze von Teams und Outlook auf ARM64-Geräten.

Zwei Baustellen bleiben. Auf Windows Server 2016 stürzt seit dem August-Update die CompatTelRunner.exe mit dem Fehler 0xc0000409 ab. Und beim WSUS-Synchronisierungsproblem, das seit Mitte Juni vor allem europäische Umgebungen trifft, greift der Fix KB5121986 vom Juli nicht in allen Fällen: Ist auf dem WSUS-Server das Windows-Subsystem für Linux als Produktkategorie ausgewählt, scheitert die Synchronisierung weiterhin. Das Abwählen dieser Kategorie hilft als Behelf.

So gehen Sie beim Patchen vor

1

Priorisieren statt alles gleichzeitig

Zuerst die beiden Zero-Days CVE-2026-81963 und CVE-2026-85880, danach DNS, Remote Desktop Services und Kerberos.

2

Exponierte Systeme zuerst

Alles, was aus dem Internet erreichbar ist, vor den internen Clients patchen.

3

Neustartfenster einplanen

Hotpatching entfällt im September; Termin und Dauer vorab abstimmen und ankündigen.

4

Testring nutzen

Eine repräsentative Gerätegruppe vorab versorgen und 24 bis 48 Stunden beobachten.

5

Verteilwege prüfen

WSUS-Synchronisierung kontrollieren, bevor der Rollout startet.

6

Erfolg messen

Nach dem Rollout die Installationsquote auswerten und Nachzügler gezielt nachziehen.

7

Rechteausweitung eindämmen

Lokale Administratorrechte reduzieren und Anmeldungen überwachen, damit ein kompromittiertes Konto nicht zur Systemübernahme führt.

Bedeutung für Geschäftsführung und Entscheider

Die Zahl 964 ist für die Geschäftsführung weniger relevant als die Frage, wie schnell diese Updates im Haus ankommen. Zwei der Lücken werden nachweislich in Ransomware-Angriffen genutzt, und beide brauchen lediglich einen bereits vorhandenen Zugang – etwa ein Konto, das über eine Phishing-Mail übernommen wurde. Zwischen erstem Zugriff und verschlüsselten Systemen liegen in solchen Fällen oft nur Stunden.

Der Aufwand ist planbar: Es geht um regulären Patchbetrieb, nicht um ein Projekt. Zu entscheiden ist im September vor allem eines – wann das Neustartfenster liegt und welche Systeme dafür kurz stillstehen dürfen. Wer diese Abstimmung verschiebt, verschiebt faktisch den Schutz.

Zwei Kennzahlen lohnen den Blick in der nächsten Leitungsrunde: Wie viele Tage vergehen zwischen Patchday und flächendeckender Installation, und wie viele Systeme sind nach 14 Tagen noch offen? Beides lässt sich aus dem vorhandenen Patchmanagement ablesen. Bleiben die Werte im zweistelligen Tagebereich, ist das ein Steuerungsthema für die Geschäftsführung und kein reines Technikthema.

FAQ zum Patchday September 2026

Welche Updates aus dem Patchday September 2026 sind am dringendsten?

Zuerst die beiden aktiv ausgenutzten Zero-Days CVE-2026-81963 (Windows Update Stack) und CVE-2026-85880 (ALPC). Danach folgen die Remotecodeausführungen in Windows DNS Server, Remote Desktop Services und Kerberos.

Warum ist im September ein Neustart nötig, obwohl Hotpatching genutzt wird?

Microsoft setzt den Hotpatch-Zyklus im September aus, weil sich tiefer liegende Sicherheitskomponenten nicht im laufenden Betrieb austauschen lassen. Ab Oktober 2026 soll wieder ohne Neustart gepatcht werden.

Sind kleine und mittlere Unternehmen von diesen Lücken betroffen?

Ja. Betroffen sind Standardkomponenten von Windows-Clients und Windows-Servern, die in praktisch jeder Umgebung laufen. Die Größe des Unternehmens spielt für die Angreifbarkeit keine Rolle.

Reicht es, die Updates automatisch installieren zu lassen?

In kleinen Umgebungen ist die automatische Installation besser als ein verzögerter manueller Prozess. In verwalteten Netzen sollten zusätzlich ein Testring, ein Neustartfenster und eine Erfolgskontrolle vorgesehen werden, damit keine Systeme unbemerkt zurückbleiben.

Fazit

Der Patchday September 2026 ist vor allem wegen zweier Lücken wichtig, nicht wegen seiner Rekordgröße: CVE-2026-81963 und CVE-2026-85880 werden aktiv in Ransomware-Angriffsketten genutzt und heben ein einzelnes kompromittiertes Konto auf Systemrechte. Direkt danach folgen die Remotecodeausführungen in DNS, Remote Desktop Services und Kerberos, weil sie die Kernwege einer Active-Directory-Umgebung treffen. Neu ist in diesem Monat nur die Organisation: Ohne Hotpatching braucht es ein Neustartfenster. Wer beides zusammen plant – Priorisierung nach Ausnutzbarkeit und ein verbindlicher Neustarttermin – hat den September-Patchday in wenigen Tagen abgeschlossen statt in mehreren Wochen.

Weitere interessante Beiträge

IT-News

Cyberangriff LMU München: Stammdaten von Studierenden abgeflossen

22. September 2026

Zum Blogbeitrag

IT-News

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

31. Juli 2026

Zum Blogbeitrag

IT-News

Teams-Phishing ohne Fake-Login: Consent-Phishing

11. August 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Patchday September 2026: 964 Lücken und zwei aktive Zero-Days erschien zuerst auf mars solutions GmbH.

Datenleck Berlin: 1,4 Millionen Dateien aus dem Landesnetz im Darknet

Technischer Support — Mon, 07 Sep 2026 07:45:00 +0000

Datenleck Berlin: 1,4 Millionen Dateien aus dem Landesnetz im Darknet

Technischer Support
September 7, 2026
09:45

Nach dem Cyberangriff auf das Berliner Landesnetz hat die Ransomware-Gruppe Rhysida am 4. September 2026 rund 1,4 Millionen Dateien im Darknet veröffentlicht.

Beim Datenleck Berlin sollen sich demnach Teile von Personalakten, eingescannte Ausweise, Gehaltsabrechnungen und Unterlagen zu kritischer Infrastruktur befinden. In der Nacht zum 6. September folgte nach Angaben des Landes Berlin ein weiteres Datenpaket, das Zugangsdaten enthält.

Das Datenleck Berlin zeigt den Unterschied zwischen einem Verschlüsselungsvorfall und einem Datenabfluss: Verschlüsselte Systeme lassen sich wiederherstellen, veröffentlichte Daten nicht mehr zurückholen.

Das Wichtigste in Kürze

Zwischen dem 7. und 12. August 2026 flossen Daten aus dem Berliner Landesnetz ab; am 14. August wurden zwei Senatsverwaltungen vom Netz getrennt.
Rhysida forderte 30 Bitcoin, umgerechnet rund 2 Millionen Euro, mit einer Frist von sechs Tagen. Das Land Berlin zahlte nicht.
Nach Fristablauf veröffentlichte die Gruppe rund 1,4 Millionen Dateien; der Tagesspiegel zählte 1.439.893 Dateien mit 5,26 Terabyte, Rhysida selbst gibt 5,79 Terabyte an.
Das zweite Paket enthält laut Land Berlin Zugangsdaten - die Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen hat ihre Maßnahmen nachgeschärft, kurzfristige Einschränkungen bei Fachverfahren sind möglich.
Das BSI warnt vor erhöhter Bedrohungslage durch personalisiertes Phishing; abgeflossene personenbezogene Daten bleiben dauerhaft missbrauchbar.

So entstand das Datenleck Berlin

Der Angriff wurde Mitte August 2026 über auffällige Netzwerkaktivitäten entdeckt, der eigentliche Datenabfluss fand nach bisherigen Erkenntnissen zwischen dem 7. und 12. August statt. Am 14. August trennte das Land zwei Senatsverwaltungen vorsorglich vom Landesnetz: Stadtentwicklung, Bauen und Wohnen sowie Mobilität, Verkehr, Klimaschutz und Umwelt. Beide waren über Tage praktisch arbeitsunfähig.

Ermittelt wird von Landeskriminalamt und Staatsanwaltschaft Berlin, das BSI ist eingebunden; die Krisenbewältigung läuft unter Leitung des Landesbeauftragten für Informationssicherheit. Ende August wurde die Erpressung öffentlich: Rhysida verlangte 30 Bitcoin, rund 2 Millionen Euro, binnen sechs Tagen. Berlin lehnte die Zahlung grundsätzlich ab – eine Entscheidung, die Sicherheitsfachleute begrüßten, die aber zur Veröffentlichung führte.

Der Einfallweg ist laut IT-Administrator nicht abschließend geklärt; bekannte Vorgehensweisen von Rhysida sind gehackte Zugangsdaten, Phishing und Social Engineering. Berichten zufolge betraf der Vorfall IT-Infrastruktur, die nie in den zentralen Betrieb überführt worden war. Parallel wurden VPN-Zugangsdaten öffentlich, woraufhin das Land Homeoffice-Zugänge für Verwaltungsbeschäftigte aussetzte.

Datenleck Berlin in Zahlen

1.439.893

veröffentlichte Dateien, gezählt vom Tagesspiegel

5,26 TB

ausgewertetes Volumen; die Täter geben 5,79 TB an

6 Tage

Erpressungsfrist bei einer Forderung von 30 Bitcoin

0 Euro

Lösegeld – das Land Berlin hat nicht gezahlt

Welche Daten das Datenleck enthält

Nach ersten Auswertungen sollen sich in den Paketen Teile von Personalakten, eingescannte Ausweise, Gehaltsabrechnungen, Arbeitszeugnisse und Vertragsunterlagen befinden. Hinzu kommen sensible Informationen zu Bauprojekten, unter anderem am Bundeskanzleramt, sowie Daten zur kritischen Infrastruktur.

Weitere Auswertungen nennen Zahlungsvorgänge, Gehaltslisten, IBANs, E-Mail-Bestände, Passwörter, KRITIS-Analysen zur Wasserversorgung und Unterlagen aus der CBRN-Rahmenplanung, also zur Vorsorge gegen chemische, biologische, radiologische und nukleare Bedrohungen.

Wichtiger Hinweis

Das zweite Paket verändert die Lage technisch. Zugangsdaten sind kein Beiprodukt, sondern der Rohstoff für den nächsten Angriff – auf dieselbe oder auf verbundene Umgebungen. Genau deshalb hat die Senatsverwaltung für Stadtentwicklung nachgeschärft und weist auf Einschränkungen bei Fachverfahren hin; betroffen sein können damit auch Anträge von Bürgern, etwa beim Wohngeld.

Warum Datenschutz jetzt geschäftskritisch ist

Bei einem reinen Verschlüsselungsvorfall ist ein geprüftes Backup die Antwort. Bei einem Datenabfluss gibt es diese Antwort nicht.

Veröffentlichte Daten sind kopiert und weiterverbreitet, bevor eine Löschung technisch möglich wäre. Der Schaden ist damit nicht behebbar, sondern nur begrenzbar – und zwar ausschließlich vorher.

Das macht jeden gespeicherten Datensatz zu einer Verbindlichkeit. Ausweisscans, Gehaltsabrechnungen und IBANs sind in Kombination ein vollständiger Identitätsbaukasten: Sie ermöglichen Kontoeröffnungen, Bestellbetrug und Vertragsabschlüsse im Namen der Betroffenen, noch Jahre nach dem Vorfall. Zugangsdaten wirken dagegen sofort, sofern sie irgendwo unverändert weiterverwendet werden.

Das BSI weist darauf hin, dass Informationen aus Datenlecks Phishing-Nachrichten deutlich glaubwürdiger machen: echte Namen, echte Zuständigkeiten, echte Vorgangsdaten. Zusätzlich warnt die Behörde vor Hack-and-Leak-Operationen, bei denen authentische Inhalte aus dem Zusammenhang gelöst oder mit manipuliertem Material vermischt werden – kurz vor der Wahl zum Berliner Abgeordnetenhaus am 20. September 2026 ein wirksames Muster.

Für Unternehmen ist die Übertragung unmittelbar. Die DSGVO benennt die Pflichten konkret:

Artikel 5 - Datenminimierung und Speicherbegrenzung: nur aufbewahren, was gebraucht wird.
Artikel 32 - angemessene technische und organisatorische Maßnahmen, nachweisbar dokumentiert.
Artikel 33 - Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnis.
Artikel 34 - Benachrichtigung der Betroffenen bei hohem Risiko.

Wer Daten nicht mehr vorhält, muss sie nicht schützen, nicht melden und kann sie nicht verlieren. Datenschutz ist damit keine Formalie der Rechtsabteilung, sondern die wirksamste Begrenzung des Schadensradius.

Empfehlungen für IT-Admins

Datenbestände inventarisieren - wissen, wo personenbezogene Daten, Ausweiskopien und Vertragsunterlagen liegen. Ohne Inventar ist ein Datenleck weder bewertbar noch meldbar.
Löschkonzept durchsetzen - Aufbewahrungsfristen technisch erzwingen statt organisatorisch hoffen. Altbestände auf Dateiservern erklären ein Vielfaches der erwarteten Datenmenge.
Zugriffe segmentieren - Berechtigungen auf Fachbereiche begrenzen, offene Freigaben und alte Gruppenmitgliedschaften abbauen. Ein gekapertes Konto darf nicht das gesamte Dateiarchiv erreichen.
Geheimnisse aus Dokumenten entfernen - Passwörter, VPN-Profile und Schlüssel gehören in einen Passwort-Manager, nicht in Tabellen auf dem Dateiserver.
Verschlüsselung dort einsetzen, wo sie wirkt - Festplattenverschlüsselung schützt nicht gegen exfiltrierte Dateien. Wirksam sind Datei- und Archivverschlüsselung.
Fernzugänge härten - VPN- und Portalzugänge ausschließlich mit Multi-Faktor-Authentifizierung; bei Leak-Verdacht Kennwörter zurücksetzen und aktive Sitzungen widerrufen.
Abfluss erkennbar machen - ungewöhnlich große Lese- und Kopiervorgänge auf Dateiservern alarmieren. In Berlin lagen zwischen Abfluss und Netztrennung Tage.
Schatten-IT einsammeln - was niemand betreut, wird auch nicht gepatcht. Systeme außerhalb des zentralen Betriebs sind hier ein Kernthema.

Hinweise zum Vorgehen bei Betroffenheit

1

Zugangsdaten invalidieren

Passwörter potenziell betroffener Konten zurücksetzen, Sitzungen und Tokens widerrufen, wiederverwendete Passwörter aufspüren.

2

Meldewege klären

Vorfall bewerten, Fristen nach Artikel 33 und 34 DSGVO einhalten, Datenschutzbeauftragten früh einbinden.

3

Belegschaft warnen

Konkret vor Anrufen und Mails mit korrekten Personendaten warnen; Aufforderungen über einen zweiten Kommunikationsweg verifizieren.

4

Missbrauch verfolgen

Bei Identitätsmissbrauch Strafanzeige erstatten; das Land Berlin verweist Betroffene ausdrücklich auf die Internetwache der Polizei Berlin.

Bedeutung für Geschäftsführung und Entscheider

Der Fall Berlin ist teuer, obwohl kein Lösegeld gezahlt wurde. Die Kosten entstehen an anderer Stelle: Wochen eingeschränkter Handlungsfähigkeit in zwei Ressorts, Nacharbeiten nach jedem neuen Datenpaket, Einschränkungen in Fachverfahren mit direkter Wirkung auf Bürger sowie ein dauerhafter Vertrauensschaden.

Das ist die realistische Kostenstruktur eines Datenabflusses, und sie gilt für Unternehmen genauso.

Entscheidend ist der Unterschied zur reinen Verfügbarkeitsfrage. Für Ausfälle gibt es Backups und definierte Wiederanlaufzeiten – alles planbar. Für abgeflossene Daten gibt es keinen Wiederanlauf. Die einzige Steuerungsgröße ist, was zum Zeitpunkt des Angriffs überhaupt greifbar ist. Darüber entscheidet nicht die IT allein, sondern die Freigabe von Löschkonzepten, Aufbewahrungsfristen und Berechtigungsmodellen.

Der Aufwand ist überschaubar, aber ungleich verteilt. Multi-Faktor-Authentifizierung für Fernzugänge und das Entfernen von Passwörtern aus Dokumenten sind Arbeiten von Tagen. Ein belastbares Löschkonzept und ein aufgeräumtes Berechtigungsmodell sind Vorhaben von Monaten – und genau der Teil, der im Schadensfall zählt. Hinzu kommt die regulatorische Seite: Aufsichtsbehörden prüfen nach einem Datenleck nicht den Angriff, sondern die vorher getroffenen Maßnahmen.

Die Frage an die Geschäftsführung lautet deshalb nicht nur „Wie schnell sind wir wieder handlungsfähig?“, sondern „Was genau könnte ein Angreifer heute bei uns mitnehmen?“.

FAQ zum Datenleck Berlin

Sind Bürger vom Datenleck Berlin betroffen?

Ja, das ist möglich. Nach Auswertungen sollen die Pakete Personalunterlagen, Ausweisscans und Vertragsdaten enthalten-. Das Land Berlin hält Auswirkungen auf Bürger für möglich, etwa in Fachverfahren wie dem Wohngeld. Eine belastbare öffentliche Liste der Betroffenen liegt bislang nicht vor.

Was ist Rhysida?

Rhysida ist eine seit mehreren Jahren aktive Gruppe, die nach dem Modell Ransomware-as-a-Service arbeitet. Typisch ist die doppelte Erpressung: Daten werden abgezogen und bei Nichtzahlung veröffentlicht. Für eine politische Motivation gibt es laut IT-Administrator keine Belege.

Warum hilft ein Backup gegen ein Datenleck nicht?

Ein Backup stellt Verfügbarkeit wieder her, nicht Vertraulichkeit. Sobald Daten kopiert und veröffentlicht sind, ist der Vorgang irreversibel - Löschansprüche erreichen Kopien im Darknet nicht. Wirksam sind daher nur vorbeugende Maßnahmen wie Datenminimierung, Verschlüsselung und Zugriffsbegrenzung.

Welche Fristen gelten nach einem Datenleck?

Nach Artikel 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde binnen 72 Stunden zu melden. Besteht ein hohes Risiko für die Betroffenen, kommt nach Artikel 34 deren unverzügliche Benachrichtigung hinzu. Die Frist läuft ab Kenntnis des Vorfalls, nicht ab abgeschlossener Analyse.

Woran erkennt man Phishing nach einem Datenleck?

Meist an nichts Offensichtlichem - genau das ist das Problem. Laut BSI können korrekte Namen, Zuständigkeiten und Vorgangsdaten aus Datenlecks stammen. Prüfen Sie Aufforderungen zu Zahlungen oder Datenfreigaben über einen zweiten, selbst gewählten Kommunikationsweg.

Fazit

1,4 Millionen veröffentlichte Dateien und ein zweites Paket mit Zugangsdaten machen das Datenleck Berlin zu einem Lehrstück über den Unterschied zwischen Ausfall und Abfluss. Der Ausfall war nach Tagen beherrschbar, der Abfluss bleibt es dauerhaft nicht. Wirksam war rückblickend nur, was vor dem Angriff entschieden wurde: welche Daten überhaupt gespeichert waren, wer sie erreichen konnte und wie Fernzugänge geschützt waren. Die Konsequenz ist unbequem einfach – Daten, die nicht mehr vorhanden sind, können nicht veröffentlicht werden; für alles Übrige zählen Verschlüsselung, Segmentierung und Multi-Faktor-Authentifizierung. Die Frage ist nicht, ob die eigene Umgebung interessant genug für einen Angriff ist, sondern wie viel bei einem erfolgreichen Zugriff mitgehen würde.

Weitere interessante Beiträge

mars-News

Cyber Security Workshop für Schulen und Bildungseinrichtungen

20. August 2026

Zum Blogbeitrag

IT-News

PHP Sicherheitslücke PHP2Shell: Updates für alle Webserver

21. Oktober 2026

Zum Blogbeitrag

mars-News

mars Events - Sommer / Herbst 2026

30. September 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Datenleck Berlin: 1,4 Millionen Dateien aus dem Landesnetz im Darknet erschien zuerst auf mars solutions GmbH.

Exchange Sicherheitslücke CVE-2026-62911: 85 Prozent der Server ungepatcht

Technischer Support — Thu, 03 Sep 2026 06:40:00 +0000

Exchange Sicherheitslücke CVE-2026-62911: 85 Prozent der Server ungepatcht

Technischer Support
September 3, 2026
08:40

Für die Exchange Sicherheitslücke CVE-2026-62911 liegt seit dem 28. August 2026 ein öffentlicher Exploit auf GitHub. Nach Zahlen des CERT-Bund waren zu diesem Zeitpunkt rund 85 Prozent der On-Premises-Exchange-Server in Deutschland weiterhin angreifbar, obwohl der Patch seit dem August-Patchtag bereitsteht. Angreifer können ohne gültige Zugangsdaten auf beliebige Postfächer zugreifen, Mails lesen und versenden sowie Anhänge herunterladen. Eine Behelfslösung gibt es nicht, nur das Sicherheitsupdate hilft.

Das Wichtigste in Kürze

CVE-2026-62911 ist ein Authentifizierungs-Bypass in Microsoft Exchange Server, CVSS 8.0 nach Microsoft und 8.8 nach der Zero Day Initiative.
Der Exploit-Code ist seit dem 28.08.2026 öffentlich; bestätigte Angriffe in der Praxis sind bislang nicht bekannt.
Betroffen sind Exchange Server Subscription Edition, Exchange 2019 und Exchange 2016; der Fix stammt aus dem August-Patchtag 2026.
Rund 85 Prozent der deutschen On-Premises-Server sind laut CERT-Bund weiterhin ungepatcht, das BSI benachrichtigt Netzbetreiber seit dem 14.08.2026.
Die Exchange Emergency Mitigation greift hier nicht; ohne Update bleibt nur, den Zugriff aus dem Internet einzuschränken.

So funktioniert die Exchange Sicherheitslücke

CVE-2026-62911 ist ein Authentifizierungs-Bypass durch Capture-Replay, in der Schwachstellen-Systematik als CWE-294 geführt. Der Angriff setzt am MRSProxy-Endpunkt an, den Exchange für das Verschieben von Postfächern zwischen Servern nutzt.

Nach der Analyse von Frank Zöchling (Frankys Web) leiten Angreifer die Authentifizierung des Serverkontos an diesen Endpunkt weiter. Exchange akzeptiert das zuvor mitgeschnittene Anmeldematerial und stellt daraufhin erweiterte Rechte aus. Anschließend lassen sich beliebige Postfächer öffnen, unabhängig davon, welchem Benutzer sie gehören: Nachrichten lesen, Nachrichten in fremdem Namen versenden, Anhänge herunterladen.

Microsoft bewertet die Lücke mit CVSS 8.0 und stuft sie als Rechteausweitung ein. Die Zero Day Initiative von Trend Micro, die den Fehler gemeldet hat, kommt auf 8.8 und hat der Einstufung von Microsoft öffentlich widersprochen, die Ausnutzbarkeit sei nicht belegt.

Die Herkunft erklärt die Brisanz: Der Fehler wurde bei Pwn2Own Berlin 2026 gezeigt, dort als Teil einer Kette aus drei Schwachstellen. Zusammengenommen führte die Kette zur Codeausführung mit SYSTEM-Rechten auf dem Exchange-Server. Für sich genommen ist CVE-2026-62911 also eine Rechteausweitung, in Kombination mit weiteren Lücken wird daraus die vollständige Übernahme eines Servers, der aus dem Internet erreichbar ist.

Zahlen, Daten, Fakten

Seit dem 14.08.2026 benachrichtigt das BSI deutsche Netzbetreiber über verwundbare Systeme in ihren Netzen. Die Zahlen zum Stand vom 31.08.2026:

der Server in Deutschland ungepatcht

0 %

verwundbare IP-Adressen weltweit

davon in Deutschland

Server mit ESU-Update bekannt

Warum viele Exchange-Server ungepatcht bleiben

Die Quote von 85 Prozent wirkt zunächst nach Nachlässigkeit. Der eigentliche Grund liegt tiefer: Der reguläre Support für Exchange Server 2016 und 2019 ist im Oktober 2025 ausgelaufen. Sicherheitsupdates für diese Versionen gibt es seither ausschließlich über das kostenpflichtige Programm Extended Security Updates.

Wie selten dieser Weg gegangen wird, zeigt die Zahl des CERT-Bund: Neun Server in ganz Deutschland sind bekannt, auf denen ein ESU-Update tatsächlich eingespielt ist. Wer also weiterhin Exchange 2016 oder 2019 betreibt und kein ESU gebucht hat, bekommt den Fix für CVE-2026-62911 gar nicht erst angeboten.

Zum Hintergrund

Bereits Ende Oktober 2025 kam das BSI zu dem Ergebnis, dass rund 92 Prozent von etwa 33.000 On-Premises-Exchange-Servern in Deutschland auf nicht mehr unterstützten Versionen liefen, mit aus dem Internet erreichbarem Outlook on the Web. Der aktuelle Fall trifft also auf einen Bestand, der schon vorher überaltert war.

Dazu kommt der Zeitdruck: Zwischen dem Patchtag im August und dem öffentlichen Exploit lagen rund zwei Wochen. Wer Exchange-Updates nach dem üblichen Muster erst nach einer Beobachtungsphase einspielt, war zum Zeitpunkt der Veröffentlichung noch nicht fertig.

Patchstände gegen CVE-2026-62911

Abgesicherte Build-Nummern gegen CVE-2026-62911
Exchange-Version	Build	Update
Subscription Edition RTM	15.2.2562.46	KB5121573
Exchange 2019 CU15	15.2.1748.49	KB5121574
Exchange 2019 CU14	15.2.1544.44	KB5121575
Exchange 2016 CU23	15.1.2507.72	KB5121576

Maßgeblich ist die Buildnummer, nicht das Datum der letzten Update-Installation. Für Exchange 2016 und 2019 setzt die Installation eine gültige ESU-Lizenzierung voraus; ohne sie steht das Update nicht zur Verfügung.

Keine Emergency Mitigation

Die Exchange Emergency Mitigation, mit der Microsoft in früheren Fällen eine Übergangslösung angeboten hat, greift bei dieser Lücke nicht. Es gibt keinen Workaround, der das Update ersetzt.

Sofortmaßnahmen gegen die Exchange Sicherheitslücke

Den Stand aller Server liefert die Exchange Management Shell:

Get-ExchangeServer | Format-List Name, AdminDisplayVersion

1

Buildnummer prüfen

Die Ausgabe des Befehls gegen die Tabelle oben abgleichen, Server für Server.

2

Update einspielen

Das August-Sicherheitsupdate installieren. Bei Exchange 2016 und 2019 zuvor klären, ob eine ESU-Lizenzierung vorliegt; fehlt sie, ist ihre Beschaffung der erste Schritt.

3

Zugriff aus dem Internet einschränken

Solange ein Server ungepatcht bleibt, den Zugriff auf die Exchange-Webdienste auf vertrauenswürdige Quell-IP-Adressen begrenzen oder ihn über ein VPN führen. Das ist die ausdrückliche Empfehlung des BSI.

4

Protokolle sichten

Die IIS-Logs auf auffällige Zugriffe auf den MRSProxy-Endpunkt und auf Postfachzugriffe außerhalb der üblichen Zeiten und Netze prüfen.

5

Migration bewerten

Bei Exchange 2016 und 2019 die Frage beantworten, ob ESU verlängert wird oder ob der Umstieg auf die Subscription Edition beziehungsweise nach Exchange Online ansteht. Diese Entscheidung wird bei jeder weiteren Lücke erneut fällig.

6

Postfachrechte kontrollieren

Nach dem Patchen prüfen, ob Postfachregeln, Weiterleitungen oder Stellvertreterrechte angelegt wurden, die niemand kennt.

Bedeutung für Geschäftsführung und Entscheider

Ein Exchange-Server, der aus dem Internet erreichbar ist, ist der Zugang zur gesamten Geschäftskorrespondenz. Gelingt der Zugriff, sind Angebote, Verträge, Personalunterlagen und Rechnungsverläufe offen einsehbar. Aus mitgelesenen Mailverläufen entsteht typischerweise Rechnungsbetrug, weil Angreifer sich in laufende Vorgänge einklinken und Bankverbindungen austauschen. Sobald personenbezogene Daten betroffen sind, greift die Meldepflicht nach DSGVO innerhalb von 72 Stunden.

Der wirtschaftlich unangenehme Teil ist nicht das Update, sondern die Frage dahinter. Exchange 2016 und 2019 sind seit Oktober 2025 ohne regulären Support. Wer sie weiterbetreibt, zahlt für Extended Security Updates und bekommt dafür nur Zeit, keine Zukunft. Die neun bekannten ESU-Installationen in ganz Deutschland zeigen, dass diese Rechnung kaum jemand aufmacht: Der Regelfall ist ein Server, der weiterläuft und keine Sicherheitsupdates mehr erhält.

Für die Geschäftsführung stellen sich damit zwei getrennte Entscheidungen. Kurzfristig: Ist unser Exchange auf dem aktuellen Stand, und wenn nein, bis wann? Mittelfristig: Bleiben wir bei Exchange on premises mit ESU-Kosten, wechseln wir auf die Subscription Edition oder gehen wir nach Exchange Online? Die zweite Frage lässt sich planen. Sie zu verschieben bedeutet, sie bei jeder weiteren Lücke unter Zeitdruck erneut zu stellen.

FAQ zur Exchange Sicherheitslücke

Wird CVE-2026-62911 bereits aktiv ausgenutzt?

Bestätigte Angriffe sind bislang nicht bekannt. Öffentlicher Exploit-Code liegt seit dem 28.08.2026 auf GitHub, und mehr als 21.000 verwundbare Server sind aus dem Internet erreichbar. Fachleute rechnen deshalb damit, dass aus Scans in kurzer Zeit Angriffe werden.

Betrifft die Lücke auch Exchange Online?

Nein. Betroffen sind ausschließlich On-Premises-Installationen: Exchange Server Subscription Edition, Exchange 2019 und Exchange 2016. Wer vollständig in Exchange Online arbeitet, muss hier nichts tun.

Wir betreiben Exchange 2016 ohne ESU. Was jetzt?

Für diese Konstellation steht kein Update bereit. Kurzfristig hilft nur, den Zugriff aus dem Internet zu unterbinden oder über ein VPN zu führen. Parallel gehören die ESU-Beschaffung und die Migration auf den Tisch.

Reicht die Exchange Emergency Mitigation als Übergang?

Nein. Für diese Lücke gibt es keine wirksame Entschärfung über die Emergency Mitigation. Ausschließlich das Sicherheitsupdate schließt sie.

Woran erkennen wir, ob unser Server angegriffen wurde?

Prüfen Sie die IIS-Protokolle auf Zugriffe auf den MRSProxy-Endpunkt sowie die Postfachprotokolle auf Zugriffe außerhalb üblicher Zeiten und Netze. Auffällig sind außerdem neu angelegte Postfachregeln, Weiterleitungen und Stellvertreterrechte. Fehlende Spuren sind allerdings kein Beweis dafür, dass nichts passiert ist.

Fazit

Die Exchange Sicherheitslücke CVE-2026-62911 ist ein Lehrstück über den Unterschied zwischen verfügbarem und eingespieltem Patch. Der Fix liegt seit dem August-Patchtag vor, zwei Wochen später war der Exploit öffentlich, und trotzdem blieben nach Zahlen des CERT-Bund rund 85 Prozent der deutschen Server angreifbar. Wer Exchange on premises betreibt, sollte heute die Buildnummer prüfen und nicht auf die nächste Wartungsphase warten, denn eine Behelfslösung existiert nicht. Der Fall zeigt zugleich, dass die eigentliche Entscheidung eine andere ist: Ein Mailserver ohne regulären Support ist kein Zustand, den man verwaltet, sondern einer, den man beendet.

Weitere interessante Beiträge

IT-News

Exchange Online - EWS Abschaltung 2026

11. August 2026

Zum Blogbeitrag

IT-News

NIS-2-Registrierung: Frist abgelaufen, Lücke bleibt

5. August 2026

Zum Blogbeitrag

IT-News

OWAReaper: Half-Click-Exploit übernimmt Exchange-Postfächer

31. Juli 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Exchange Sicherheitslücke CVE-2026-62911: 85 Prozent der Server ungepatcht erschien zuerst auf mars solutions GmbH.