mars solutions GmbH

Outlook Störung: Microsoft 365 seit Donnerstagabend weltweit gestört

Technischer Support — Fri, 13 Nov 2026 06:53:29 +0000

Outlook Störung: Microsoft 365 seit Donnerstagabend weltweit gestört

Technischer Support
November 13, 2026
07:53

Seit Donnerstagabend, dem 12. November 2026, legt eine Outlook Störung weltweit den Mailverkehr vieler Unternehmen lahm: Allein bei Downdetector gingen gegen 19 Uhr knapp 130.000 Problemmeldungen ein. Betroffen sind neben Exchange Online auch Teams, SharePoint, Copilot, Intune und Defender XDR. Zum Stand Freitag, 13. November, 07:00 Uhr, ist die Störung nicht behoben – der zweite weltweite Ausfall von Microsoft 365 innerhalb von knapp elf Wochen.

Das Wichtigste in Kürze

Die Outlook Störung begann am 12.11.2026 gegen 19 Uhr und dauerte am Freitagmorgen, 07:00 Uhr, weiter an
Microsoft führt den Vorfall unter den Kennungen EX1550543 und MO1550821 im Microsoft 365 Admin Center
Potenziell betroffen sind rund ein Dutzend Dienste, darunter Exchange Online, Teams, SharePoint, Copilot, Intune, Purview und Defender XDR
Ursache ist laut Microsoft der Ausfall ungewöhnlich vieler Server, die an automatisierten Health-Checks scheitern; die verbleibende Infrastruktur ist dadurch überlastet
Die Ursache liegt bei Microsoft: Admins verfolgen am besten die Statusseite, lassen Outlook-Profile unverändert und prüfen nach der Wiederherstellung den Mailfluss

So verlief die Outlook Störung

Kurz vor 19 Uhr am Donnerstagabend stiegen die Störungsmeldungen zu Outlook, Teams, OneDrive und Copilot sprunghaft an. Die ersten Berichte kamen laut heise aus den USA. Microsoft sprach zunächst von Problemen mit Exchange-Postfächern in Nord- und Südamerika. Kurz darauf erweiterte das Unternehmen den Kreis: Die Störung könne Nutzer von Microsoft 365 weltweit treffen.

Gegen 20 Uhr meldete der Account Microsoft 365 Status, man teste eine Konfigurationsänderung und starte parallel alle betroffenen Server neu. Gegen 23 Uhr konnte Exchange Online laut heise wieder eingehende E-Mails verarbeiten, je nach Region mit Verzögerungen. Kurz vor Mitternacht räumte Microsoft ein, dass die bisherigen Maßnahmen nicht die erwartete Entlastung gebracht hatten.

In der Nacht brachte Microsoft Teile der Infrastruktur wieder ans Netz. Gegen 3 Uhr meldete der Konzern laut tagesschau „positive Ergebnisse“, wenig später folgte der Rückschlag: Die wieder gestarteten Server brachen nach Angaben von Dr. Windows unter der zusätzlichen Last erneut zusammen. Am Freitagmorgen verschlechterte sich die Lage noch einmal. Outlook Classic bleibt in vielen Umgebungen beim Start mit der Meldung „Profil wird geladen“ hängen, das neue Outlook meldet fehlende Berechtigungen.

Die Outlook Störung in Zahlen

Meldungen zu Outlook bei Downdetector gegen 19 Uhr

ca. 0

Meldungen noch gegen 22:30 Uhr

ca. 0

Microsoft-365-Dienste laut Statusseite potenziell betroffen

rund 0

Dauer bis zum Redaktionsschluss am Freitag, 07:00 Uhr

0 Stunden

weltweite Microsoft-365-Ausfälle innerhalb von elf Wochen (31.08. und 12.11.2026)

Ursache der Outlook Störung laut Microsoft

Nach Microsofts Angaben ist eine ungewöhnlich große Zahl an Servern unerwartet ausgefallen; ein allgemeiner Anstieg des Datenverkehrs war nicht der Auslöser. Die betroffenen Server bestehen automatisierte Zustandsprüfungen (Health-Checks) nicht und werden daraufhin aus dem Betrieb genommen. Ihre Last verlagert sich auf die verbleibenden Systeme, die dadurch ebenfalls an ihre Grenzen kommen.

Im Lauf der Nacht wurde Microsoft konkreter: Ein Kernprozess auf den betroffenen Servern wird überlastet, die Server reagieren nicht mehr und zeigen eine erhöhte Prozessorlast. Die fehlerhaften Health-Checks gehen nach bisherigem Stand vermutlich auf eine bestimmte Komponente zurück, die die Serverintegrität überwacht. Microsoft prüfte zudem, ob die Rücknahme einer kleinen Zahl kürzlich eingespielter Konfigurationsänderungen die Erholung beschleunigt. Einen eindeutigen Auslöser hat der Konzern bislang nicht benannt.

Wie Health-Checks eine Kaskade auslösen

Health-Checks sind automatische Selbsttests, mit denen ein Cloud-Dienst fehlerhafte Server erkennt und vom Netz nimmt. Schlagen diese Prüfungen fälschlich bei sehr vielen Servern gleichzeitig an, schaltet sich ein Teil der Infrastruktur selbst ab. Die übrigen Server übernehmen die Last, geraten in Überlast und fallen ebenfalls aus – ein Kaskadeneffekt, der sich nur schrittweise auflösen lässt.

Als Gegenmaßnahmen hat Microsoft alle Deployments und Konfigurationsänderungen gestoppt, verteilt den Datenverkehr weltweit um und isoliert Teile der Infrastruktur, um sie neu zu starten und behutsam wieder zu belasten. Zusätzlich prüft der Konzern, ob sich einzelne Regionen eigenständig erholen, wenn sie nur noch Datenverkehr aus der eigenen Region verarbeiten.

Outlook Störung trifft ein Dutzend Dienste

Auf der Microsoft-Statusseite sind neben Exchange Online auch Microsoft Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, Defender for Office 365, Planner, To Do, Intune, mehrere Purview-Dienste (unter anderem Data Loss Prevention und automatische Klassifizierung), Power BI und das Microsoft 365 Apps Admin Center als potenziell betroffen aufgeführt. Wie stark einzelne Dienste ausfallen, ist je nach Region und Tenant unterschiedlich.

Für den Betrieb bedeutet das mehr als fehlende E-Mails. Intune-Richtlinien und Compliance-Prüfungen laufen womöglich nicht wie gewohnt, Sicherheitsfunktionen in Defender und Purview arbeiten eingeschränkt. Nach Leserberichten in Günter Borns Blog ist die Outlook-App auf Smartphones auch bei Exchange-Servern im eigenen Haus betroffen, weil die App ihre Daten über Microsofts Cloud abruft. Auch das Journaling an externe Archivpostfächer stockt in einzelnen Umgebungen.

Wichtig für IT-Admins

Das Microsoft 365 Admin Center war zeitweise selbst nicht erreichbar. Microsoft verweist für diesen Fall auf die Statusseite status.cloud.microsoft und deren RSS-Feed sowie auf den X-Account @MSFT365Status.

Empfehlungen für IT-Admins zur Outlook Störung

Den Ausfall beheben kann nur Microsoft. Admins sorgen in dieser Zeit dafür, dass keine zusätzlichen Probleme entstehen, und prüfen nach der Wiederherstellung gezielt:

Statusquelle festlegen

Die Vorfälle EX1550543 und MO1550821 im Admin Center verfolgen, ersatzweise status.cloud.microsoft. So ist schnell geklärt, ob ein Fehler bei Microsoft oder im eigenen Netz liegt.

Keine lokalen Reparaturversuche

Outlook-Profile nicht neu anlegen, Konten nicht entfernen und Office nicht neu installieren. Neu angelegte Profile müssen nach der Wiederherstellung das gesamte Postfach neu synchronisieren und belasten Leitungen und Support zusätzlich.

Belegschaft informieren

Kurz über einen Kanal außerhalb von Microsoft 365 mitteilen, dass es sich um eine weltweite Störung handelt. Das verhindert eine Flut von Einzelanfragen.

Dringende Kommunikation umleiten

Für zeitkritische Abstimmungen Telefon oder einen vorab festgelegten zweiten Kanal nutzen.

Mailfluss nach der Wiederherstellung prüfen

Per Nachrichtenablaufverfolgung (Message Trace) kontrollieren, ob erwartete eingehende E-Mails angekommen sind, und auf Unzustellbarkeitsberichte achten. Sendende Mailserver wiederholen Zustellversuche in der Regel über Stunden bis Tage, verlorene Nachrichten sind deshalb die Ausnahme.

Folgedienste kontrollieren

Journaling und Archivierung, Intune-Compliance und Defender-Warnungen auf Lücken während des Ausfallzeitraums prüfen.

Wie sich ein zweiter Kommunikationsweg, ein lesender Zugriff auf ältere Mails und ein festes Vorgehen für den Ausfalltag vorbereiten lassen, haben wir nach dem Ausfall vom 31. August ausführlich beschrieben: Microsoft 365 Ausfall: zwölf Stunden ohne Mail, Teams und SharePoint.

Bedeutung für Geschäftsführung und Entscheider

Zwei weltweite Ausfälle innerhalb von knapp elf Wochen zeigen, dass auch große Cloud-Plattformen nicht ausfallfrei arbeiten. Microsoft sichert für die meisten Microsoft-365-Dienste eine Verfügbarkeit von 99,9 Prozent pro Monat zu. Das entspricht rechnerisch rund 43 Minuten Ausfall im Monat – die aktuelle Störung liegt bereits um ein Vielfaches darüber. Gutschriften aus dem Service Level Agreement gibt es nur auf Antrag; Bedingungen und Fristen regelt das SLA für Microsoft-Onlinedienste.

Wirtschaftlich wiegt der Ausfall schwerer als die Gutschrift. Wenn E-Mail, Chat, Dateiablage und Teile der Sicherheitsüberwachung gleichzeitig fehlen, stehen Vertrieb, Kundenservice und Abstimmungen still. Entscheidend ist deshalb, ob es für einen solchen Tag ein abgestimmtes Vorgehen gibt: Wer informiert die Belegschaft, über welchen Kanal, und welche Prozesse laufen notfalls ohne E-Mail weiter?

Wirksamer als ein Plattformwechsel ist es, kritische Abläufe zu kennen, einen zweiten Kommunikationsweg bereitzuhalten und Notfallpläne so abzulegen, dass sie auch ohne Microsoft 365 erreichbar sind. Der Aufwand dafür ist gering im Vergleich zu einem ungeplanten Stillstand.

FAQ zur Outlook Störung

Gehen E-Mails während der Outlook Störung verloren?

In der Regel nicht. Sendende Mailserver halten Nachrichten zurück und wiederholen die Zustellung über Stunden bis Tage. Exchange Online verarbeitete laut heise bereits am Donnerstagabend wieder eingehende E-Mails, teils mit Verzögerung. Nach der Wiederherstellung lohnt sich trotzdem ein Blick in die Nachrichtenablaufverfolgung.

Hilft es, das Outlook-Profil neu anzulegen?

Nein. Die Ursache liegt in Microsofts Rechenzentren und nicht auf dem eigenen Rechner. Ein neues Profil erzeugt nach der Wiederherstellung zusätzlich eine vollständige Neusynchronisierung des Postfachs.

Sind auch Exchange-Server im eigenen Haus betroffen?

Teilweise. Der lokale Exchange-Server selbst ist nicht betroffen. Die Outlook-App auf Smartphones ruft ihre Daten aber über Microsofts Cloud ab und kann deshalb auch bei lokalen Postfächern ausfallen.

Wo finden Administratoren verlässliche Informationen?

Im Microsoft 365 Admin Center unter den Kennungen EX1550543 und MO1550821. Ist das Admin Center nicht erreichbar, liefern status.cloud.microsoft, der zugehörige RSS-Feed und der X-Account @MSFT365Status den aktuellen Stand.

Haben Unternehmen Anspruch auf eine Entschädigung?

Ja, sofern ein Dienst die im SLA zugesicherte monatliche Verfügbarkeit von 99,9 Prozent unterschreitet. Administratoren müssen die Gutschrift aktiv beantragen; Folgeschäden deckt sie nicht ab.

Fazit

Die Outlook Störung vom 12. und 13. November 2026 trifft Microsoft 365 in der Breite: von Exchange Online über Teams bis zu Intune und Defender. Auslöser ist nach Microsofts Angaben eine Kettenreaktion aus fehlschlagenden Health-Checks und überlasteten Servern, die sich bis Freitagmorgen nicht stabil beheben ließ. Die Folgen begrenzen Unternehmen mit einer verlässlichen Statusquelle, ohne hektische Reparaturversuche an den Clients und mit einer sauberen Prüfung des Mailflusses danach. Der zweite große Ausfall binnen weniger Wochen ist zudem ein guter Anlass, das eigene Vorgehen für einen Tag ohne Microsoft 365 einmal durchzuspielen.

Weitere interessante Beiträge

IT-News

Kritische Sophos UTM Sicherheitslücke: Firewall ohne Anmeldung angreifbar

3. November 2026

Zum Blogbeitrag

IT-News

Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack

2. November 2026

Zum Blogbeitrag

mars-News

Cyber Security Workshop für Schulen und Bildungseinrichtungen

20. August 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Outlook Störung: Microsoft 365 seit Donnerstagabend weltweit gestört erschien zuerst auf mars solutions GmbH.

Phishing trotz MFA: So hebeln Angreifer den zweiten Faktor aus

Technischer Support — Thu, 12 Nov 2026 10:16:27 +0000

Phishing trotz MFA: So hebeln Angreifer den zweiten Faktor aus

Technischer Support
November 12, 2026
11:16

Ab Mitte August 2026 haben Angreifer über Einladungen im Google-Kalender die Sitzungen von Firmenkonten übernommen, obwohl die Betroffenen eine Mehrfaktor-Anmeldung (MFA) nutzten. Allein der Sicherheitsanbieter Material Security hat nach eigenen Angaben in einem Monat 68.676 Nachrichten dieser Kampagne abgefangen.

Phishing trotz MFA ist damit zur verbreiteten Methode geworden: Echtzeit-Proxys und Gerätecode-Phishing brauchen keine gefälschte Domain mehr. Sie setzen im Moment der Anmeldung an und laufen über echte Seiten von Google und Microsoft.

Das Wichtigste in Kürze

Bei Phishing trotz MFA erbeuten Angreifer die fertige Anmeldesitzung statt nur das Passwort. Der zweite Faktor wird dabei vom Opfer selbst bestätigt.
Die Kampagne, die Material Security „Operation CloudFire“ nennt, nutzte Kalendereinladungen, Links auf echte Google-Adressen und einen Proxy vor der echten Google-Anmeldung.
Beim Gerätecode-Phishing gibt das Opfer einen vom Angreifer erzeugten Code auf der echten Microsoft-Seite ein und meldet damit dessen Gerät an.
Codes per SMS, aus Authenticator-Apps oder per Bestätigung in der App lassen sich in Echtzeit weiterreichen. Passkeys und FIDO2-Schlüssel sind an die echte Domain gebunden und schützen deshalb vor Proxy-Angriffen.
Microsoft empfiehlt, den Gerätecode-Flow in Entra ID per Conditional Access zu blockieren, wo er nicht gebraucht wird.

So lief das Kalender-Phishing ab

Die Kampagne soll bereits Mitte August 2026 gestartet sein und richtete sich gegen Unternehmenskonten bei Google. Als Köder dienten Einladungen im Google-Kalender, teils in Blindkopie verschickt. Oft kamen sie von Organisationen, mit denen die Empfänger bereits Kontakt hatten. Die Anlässe klangen alltäglich: eine neue Sprachnachricht, eine Ausschreibung, eine Zahlungserinnerung oder eine Vorladung. Der Absender-Check aus unserem Beitrag Phishing-Mails erkennen bleibt wichtig, stößt hier aber an Grenzen, weil die Absender echt waren.

Die Links in den Einladungen führten zunächst auf echte Google-Adressen, etwa über Googles eigene Weiterleitung, über share.google oder über Freigaben in Google Drive. Erst danach folgten eine Bot-Prüfung über Cloudflare Turnstile und eine Anmeldeseite, die sich erst im Browser des Opfers aufbaute. Automatische Scanner fanden dadurch nichts Auffälliges. Auch beim Consent-Phishing über Teams führen die Links auf echte Seiten, dort auf die Anmeldung von Microsoft.

Hinter der Anmeldeseite stand ein sogenannter Reverse Proxy, also ein Server, der zwischen dem Opfer und der echten Google-Anmeldung vermittelt. Das Opfer gab sein Passwort ein und bestätigte die echte Rückfrage von Google. Laut Material Security reichte der Proxy SMS-Codes, Codes aus Authenticator-Apps, Googles Zahlenabgleich und sogar die telefonische Kontowiederherstellung in Echtzeit weiter. Am Ende übernahmen die Angreifer die angemeldete Sitzung mit Zugriff auf Mail und Drive.

Die Kampagne gilt vorerst als beendet. Material Security hat die Infrastruktur nach eigenen Angaben über Missbrauchsmeldungen bei Cloudflare abschalten lassen und erwartet einen Nachfolger unter anderem Namen. Im Code fand sich außerdem ein noch unfertiger Zweig für Microsoft 365.

Wie Phishing trotz MFA funktioniert

Die Methode heißt in der Fachsprache Adversary-in-the-Middle (AiTM). Microsoft hat sie bereits 2022 beschrieben: Damals versuchte eine einzige Kampagne laut Microsoft, mehr als 10.000 Organisationen anzugreifen. Der Proxy zeigt dem Opfer die echte Anmeldeseite und greift dabei Passwort und Sitzungscookie ab. Mit diesem Cookie gilt der Angreifer anschließend als angemeldet. Anders als beim Password Spraying, bei dem Angreifer Passwörter durchprobieren, hilft hier auch ein starkes Passwort nicht.

Microsoft betont, dass darin keine Schwachstelle der MFA selbst liegt. Gestohlen wird die Sitzung nach der Anmeldung, und zwar unabhängig davon, mit welcher Methode sich der Nutzer angemeldet hat. Jeder Faktor, den ein Mensch abtippen oder bestätigen kann, lässt sich auf diese Weise weiterreichen.

Wichtig für IT-Admins

Ein abgegriffenes Sitzungscookie bleibt gültig, bis die Sitzung widerrufen wird. Ein neues Passwort allein beendet den unbefugten Zugriff deshalb nicht.

Gerätecode-Phishing in Microsoft 365

Eine zweite Methode nutzt eine reguläre Anmeldeart von Microsoft: den Gerätecode-Flow. Er ist für Geräte ohne Tastatur gedacht, etwa Konferenzsysteme. Das Gerät zeigt einen Code an, den der Nutzer auf einem zweiten Gerät auf der echten Microsoft-Seite eingibt und dort bestätigt.

Beim Gerätecode-Phishing erzeugt der Angreifer diesen Code selbst und schickt ihn dem Opfer, etwa verpackt in eine Einladung zu einem Teams-Meeting. Microsoft hat 2025 eine solche Kampagne der Gruppe Storm-2372 beschrieben, die Regierungen, Behörden und Unternehmen in Europa und Nordamerika ins Visier nahm. Gibt das Opfer den Code ein, meldet es das Gerät des Angreifers an. Dieser erhält Zugriffs- und Aktualisierungstoken und kann damit auf Mails und Dateien zugreifen.

Microsoft empfiehlt die Sperre

Auch hier sieht das Opfer nur echte Microsoft-Seiten. Microsoft stuft den Gerätecode-Flow deshalb als riskante Anmeldeart ein und empfiehlt, ihn zu blockieren, wo immer das möglich ist.

Zahlen, Daten, Fakten

Kennzahlen zu Phishing trotz MFA
Kennzahl	Wert
Abgefangene Nachrichten der Kalender-Kampagne in einem Monat	68.676
Missbrauchte Absenderadressen	8.570
Abgeschaltete Domains	897
Angegriffene Organisationen einer früheren AiTM-Kampagne (Microsoft 2022)	über 10.000

Die ersten drei Werte stammen von Material Security und beruhen nur auf Daten von Kunden, die der Weitergabe zugestimmt haben. Die tatsächlichen Zahlen dürften laut dem Anbieter höher liegen. Der letzte Wert stammt aus Microsofts Analyse von 2022.

Warum Passkeys gegen Phishing schützen

Passkeys und FIDO2-Sicherheitsschlüssel arbeiten mit einem kryptografischen Schlüsselpaar, das an die Adresse des Dienstes gebunden ist. Laut Microsoft gibt der Authentifikator seine Geheimnisse nur an die Seite heraus, bei der der Passkey registriert wurde, und nicht an einen Angreifer, der sich als diese Seite ausgibt. Eine Proxy-Seite unter fremder Adresse erhält damit keine gültige Anmeldung, die sie weiterreichen könnte. Auch Google nennt Passkeys deutlich sicherer gegen Phishing als Passwörter.

Für Microsoft 365 ist das Thema ohnehin auf dem Tisch: Microsoft beendet die SMS-Anmeldung in Entra ID am 1. Februar 2027 und stellt auf Passkeys um. Die Details stehen in unserem Beitrag SMS-Authentifizierung in Entra ID endet Anfang 2027.

Passkeys schützen nicht vor jedem Trick

Beim Gerätecode-Phishing meldet sich das Opfer auf der echten Microsoft-Seite an, auch mit Passkey, und gibt dort den Code des Angreifers frei. Dagegen hilft nur, den Gerätecode-Flow zu sperren. Ähnlich verhält es sich beim Consent-Phishing, bei dem einer fremden App Rechte eingeräumt werden.

Empfehlungen für IT-Admins

Phishing-resistente Anmeldung einführen

Passkeys oder FIDO2-Schlüssel zuerst für Konten mit Administratorrechten und für Mitarbeiter in Buchhaltung und Geschäftsführung einrichten, danach für alle.

Gerätecode-Flow blockieren

In Entra ID eine Conditional-Access-Richtlinie mit der Bedingung „Authentifizierungsflüsse“ und „Gerätecodefluss“ anlegen und den Zugriff sperren. Microsoft empfiehlt, die Richtlinie zuerst im Modus „Nur Bericht“ zu testen und Notfallkonten auszunehmen. Conditional Access setzt eine Lizenz für Entra ID P1 voraus.

Sitzungen schnell widerrufen können

Im Verdachtsfall reicht ein Passwortwechsel nicht. In Google Workspace setzen Admins unter „Verzeichnis > Nutzer > Sicherheit > Anmelde-Cookies“ die Cookies zurück. Für Microsoft 365 steht der Befehl im Kasten unten.

App-Freigaben prüfen

Nach einem Vorfall die OAuth-Freigaben des Kontos kontrollieren und unbekannte Apps entfernen. Angreifer nutzen übernommene Sitzungen gern, um sich dauerhaften Zugriff über eine App zu sichern.

Anmeldeprotokolle überwachen

Anmeldungen per Gerätecode, Anmeldungen aus ungewohnten Ländern und neue Postfachregeln gezielt auswerten. Je früher eine übernommene Sitzung auffällt, desto kleiner bleibt der Schaden.

Kalender in die Schulung aufnehmen

Kalendereinladungen landen oft ohne Prüfung im Kalender. Mitarbeiter sollten wissen, dass auch Einladungen und Freigaben bekannter Partner ein Köder sein können. Wie regelmäßige Schulungen und Phishing-Simulationen wirken, zeigt unser Beitrag Dein wichtigstes Sicherheits-Upgrade sitzt vor dem Bildschirm. Die wichtigsten Regeln für das Team fasst unsere Phishing-Checkliste auf einer Seite zusammen.

Sitzungen in Microsoft 365 beenden

Mit Microsoft Graph PowerShell lassen sich alle aktiven Anmeldesitzungen eines Kontos widerrufen. Der Nutzer muss sich danach neu anmelden, ein abgegriffenes Sitzungscookie wird ungültig:

# Alle aktiven Anmeldesitzungen eines Kontos widerrufen (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId "name@firma.de"

Phishing-Abwehr im laufenden IT-Betrieb

Die beschriebenen Maßnahmen wirken nur, wenn sie dauerhaft betreut werden: Richtlinien müssen gepflegt, Anmeldeprotokolle ausgewertet und im Ernstfall Sitzungen beendet werden. Wird der IT-Betrieb von einem Dienstleister mit Full Managed-IT gemanaged, kann das für die Phishing-Abwehr mehrere Vorteile haben:

Anmeldung und E-Mail-Schutz werden eingerichtet und laufend aktuell gehalten.
Auffälligkeiten bei Anmeldungen und auf den Geräten werden erkannt, bevor ein größerer Schaden entsteht.
Im Ernstfall ist klar, wer reagiert und übernommene Konten sperrt.
Das eigene Team wird entlastet und kann sich auf das Tagesgeschäft konzentrieren.

Bedeutung für Geschäftsführung und Entscheider

Mit der Einführung von MFA gilt das Thema Phishing in vielen Unternehmen als erledigt. Für Angriffe mit gestohlenen Passwörtern stimmt das weiterhin. Phishing trotz MFA zielt jedoch auf die Sitzung nach der Anmeldung, und der klassische Hinweis „auf die Absenderadresse achten“ greift zu kurz, wenn die Einladung von einem echten, aber übernommenen Konto eines Geschäftspartners stammt.

Die Folgen reichen vom Mitlesen im Postfach über Zahlungsbetrug mit geänderten Bankverbindungen bis zum Datenabfluss aus Cloud-Speichern. Sind personenbezogene Daten betroffen, gilt die Meldepflicht nach DSGVO innerhalb von 72 Stunden. Wer im Ernstfall wen informiert, sollte deshalb vorab feststehen, etwa mit unserer IT-Notfallkarte.

Der Aufwand für die Abwehr ist überschaubar. Die Sperre des Gerätecode-Flows ist eine einzelne Richtlinie. Die Umstellung auf Passkeys steht für Microsoft 365 bis Februar 2027 ohnehin an. Hinzu kommt eine kurze Unterweisung der Mitarbeiter, wie sie verdächtige Anmeldeaufforderungen erkennen. Wie das bei E-Mails gelingt, zeigt unser Beitrag Phishing-Mails erkennen. Welche technischen Filter gefälschte Mails schon vorher abfangen, beschreibt der Beitrag Phishing und Spam im Unternehmen.

FAQ zu Phishing trotz MFA

Ist MFA damit wirkungslos?

MFA bleibt ein wichtiger Schutz und stoppt die meisten Angriffe mit gestohlenen Passwörtern, etwa Password Spraying. Gegen Echtzeit-Proxys helfen aber nur Verfahren, die an die echte Domain gebunden sind, also Passkeys oder FIDO2-Schlüssel.

Woran erkenne ich eine Proxy-Anmeldeseite?

Am verlässlichsten an der Adresse in der Browserzeile, die nicht zum Dienst passt. Da die Links zunächst über echte Google- oder Microsoft-Adressen laufen, fällt das oft erst auf der Anmeldeseite auf. Melden Sie sich deshalb nie über einen Link aus einer Mail oder Einladung an, sondern rufen Sie den Dienst selbst auf.

Was ist Gerätecode-Phishing?

Beim Gerätecode-Phishing schickt der Angreifer einen Anmeldecode, den das Opfer auf der echten Microsoft-Seite eingibt. Damit meldet es unbemerkt das Gerät des Angreifers an. Microsoft empfiehlt, diese Anmeldeart zu sperren, wo sie nicht gebraucht wird.

Hilft ein neues Passwort nach einem Vorfall?

Ein neues Passwort reicht allein nicht aus. Eine übernommene Sitzung bleibt gültig, bis sie widerrufen wird. Admins sollten deshalb alle Sitzungen des Kontos beenden, App-Freigaben prüfen und erst danach das Passwort zurücksetzen.

Fazit

Phishing trotz MFA ist ein erprobtes Werkzeug: Die Angriffe laufen über echte Einladungen, echte Links und echte Anmeldeseiten und umgehen dabei jeden Faktor, den ein Mensch weiterreichen kann. Wirksam sind phishing-resistente Verfahren wie Passkeys, eine Sperre für den Gerätecode-Flow und die Fähigkeit, übernommene Sitzungen schnell zu beenden. Wer diese drei Punkte umsetzt, nimmt den beschriebenen Methoden die Grundlage. Material Security rechnet bereits mit einem Nachfolger der Kalender-Kampagne, dann womöglich auch für Microsoft 365.

Weitere interessante Beiträge

IT-News

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

7. September 2026

Zum Blogbeitrag

mars-News

Wir sind Hauptsponsor des TSG Salach: Heimvorteil in Sachen IT

11. September 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 Phishing trotz MFA: So hebeln Angreifer den zweiten Faktor aus erschien zuerst auf mars solutions GmbH.

OpenSSH Sicherheitslücke – SSHole (CVE-2026-123158)

Technischer Support — Tue, 10 Nov 2026 10:06:36 +0000

OpenSSH Sicherheitslücke – SSHole (CVE-2026-123158)

Technischer Support
November 10, 2026
11:06

Die OpenSSH Sicherheitslücke CVE-2026-123158, genannt „SSHole“, erlaubt Angreifern die Anmeldung an Konten, die eigentlich gar kein Passwort annehmen dürfen. Dafür genügt ein beliebiges Passwort mit 257 bis 1.024 Zeichen. Betroffen sind Linux-Systeme, die OpenSSH auf der C-Bibliothek musl ohne PAM betreiben, allen voran Alpine Linux. Weniger als neun Stunden nach der Veröffentlichung registrierte das Threat-Intelligence-Unternehmen Previdian die ersten Angriffe.

Das Wichtigste in Kürze

CVE-2026-123158 (CVSS 8.1) betrifft den SSH-Server von OpenSSH vor Version 10.6p2 auf Linux-Systemen mit musl libc, die Passwörter ohne PAM prüfen.
Konten mit gesperrtem Passwort, etwa root, reine Schlüssel-Konten oder der Standardbenutzer auf den Cloud-Images von Alpine, akzeptieren jedes Passwort mit 257 bis 1.024 Zeichen.
Debian, Ubuntu, Red Hat und andere Distributionen mit glibc sind nicht betroffen, ebenso Systeme mit PAM und der SSH-Server Dropbear.
Die Lücke wird bereits ausgenutzt: Bis zum 8. November 2026 zählte Previdian 20 Angriffsversuche von 13 IP-Adressen.
Abhilfe bringt OpenSSH 10.6p2 vom 5. November 2026; bis zum Update hilft es, die Anmeldung per Passwort abzuschalten.

So funktioniert die OpenSSH Sicherheitslücke

Unter Linux steht im Passwortfeld eines Kontos ein Hash des Passworts. Konten, die sich gar nicht per Passwort anmelden sollen, tragen dort stattdessen einen Stern (*). Das ist üblich für root auf Alpine, für Dienst- und Deploy-Konten, die nur mit SSH-Schlüsseln arbeiten, und für Benutzer, die über LDAP verwaltet werden.

Beim Anmelden berechnet der SSH-Server aus dem eingegebenen Passwort einen Hash und vergleicht ihn mit dem gespeicherten Wert. Laut The Hacker News schlägt diese Berechnung unter musl bei Passwörtern zwischen 257 und 1.024 Zeichen fehl und liefert dann ebenfalls einen Stern zurück. Der Vergleich mit dem gespeicherten Stern geht auf, und der SSH-Server lässt den Angreifer herein. Der Fehler stammt aus einem Patch von 2016, der damals eine andere Lücke zur Ermittlung von Benutzernamen schließen sollte.

Welche Systeme von SSHole betroffen sind

Für einen erfolgreichen Angriff müssen laut der Projektseite sshhole.com mehrere Bedingungen zusammenkommen:

Der SSH-Server läuft auf musl libc, etwa unter Alpine Linux, OpenWrt, Buildroot oder Yocto.
Er prüft Passwörter ohne PAM. Das ist beim OpenSSH-Paket von Alpine die Standardeinstellung.
Die Anmeldung per Passwort ist aktiv, wie es ab Werk der Fall ist.
Es gibt ein Konto mit Stern im Passwortfeld und zusätzlich mindestens ein Konto mit echtem Passwort.

Besonders heikel sind laut sshhole.com die offiziellen Alpine-Images für AWS und Azure. Dort ist der Standardbenutzer alpine betroffen, und er darf per doas ohne Passwort Befehle als root ausführen. Ein Angreifer hat damit sofort volle Kontrolle über die Maschine. Laut borncity sind zudem viele Docker-Images betroffen, weil sie auf Alpine aufbauen.

Weniger sichtbar, aber praktisch relevant sind Geräte mit eingebettetem Linux. Router, Access Points, NAS, Kameras und Steuerungen in der Haustechnik basieren häufig auf OpenWrt, Buildroot oder Yocto. Ob ein bestimmtes Gerät betroffen ist, hängt davon ab, welche SSH-Software der Hersteller einsetzt und wie er sie konfiguriert hat. Diese Information liefert nur der Hersteller.

Debian, Ubuntu und Red Hat sind nicht betroffen

Nicht betroffen sind Debian, Ubuntu, Red Hat, SUSE und andere Distributionen mit glibc, alle Systeme mit PAM, der alternative SSH-Server Dropbear sowie Systeme außerhalb von Linux. Typische Server-Installationen im Mittelstand fallen damit heraus. Für diese Server bleibt aber die Linux-Kernel-Lücke aus der Vorwoche wichtig; mehr dazu in unserem Beitrag Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack.

Zahlen, Daten, Fakten zu SSHole

Kennzahlen zur OpenSSH Sicherheitslücke SSHole
Kennzahl	Wert
Einstufung von CVE-2026-123158	CVSS 8.1 (hoch)
Länge des beliebigen Passworts	257 bis 1.024 Zeichen
Zeit bis zum ersten beobachteten Angriff	unter 9 Stunden
Angriffsversuche bis 8. November 2026	20 von 13 IP-Adressen aus neun Ländern
Fehler im Code seit	2016

Previdian bestätigt laut The Hacker News einen erfolgreichen root-Zugriff auf einem Honeypot mit Alpine Linux. Die Angreifer führten danach erste Erkundungsbefehle wie id, uname und hostname aus. Das Muster ist typisch für automatisierte Scans, die erreichbare Systeme zunächst nur katalogisieren.

Empfehlungen für IT-Admins

Betroffene Systeme finden

Erfassen Sie Server, VMs und Container auf Basis von Alpine, die einen SSH-Dienst anbieten. Prüfen Sie auch Cloud-Instanzen aus den offiziellen Alpine-Images.

OpenSSH aktualisieren

Spielen Sie OpenSSH 10.6p2 oder das korrigierte Paket der Distribution ein und starten Sie sshd neu. Unter Alpine genügt apk upgrade openssh.

Passwort-Anmeldung abschalten

Wo das Update nicht sofort möglich ist, setzen Sie PasswordAuthentication no und starten sshd neu. SSH sollte ohnehin nur mit Schlüsseln arbeiten und nicht direkt aus dem Internet erreichbar sein.

Konfiguration prüfen

Der Befehl sshd -T zeigt die wirksamen Einstellungen. Ist dort usepam no und passwordauthentication yes gesetzt, ist das System bei veraltetem OpenSSH angreifbar.

Spuren suchen

Laut Alpine sollten Sie in /var/log/messages nach Zeilen „Accepted password for“ suchen, die Konten ohne Passwort betreffen, etwa alpine, root oder reine Schlüssel-Konten. Prüfen Sie zusätzlich die doas-Nutzung, neu angelegte Benutzer und Dateien sowie hinterlegte SSH-Schlüssel.

Geräte mit eingebettetem Linux einbeziehen

Klären Sie bei Routern, Access Points, NAS und anderen Appliances mit SSH-Zugang, ob der Hersteller einen Hinweis zu CVE-2026-123158 veröffentlicht hat. Schalten Sie SSH dort ab, wo es nicht gebraucht wird, und beschränken Sie den Zugriff auf das Verwaltungsnetz.

Wichtig für IT-Admins

Lässt sich eine unbefugte Anmeldung nicht sicher ausschließen, empfiehlt Alpine, die Maschine als übernommen zu behandeln. In der Praxis heißt das: System neu aufsetzen, Zugangsdaten und Schlüssel tauschen, die auf der Maschine lagen, und angebundene Systeme prüfen. Ein bloßes Update schließt die Tür, entfernt aber keinen Angreifer, der schon drin ist.

Bedeutung für Geschäftsführung und Entscheider

SSHole trifft vor allem Systeme, die selten jemand im Blick hat. Klassische Windows- und Linux-Server im Unternehmen sind in aller Regel nicht betroffen. Gefährdet sind Container, Cloud-Instanzen aus Standard-Images und Geräte mit eingebettetem Linux, die einmal eingerichtet und danach kaum noch angefasst werden.

Das Risiko ist konkret, weil Angreifer die Lücke bereits automatisiert ausnutzen. Ein übernommenes System dient als Sprungbrett ins Netz: Laut Safe Security können Angreifer an Zugangsdaten für Deployments, Anwendungsgeheimnisse und angebundene Infrastruktur gelangen.

Der Aufwand für die Abwehr ist überschaubar. Das Update und das Abschalten der Passwort-Anmeldung sind Arbeiten von Minuten je System. Aufwendiger ist die Frage, welche Systeme überhaupt betroffen sind. Eine aktuelle Inventarisierung aller Server, Container und Netzwerkgeräte mit SSH-Zugang zahlt sich hier unmittelbar aus.

FAQ zu SSHole

Ist mein Debian- oder Ubuntu-Server von SSHole betroffen?

Nein. Debian, Ubuntu, Red Hat und andere Distributionen mit glibc sind laut sshhole.com und The Hacker News nicht betroffen. Gleiches gilt für alle Systeme, die Passwörter über PAM prüfen.

Was ist musl libc?

musl ist eine schlanke C-Standardbibliothek für Linux. Sie steckt vor allem in Alpine Linux, in vielen Docker-Images und in Firmware für Router und andere Geräte mit eingebettetem Linux.

Wird SSHole bereits ausgenutzt?

Ja. Previdian beobachtete den ersten Angriff weniger als neun Stunden nach Veröffentlichung der CVE und bis zum 8. November 2026 insgesamt 20 Versuche von 13 IP-Adressen. Auf einem Honeypot mit Alpine erlangten die Angreifer root-Rechte.

Reicht es, die Passwort-Anmeldung abzuschalten?

Als Sofortmaßnahme ja. Mit PasswordAuthentication no greift SSHole nicht mehr. Das Update auf OpenSSH 10.6p2 sollte trotzdem folgen, damit die Einstellung nicht später versehentlich zurückgesetzt wird.

Wie erkenne ich einen erfolgreichen Angriff?

Suchen Sie in /var/log/messages nach "Accepted password for" bei Konten, die kein Passwort haben. Ergänzend prüfen Sie doas-Aufrufe, neue Benutzer und hinterlegte SSH-Schlüssel.

Fazit

Die OpenSSH Sicherheitslücke SSHole betrifft eine überschaubare Gruppe von Systemen: Alpine-Server, Container und Geräte mit eingebettetem Linux. Wo diese Bedingungen zutreffen, öffnet ein langes Passwort die Tür zu Konten, die nie ein Passwort hatten, im ungünstigsten Fall direkt mit root-Rechten. Da Angreifer die Lücke bereits ausnutzen, gehört das Update auf OpenSSH 10.6p2 in diese Woche. Wer zusätzlich die Passwort-Anmeldung per SSH grundsätzlich abschaltet, ist auch gegen die nächste Lücke dieser Art besser aufgestellt.

Weitere interessante Beiträge

mars-News

Cyber Security Workshop für Schulen und Bildungseinrichtungen

20. August 2026

Zum Blogbeitrag

IT-News

Kritische Sophos UTM Sicherheitslücke: Firewall ohne Anmeldung angreifbar

3. November 2026

Zum Blogbeitrag

IT-News

Phishing-Mails erkennen: So entlarven Sie gefälschte Absender

29. Oktober 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag OpenSSH Sicherheitslücke – SSHole (CVE-2026-123158) erschien zuerst auf mars solutions GmbH.

Kritische Sophos UTM Sicherheitslücke: Firewall ohne Anmeldung angreifbar

Technischer Support — Tue, 03 Nov 2026 12:48:54 +0000

Kritische Sophos UTM Sicherheitslücke: Firewall ohne Anmeldung angreifbar

Technischer Support
November 3, 2026
13:48

Eine Sicherheitslücke in Sophos UTM erlaubt es Angreifern, ohne Anmeldung aus dem Internet beliebige Befehle mit root-Rechten auf der Firewall auszuführen. Sophos hat die Lücke CVE-2026-118633 am 28. Oktober 2026 veröffentlicht und mit 9.2 von 10 Punkten als kritisch bewertet. Betroffen sind alle Versionen von Sophos UTM, auf denen der E-Mail-Proxy mit aktivierter Prüfung läuft. Den Patch müssen Administratoren von Hand einspielen.

Gleichzeitig hat Sophos UTM 9 sein Supportende bereits erreicht. Für Unternehmen, die noch eine UTM betreiben, ist die Lücke damit doppelter Anlass zum Handeln: kurzfristig patchen und die Ablösung verbindlich planen.

Das Wichtigste in Kürze

Die Sicherheitslücke CVE-2026-118633 betrifft laut Sophos alle Versionen von Sophos UTM bis einschließlich 9.724.
Angreifer können ohne Anmeldung aus der Ferne Befehle mit root-Rechten ausführen und damit die Firewall vollständig übernehmen.
Angreifbar sind Geräte, deren E-Mail-Proxy mit aktivierter Prüfung E-Mails aus dem Internet annimmt.
Der Patch wird nicht automatisch verteilt. Nach dem Update auf Version 9.724 wird ein Korrekturpaket manuell installiert.
Sophos UTM 9 hat das Supportende am 30. Juni 2026 erreicht, Kunden mit gültiger Lizenz werden längstens bis 31. Dezember 2026 unterstützt.

So funktioniert die Sophos-UTM-Lücke

Sophos beschreibt die Schwachstelle in seinem Sicherheitshinweis als Path-Traversal-Lücke. Dabei verarbeitet ein Dienst manipulierte Pfadangaben, ohne sie ausreichend zu prüfen, und gibt so Zugriff auf Bereiche frei, die eigentlich gesperrt sind. Laut dem CVE-Eintrag in der US-Schwachstellendatenbank NVD führt das bei Sophos UTM bis zur Ausführung beliebigen Codes mit root-Rechten, dem höchsten Berechtigungsniveau auf dem Gerät.

Ein gewisser Aufwand bleibt für den Angreifer. Er muss eine sogenannte Wettlaufsituation (Race Condition) gewinnen und seine Angriffe dafür einige Minuten lang wiederholen. Solche Wiederholungen lassen sich allerdings leicht automatisieren. Eine Anmeldung, gestohlene Zugangsdaten oder ein Zugang zum Firmennetz sind nicht nötig.

Zahlen, Daten, Fakten

Kennzahlen zur Sophos-UTM-Sicherheitslücke
Kennzahl	Wert
CVSS-4.0-Bewertung durch Sophos	9.2 (kritisch)
Letzte UTM-Version, Voraussetzung für den Patch	9.724
Supportende von Sophos UTM 9	30.06.2026
Spätester Stichtag für Support mit gültiger Lizenz	31.12.2026

Die Bewertung stammt von Sophos selbst. Eine eigene Einstufung der US-Schwachstellendatenbank NVD steht noch aus.

Welche Sophos-UTM-Installationen betroffen sind

Betroffen sind laut Sophos alle Versionen von Sophos UTM. Der Knowledge-Base-Artikel zum Patch grenzt die gefährdete Umgebung genauer ein: UTMs, die als SMTP-Gateway eingesetzt werden, also E-Mails aus dem Internet annehmen, prüfen und an den Mailserver weiterreichen. Angreifen kann jeder, der das Gerät erreicht, um dort E-Mails einzuliefern.

Im Mittelstand ist diese Konstellation verbreitet. Die UTM wurde oft vor Jahren als zentrale Sicherheitslösung angeschafft und übernimmt neben Firewall und VPN auch den E-Mail-Schutz. Sie läuft zuverlässig und fällt deshalb im Alltag kaum auf.

Sophos Firewall wird nicht genannt

Der CVE-Eintrag nennt als betroffenes Produkt ausschließlich SG UTM, nicht die Nachfolgelinie Sophos Firewall.

So patchen Sie Sophos UTM

Bestand erfassen

Klären Sie, wo im Unternehmen noch eine Sophos UTM läuft, auch als Zweitgerät oder an einem Außenstandort.

Mail-Proxy prüfen

Stellen Sie fest, ob die UTM als SMTP-Gateway arbeitet und der E-Mail-Proxy mit Prüfung aktiv ist. Wird der E-Mail-Schutz nicht mehr gebraucht, schalten Sie ihn ab.

Konfiguration sichern

Legen Sie vor dem Eingriff ein aktuelles Backup der UTM-Konfiguration an und speichern Sie es getrennt vom Gerät.

Auf Version 9.724 aktualisieren

Der Patch setzt den aktuellen Versionsstand voraus. Ältere Geräte müssen zuerst auf 9.724 gebracht werden.

Korrekturpaket einspielen

Laut dem Sophos-Artikel KBA-000049692 wird ein RPM-Paket über die Kommandozeile der UTM installiert, seine Prüfsumme kontrolliert und der betroffene Mail-Dienst neu gestartet. Planen Sie dafür ein kurzes Wartungsfenster ein und kontrollieren Sie danach gezielt, ob die Mailzustellung wieder normal läuft.

Supportende von Sophos UTM

Dass der Patch nicht automatisch kommt, hat mit dem Lebenszyklus des Produkts zu tun. Laut dem Lebenszyklus-Kalender von Sophos (KBA-000003353) hat Sophos UTM 9 das Supportende am 30. Juni 2026 erreicht. Kunden mit gültiger Lizenz werden noch bis zum Ablauf ihrer Lizenz unterstützt, längstens bis zum 31. Dezember 2026.

Ab 2027 gibt es keinen Support mehr

Blind verlassen sollte man sich auf weitere Korrekturen nicht. Spätestens ab dem 1. Januar 2027 ist für Sophos UTM keinerlei Support mehr vorgesehen. Als Nachfolger empfiehlt Sophos die Sophos Firewall.

Wann sich eine neue Firewall lohnt

Die UTM-Lücke wirft eine grundsätzliche Frage auf: Ab wann ist für eine Firewall ein Nachfolger sinnvoller als das nächste Update? Ein starres Alter gibt es dafür nicht, wohl aber klare Anzeichen.

Der Hersteller hat das Produkt abgekündigt: Mit dem Supportende kommen Sicherheitskorrekturen nur noch ausnahmsweise oder gar nicht mehr. Für ein Gerät am Internetrand ist das das stärkste Argument für einen Austausch.
Updates erfordern Handarbeit: Müssen Korrekturen einzeln gesucht und eingespielt werden, steigt das Risiko, dass eine Lücke offen bleibt.
Die Leistung reicht nicht mehr: Moderne Prüfungen, etwa von verschlüsselten Verbindungen, kosten Rechenleistung. Ältere Hardware bremst dann die Verbindung, oder Schutzfunktionen werden abgeschaltet.
Die Anforderungen haben sich verändert: Mehr Standorte, mobiles Arbeiten und Cloud-Dienste lassen sich mit einer vor Jahren dimensionierten Firewall oft nur über Umwege abbilden.
Die Lizenzverlängerung steht an: Das ist der richtige Zeitpunkt, die Kosten des Weiterbetriebs mit denen eines Nachfolgers zu vergleichen.

Eine Firewall, die vom Hersteller unterstützt wird, regelmäßig Updates erhält und für die heutige Last ausreicht, muss dagegen nicht ersetzt werden, nur weil sie einige Jahre alt ist. Ein Wechsel ist ein Projekt mit Vorlauf: Regeln, VPN-Verbindungen und Ausnahmen müssen übernommen und getestet werden. Wer erst handelt, wenn die nächste kritische Lücke ohne Patch bleibt, plant unter Zeitdruck.

Empfehlungen für IT-Admins

Erreichbarkeit einschränken: Prüfen, welche Dienste der UTM aus dem Internet erreichbar sind, und alles schließen, was nicht zwingend nötig ist
Protokolle sichten: Die Logs des E-Mail-Proxys auf gehäufte, ungewöhnliche Anfragen über mehrere Minuten prüfen, denn genau solche Wiederholungen braucht der Angriff
Lizenzlaufzeit prüfen: Für jede UTM festhalten, wann die Lizenz und damit der Support endet
Migration terminieren: Den Wechsel auf ein unterstütztes System mit Datum und Verantwortlichem einplanen, spätestens vor dem 31. Dezember 2026

Bedeutung für Geschäftsführung und Entscheider

Die Firewall steht zwischen Firmennetz und Internet. Übernimmt ein Angreifer sie, kann er im ungünstigsten Fall den gesamten Datenverkehr mitlesen, Regeln verändern und sich von dort aus im Netz weiterbewegen. Eine Lücke ohne Anmeldung an genau dieser Stelle ist deshalb ein Geschäftsrisiko, das weit über die IT hinausreicht.

Für die Planung zählen zwei Termine. Der Patch gehört jetzt eingespielt, der Aufwand dafür liegt bei einem kurzen Wartungsfenster je Gerät. Die Ablösung der UTM muss bis spätestens Ende 2026 erledigt sein und braucht Vorlauf für Auswahl, Beschaffung und Umstellung. Wer dafür heute noch keinen Termin hat, sollte ihn jetzt festlegen.

Laufender IT-Betrieb mit Full Managed-IT

Ob eine Meldung wie diese rechtzeitig ankommt, hängt weniger von der Technik ab als davon, ob jemand fest dafür zuständig ist. Bei Full Managed-IT übernimmt mars solutions den laufenden Betrieb der IT eines Unternehmens. Einige Bausteine greifen bei einem Fall wie der UTM-Lücke direkt:

Server- und Netzwerkmonitoring (ab Stufe Bronze) zeigt, welche Geräte im Netz laufen und in welchem Zustand sie sind.
Antispam und DMARC-Management (ab Stufe Bronze) prüft eingehende E-Mails vor der Zustellung. Übernimmt dieser Dienst den E-Mail-Schutz, lässt sich die entsprechende Funktion auf einer alten Firewall abschalten.
Schwachstellenanalyse intern und extern (ab Stufe Silber) scannt die Systeme in festem Rhythmus. Veraltete oder abgekündigte Geräte am Internetrand fallen so auf, bevor sie zum Problem werden.

Der Austausch einer Firewall bleibt ein eigenes Projekt. Eine laufende Betreuung sorgt dafür, dass er rechtzeitig geplant wird.

FAQ zur Sophos-UTM-Sicherheitslücke

Ist meine Sophos UTM betroffen?

Betroffen sind laut Sophos alle Versionen bis einschließlich 9.724. Angreifbar ist ein Gerät, wenn es als SMTP-Gateway arbeitet und der E-Mail-Proxy mit Prüfung aktiv ist.

Wird die Lücke bereits ausgenutzt?

Dazu gibt es bislang keine Angaben. Weder der Sicherheitshinweis von Sophos noch der CVE-Eintrag nennen laufende Angriffe. Weil der Angriff ohne Anmeldung funktioniert, sollte der Patch trotzdem zeitnah eingespielt werden.

Gibt es eine Übergangslösung?

Sophos nennt keine. Wer den E-Mail-Schutz der UTM nicht mehr benötigt, kann die Funktion abschalten. Ohne aktiven E-Mail-Proxy mit Prüfung fehlt nach Angaben von Sophos die Voraussetzung für den Angriff.

Reicht der Patch, oder muss die UTM ersetzt werden?

Der Patch schließt diese eine Lücke. Weil der Support für Sophos UTM spätestens am 31. Dezember 2026 endet, muss die Ablösung trotzdem verbindlich geplant werden.

Fazit

Die Sicherheitslücke in Sophos UTM ist ernst: Ein Angreifer braucht keine Anmeldung und erhält im Erfolgsfall die volle Kontrolle über die Firewall. Wer eine UTM als SMTP-Gateway betreibt, sollte sie jetzt auf Version 9.724 bringen und den Patch nach KBA-000049692 einspielen oder den E-Mail-Schutz abschalten, wenn er nicht mehr gebraucht wird. Ebenso wichtig ist der zweite Schritt. Der Support für Sophos UTM endet spätestens am 31. Dezember 2026, und für jedes dieser Geräte sollte jetzt ein fester Termin für den Wechsel auf ein unterstütztes System stehen.

Weitere interessante Beiträge

IT-News

Microsoft Defender Treiber BTR.sys: Wenn der Schutz zum Werkzeug wird

25. August 2026

Zum Blogbeitrag

IT-News

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

17. September 2026

Zum Blogbeitrag

IT-News

Exchange-Ausfälle nach dem Oktober-Patchday

19. Oktober 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Kritische Sophos UTM Sicherheitslücke: Firewall ohne Anmeldung angreifbar erschien zuerst auf mars solutions GmbH.

Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack

Technischer Support — Mon, 02 Nov 2026 15:49:39 +0000

Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack

Technischer Support
November 2, 2026
16:49

Aktualisiert am 10. November 2026: Hotfix und Kernel-Updates Sophos Firewall und Veeam-Appliances

Eine kritische Linux-Kernel-Lücke im TCP/IP-Stack betrifft nahezu alle Linux-Distributionen, darunter Debian, Red Hat, Suse und Ubuntu. Die Schwachstelle CVE-2026-98432 ist mit CVSS 9,8 bewertet und erlaubt Angreifern über das Netzwerk, ohne Anmeldung Speicher im Kernel zu beschädigen und im schlimmsten Fall eigenen Code auszuführen.

Der Fehler steckt seit Kernel-Version 4.4 aus dem Jahr 2015 im Code und blieb elf Jahre unentdeckt. Gefunden hat ihn Anthropic bei systematischen Tests mit dem KI-Modell Claude. Die Kernel-Entwickler haben die Lücke am 15. Oktober 2026 behoben, die Distributionen liefern die Updates gerade nach und nach aus.

Das Wichtigste in Kürze

CVE-2026-98432 ist ein Use-after-free-Fehler im IPv4-TCP-Code des Linux-Kernels, ausnutzbar über das Netzwerk ohne Anmeldung.
Betroffen sind alle Kernel ab Version 4.4 bis zu den korrigierten Fassungen, also fast jeder Linux-Server und jede Linux-Appliance.
IPv6-Verbindungen sind vom Hauptfehler nicht betroffen.
Ein funktionierender Exploit existiert, ist aber nicht öffentlich. Angriffe sind bislang nicht bekannt.
Abhilfe schafft nur ein korrigierter Kernel mit anschließendem Neustart.
Für Ubuntu gibt es noch keine Patches, Sophos arbeitet ebenfalls noch an Updates.

UPDATE: Linux-Kernel-Lücke: Hotfix für Sophos Firewall

Aktualisierung vom 9. November 2026: Die Linux-Kernel-Lücke CVE-2026-98432 betrifft auch die Sophos Firewall. Sophos hat am 6. November 2026 einen kritischen Hotfix veröffentlicht (KBA-000049730). Er gilt für SFOS 23.0 GA, 23.0 EAP1 und 22.0 MR3. Firewalls mit diesen Versionen laden den Hotfix automatisch herunter. Laut Sophos erscheint danach im Control Center der Weboberfläche ein Hinweis, dass für die Installation ein Neustart nötig ist.

So spielen Sie den Hotfix ein:

Version prüfen: Läuft eine ältere Version, aktualisieren Sie die Firewall zuerst auf eine der genannten Versionen. Erst danach wird der Hotfix angeboten.
Automatische Installation einschalten: Ist die automatische Hotfix-Installation abgeschaltet, schalten Sie sie in der CLI mit system hotfix enable ein.
Neustart im Wartungsfenster: Erst der Neustart installiert den Hotfix. Er unterbricht den Datenverkehr, planen Sie ihn deshalb in einem Wartungsfenster ein. Bei HA-Paaren starten Sie zuerst das Auxiliary-Gerät neu und erst danach das Primary, sobald das Auxiliary wieder verfügbar ist.
Stand kontrollieren: In der CLI (Device Console, Menüpunkt 4) zeigt system hotfix list, ob der Eintrag HF110626.1 mit dem Status Installed vorhanden ist. In SFOS 23.0 zeigt die Weboberfläche den Hotfix-Status noch nicht an.
Firmware für SD-RED aktualisieren: Für SD-RED 20 und SD-RED 60 hat Sophos am 5. November 2026 die Firmware 3.0.012 als Pattern-Update veröffentlicht. Sie kommt nicht mit dem Hotfix, sondern muss manuell eingespielt werden: in der Weboberfläche unter Backup & Firmware > Pattern Updates auf Update Pattern Now und danach auf Install klicken. Die Firewall muss dafür nicht neu starten, die SD-RED-Geräte starten bei der Installation aber neu. Die Verbindung zu den Außenstellen bricht dabei kurz ab. Ältere RED-Modelle, deren Lebenszyklus beendet ist, erhalten kein Update.

Per E-Mail oder in Sophos Central/Fusion kam in der Sophos Community meist keine Meldung. Prüfen Sie deshalb jede Firewall gezielt, statt auf eine Benachrichtigung zu warten.

Ohne Neustart bleibt die Firewall angreifbar

Installiert wird der Hotfix erst mit einem Neustart der Firewall. Wer vorher von einer älteren Version aktualisiert, braucht danach einen weiteren Neustart. Bis dahin läuft weiter der verwundbare Kernel.

UPDATE: Kernel-Update für Veeam-Appliances

Aktualisierung vom 10. November 2026: Laut Veeam (KB4966 vom 6. November 2026) betrifft die Linux-Kernel-Lücke CVE-2026-98432 alle Veeam-Komponenten, die einen eigenen Linux-Kernel mitbringen. Dazu gehören:

Veeam Software Appliance 13.1 und Veeam Infrastructure Appliance 13.1, auch in den Rollen als Proxy, Repository, Hardened Repository, Gateway, Mount-Server oder WAN-Beschleuniger
die Linux-basierten Hilfs-Appliances von Veeam Backup & Replication 13.1 und 12.3 unter Windows
die Worker der Veeam-Plug-ins für Hypervisoren sowie die Appliances der Plug-ins für AWS, Microsoft Azure und Google Cloud
Recovery Media für Veeam Agent for Linux, die vor dem Update erstellt wurden

Für die Appliances in Version 13.1 liegt der korrigierte Kernel 5.14.0-570.60.1+27.2.el9_6_ciq seit 2. November 2026 im Veeam-Repository.

So spielen Sie das Update ein:

Appliances aktualisieren: In der Standardeinstellung installiert der Veeam Updater Pflicht-Updates automatisch am nächsten Sonntag um 14 Uhr. Schneller geht es in der Veeam Host Management Console über Updates, Check for updates und Install Updates Now. Laut Veeam kann danach ein Neustart der Appliance nötig sein.
Einzeln konfigurierte Komponenten prüfen: Komponenten mit eigener Update-Konfiguration aktualisieren Sie in ihrer eigenen Host Management Console. Appliances mit lokalem Spiegel des Veeam-Repositorys erhalten das Update erst, wenn der Spiegel synchronisiert ist.
Private Fix für Windows-Server: Für Veeam Backup & Replication 13.1 unter Windows gibt es einen Private Fix, der Version 13.1.2.57 voraussetzt. Das neu gepackte Installations-ISO 13.1.2 enthält ihn bereits. Für Version 12.3 ist der Private Fix laut Veeam noch nicht verfügbar.
Hilfs-Appliances und Recovery Media erneuern: Virtuelle Labore und Hilfs-Appliances in Azure werden nicht automatisch aktualisiert, sondern müssen neu bereitgestellt werden. Recovery Media, die vor dem Update entstanden sind, ersetzen Sie durch neu erstellte.

Selbst verwaltete Linux-Server separat patchen

Nicht betroffen ist laut Veeam Kasten for Kubernetes, weil die Container-Images keinen eigenen Kernel enthalten. Linux-Server, die Sie selbst installiert haben und verwalten, zählt Veeam nicht zu seinen Komponenten. Für sie gelten die Kernel-Updates der jeweiligen Distribution.

So funktioniert die Linux-Kernel-Lücke

Die Schwachstelle liegt im Verbindungsaufbau von TCP über IPv4. Schickt ein Client beim Verbindungsaufbau IP-Optionen mit, speichert der Kernel diese in einem vorläufigen Verbindungsobjekt. Sobald die Verbindung steht, übernimmt die eigentliche Verbindung diese Optionen, ohne sie zu kopieren. Beide Objekte zeigen danach auf denselben Speicher.

Verarbeitet ein zweiter Prozessorkern gleichzeitig eine wiederholte Verbindungsanfrage, liest er diese Optionen noch, während der erste Kern die Verbindung bereits abbaut und den Speicher freigibt. Laut der Beschreibung der Kernel-Entwickler entsteht so ein Use-after-free: Der Kernel arbeitet mit Speicher, der schon wieder anderweitig vergeben sein kann. Je nach Ablauf führt das zum Absturz des Systems, zum Abfluss von Kernel-Speicher an den Angreifer oder zu Schreibzugriffen außerhalb des vorgesehenen Bereichs.

Laut der Begründung zur CVSS-Bewertung kann ein Angreifer die nötigen Verbindungsanfragen beliebig oft wiederholen, bis das knappe Zeitfenster getroffen ist. Da der Fehler beim Verbindungsaufbau auftritt, greift er, bevor ein Dienst überhaupt nach Zugangsdaten fragt.

Die Korrektur selbst ist klein. Zwei Stellen im Kernel geben den Speicher jetzt erst frei, wenn kein anderer Kern mehr darauf zugreift.

IPv6 ist nicht betroffen

Bei IPv6 kopiert der Kernel die Optionen beim Verbindungsaufbau. Der beschriebene Hauptfehler tritt dort deshalb nicht auf. Ein Schutz für IPv4-Dienste ist das allerdings nicht.

Welche Linux-Kernel-Versionen betroffen sind

Behobene Linux-Kernel-Versionen
Kernel-Zweig	Behoben ab
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	7.3-rc7

Betroffen sind alle Kernel ab Version 4.4. Die Tabelle nennt die Versionen, in denen der Fehler laut Greg Kroah-Hartman, dem Betreuer der stabilen Kernel-Zweige, behoben ist.

Der Stand bei den Distributionen ist unterschiedlich. Debian hat korrigierte Kernel für Bookworm (6.1.190) und Trixie (6.12.113) veröffentlicht. Für Ubuntu gibt es noch keine Patches: Laut Canonical sind die Kernel-Updates für alle unterstützten Versionen, auch 24.04 LTS und 26.04 LTS, am 2. November 2026 noch in Arbeit. Red Hat stuft die Lücke als kritisch ein und hat ein eigenes Security Bulletin herausgegeben.

Warum MPTCP-Dienste besonders gefährdet sind

Der bislang einzige bekannte Exploit stammt von Anthropic und zielt auf Server, die Multipath TCP (MPTCP) anbieten. MPTCP verteilt eine Verbindung auf mehrere Netzwerkwege und muss von einem Dienst ausdrücklich angefordert werden. Laut Anthropic gelang damit eine vollständige Übernahme des Servers mit Root-Rechten, ohne Zugangsdaten und ohne Zutun eines Benutzers.

Offen ist, ob ein Angriff zwingend einen MPTCP-Dienst voraussetzt. Der Fehler selbst sitzt im allgemeinen TCP-Code.

Go-Anwendungen nutzen MPTCP standardmäßig

Programme, die mit Go ab Version 1.24 gebaut sind, nehmen Verbindungen per Default über MPTCP an. Damit erfüllen viele moderne Server-Dienste die Voraussetzung des bekannten Angriffs. Bis der korrigierte Kernel läuft, lässt sich MPTCP abschalten, etwa systemweit per sysctl oder für Go-Programme über die Umgebungsvariable GODEBUG=multipathtcp=0. Den Fehler selbst beseitigt das nicht.

Kernel-Version und MPTCP-Dienste prüfen

Mit diesen Befehlen prüfen Sie die laufende Kernel-Version und offene MPTCP-Dienste:

# Laufende Kernel-Version anzeigen
uname -r

# Dienste mit MPTCP-Sockets anzeigen
ss -M -l

# MPTCP vorübergehend systemweit abschalten
sysctl -w net.mptcp.enabled=0

CVSS-Wert (kritisch)

0 ,8

Jahre unentdeckt im Kernel

korrigierte Kernel-Zweige

bekannte Angriffe

Hinweise zum Vorgehen für IT-Admins

Bestand erfassen

Alle Linux-Systeme auflisten, auch Appliances, Firewalls, NAS-Systeme und Virtualisierungshosts auf Linux-Basis.

Updates einspielen

Den korrigierten Kernel der jeweiligen Distribution installieren, sobald er bereitsteht. Bei Appliances die Hinweise des Herstellers abwarten.

Neustart einplanen

Ein neuer Kernel greift erst nach dem Neustart. Danach mit uname -r prüfen, welche Version tatsächlich läuft.

Übergang absichern

Bis zum Update MPTCP abschalten, wo es nicht gebraucht wird, und aus dem Internet erreichbare Dienste zuerst patchen.

Bedeutung für Geschäftsführung und Entscheider

Die Lücke betrifft die Grundlage vieler Server, Cloud-Dienste und Netzwerkgeräte im Unternehmen. Ein Angreifer braucht weder Zugangsdaten noch die Mithilfe eines Mitarbeiters. Ein erreichbarer Dienst genügt.

Das Risiko ist derzeit beherrschbar, weil der Exploit nicht öffentlich ist und Updates verfügbar sind oder kurz bevorstehen. Der Aufwand liegt vor allem in der Planung der Neustarts. Entscheidend ist, dass alle Linux-Systeme erfasst sind, auch die, die nicht als Server wahrgenommen werden.

Der Fall zeigt zudem eine Entwicklung, die für die IT-Sicherheit insgesamt gilt: KI-Werkzeuge finden alte Fehler in bewährter Software deutlich schneller als bisher. Mit mehr kritischen Updates in kürzeren Abständen ist zu rechnen.

FAQ zu CVE-2026-98432

Bin ich betroffen, wenn ich nur IPv6 nutze?

Vom Hauptfehler nicht, denn der IPv6-Code kopiert die Optionen beim Verbindungsaufbau. In der Praxis sind aber fast alle Systeme auch über IPv4 erreichbar und damit betroffen.

Reicht es, MPTCP abzuschalten?

Nein, das senkt nur das Risiko des bekannten Angriffswegs. Der Fehler sitzt im allgemeinen TCP-Code, sicher ist erst der korrigierte Kernel.

Wird die Lücke bereits ausgenutzt?

Bislang sind keine Angriffe bekannt. Der einzige Exploit stammt von Anthropic und ist nicht öffentlich verfügbar.

Muss das System nach dem Update neu starten?

Ja, ein neuer Kernel wird erst nach dem Neustart aktiv. Ohne Neustart läuft weiter der verwundbare Kernel.

Fazit

Die Linux-Kernel-Lücke CVE-2026-98432 ist mit CVSS 9,8 als kritisch eingestuft, weil sie fast jedes Linux-System betrifft und ohne Anmeldung über das Netz erreichbar ist.

Noch fehlen öffentliche Exploits und bekannte Angriffe, dieser Vorsprung ist aber begrenzt. Wer jetzt alle Linux-Systeme erfasst, die korrigierten Kernel einspielt und die Neustarts einplant, schließt die Lücke, bevor sie breit ausgenutzt werden kann.

Weitere interessante Beiträge

IT-News

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

7. September 2026

Zum Blogbeitrag

IT-News

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

1. September 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 Linux-Kernel-Lücke CVE-2026-98432 im TCP-Stack erschien zuerst auf mars solutions GmbH.

Phishing-Mails erkennen: So entlarven Sie gefälschte Absender

Technischer Support — Thu, 29 Oct 2026 11:30:00 +0000

Phishing-Mails erkennen: So entlarven Sie gefälschte Absender

Technischer Support
Oktober 29, 2026
12:30

Phishing-Mails tarnen sich als Nachrichten bekannter Absender: Banken, Paketdienste, Software-Hersteller oder der eigene IT-Dienstleister. Die Angreifer wollen Zugangsdaten abgreifen, Schadsoftware verteilen oder Zahlungen umleiten. Wer Phishing-Mails erkennen will, prüft vor allem die Absenderadresse. Wie das geht, zeigen wir am Beispiel unserer eigenen Adressen.

Das Wichtigste in Kürze

Phishing-Mails nutzen bekannte Namen, damit Empfänger weniger genau hinsehen. Das kann jeden Absender treffen, auch mars solutions.
Der angezeigte Name einer Mail ist frei wählbar und beweist nichts. Aussagekräftig ist nur die Absenderadresse.
Betrüger nutzen Domains, die der echten zum Verwechseln ähnlich sehen, etwa mit einem fehlenden Buchstaben oder einem großen i statt eines kleinen L.
Seriöse Absender fordern Sie nie per Mail auf, ein Kennwort einzugeben oder eine Rechnung an eine neue Bankverbindung zu zahlen.
Im Zweifel fragen Sie beim Absender über einen bekannten Weg nach, etwa über die Telefonnummer, die Sie schon kennen.

So tarnen sich Phishing-Mails

Phishing-Mails wirken echt, weil sie Namen, Logos und Tonfall bekannter Absender übernehmen. Der Empfänger erwartet vielleicht ohnehin eine Rechnung, eine Paketnachricht oder eine Rückfrage zu einem Ticket und prüft entsprechend weniger genau. Darauf setzen die Angreifer.

Den Namen, der im Postfach als Absender erscheint, kann jeder frei eintragen. Dazu kommen Domains, die der echten zum Verwechseln ähnlich sehen, und Texte, die Zeitdruck erzeugen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) nennt die genaue Prüfung des Absenders deshalb als ersten Schritt, um Phishing zu erkennen.

Gut zu wissen

Angreifer können auch den Namen mars solutions für gefälschte Mails verwenden. Eine Mail mit unserem Namen im Absender stammt deshalb nicht automatisch von uns. Wie Sie das prüfen, zeigen die folgenden Abschnitte am Beispiel unserer eigenen Adressen.

Echte Absender am Beispiel mars solutions

Jedes Unternehmen versendet seine Mails von festen Domains. Bei mars solutions sind das ausschließlich diese beiden:

@mars-solutions.de
@mars-group.de

Meist schreiben wir Ihnen von diesen vier Adressen:

Absenderadressen von mars solutions
Adresse	Wofür
helpdesk@mars-solutions.de	Technischer IT-Support, Tickets und Rückfragen zu Ihren Anfragen
it-notfall@mars-solutions.de	Soforthilfe bei IT-Notfällen
vertrieb@mars-solutions.de	Angebote, Verträge und Lizenzen
verwaltung@mars-solutions.de	Rechnungen und kaufmännische Fragen

Daneben erhalten Sie auch Mails von anderen Adressen, etwa direkt von Ihrem Ansprechpartner. Auch diese enden immer auf @mars-solutions.de oder @mars-group.de.

Wichtiger Hinweis

Kommt eine Mail von einer anderen Domain, stammt sie nicht von uns. Das gilt auch dann, wenn als Name „mars solutions“ angezeigt wird.

Phishing-Mails erkennen in fünf Schritten

Die folgenden fünf Prüfungen dauern zusammen weniger als eine Minute und funktionieren bei jeder Mail. Als Beispiel dienen unsere Adressen.

1

Anzeigename und Absenderadresse unterscheiden

Jede Mail hat zwei Angaben zum Absender. Der Anzeigename ist der Text, den Ihr Mailprogramm groß anzeigt, etwa „mars solutions Support“. Die Absenderadresse ist die eigentliche E-Mail-Adresse, etwa helpdesk@mars-solutions.de.

Den Anzeigenamen kann jeder frei wählen. Ein Betrüger schreibt dort einfach einen bekannten Namen hinein. Aussagekräftig ist nur die Adresse:

Anzeigename und Absenderadresse im Vergleich
Anzeigename	Absenderadresse	Ergebnis
mars solutions Helpdesk	helpdesk@mars-solutions.de	Echt, von uns
mars solutions Helpdesk	support@rechnung-portal.com	Gefälscht, nicht von uns

So sehen Sie die Absenderadresse:

Outlook am PC: Die Adresse steht meist in spitzen Klammern hinter dem Namen, etwa mars solutions Helpdesk . Sehen Sie nur den Namen, klicken Sie darauf. Die Kontaktkarte zeigt dann die vollständige Adresse.
Outlook im Browser: Fahren Sie mit der Maus über den Namen oder klicken Sie darauf. Die Adresse erscheint im eingeblendeten Fenster.
Smartphone: Tippen Sie auf den Absendernamen. Erst dann zeigt die App die vollständige Adresse an.

Fehlt die Adresse ganz oder lässt sie sich nicht anzeigen, behandeln Sie die Mail als verdächtig.

2

Die Domain genau lesen

Betrüger nutzen gern Adressen, die echt aussehen. Achten Sie auf kleine Abweichungen, hier am Beispiel unserer Domain:

mars-solution.de (ein Buchstabe fehlt)
mars-soIutions.de (großes i statt kleinem L)
marsgroup.de (Bindestrich fehlt)
mars-solutions.de.example.com (die echte Domain steht nur vorne)
mars-solutions-support.com (andere Endung, Zusatzwort)

Maßgeblich ist immer der Teil direkt hinter dem @ bis zum Ende. Bei uns muss er exakt mars-solutions.de oder mars-group.de lauten.

Auch eine korrekte Adresse ist kein vollständiger Beweis, denn in seltenen Fällen lässt sie sich ebenfalls fälschen. Wirkt eine Mail trotz richtiger Adresse ungewöhnlich, fragen Sie beim Absender kurz telefonisch nach.

3

Links prüfen, ohne zu klicken

Fahren Sie mit der Maus über einen Link, ohne zu klicken. Unten links im Fenster oder in einem kleinen Feld sehen Sie dann das echte Linkziel. Passt es nicht zum angeblichen Absender, klicken Sie nicht. Das BSI rät außerdem, bekannte Adressen lieber selbst in den Browser einzugeben, statt einem Link aus einer Mail zu folgen.

4

Auf Druck und ungewöhnliche Bitten achten

Typisch für Phishing sind Sätze wie „Ihr Konto wird heute gesperrt“ oder „Bitte sofort bestätigen“. Seriöse Absender fordern Sie nie per Mail auf, ein Kennwort einzugeben, eine Rechnung an eine neue Bankverbindung zu zahlen oder unerwartete Anhänge zu öffnen. Das gilt auch für mars solutions.

5

Die Antwortadresse prüfen

Klicken Sie auf „Antworten“, ohne die Mail abzuschicken. Steht im Feld „An“ plötzlich eine fremde Adresse, ist die Mail gefälscht.

Wichtig für IT-Admins

Wer eine verdächtige Mail genauer prüfen will, wirft einen Blick in den Nachrichtenkopf. Die Felder Return-Path und Reply-To zeigen, wohin Rückläufer und Antworten tatsächlich gehen. Der Eintrag Authentication-Results zeigt, ob die Prüfungen SPF, DKIM und DMARC bestanden wurden.

So gehen Sie bei Phishing-Verdacht vor

1

Fragen Sie beim Absender nach.

Nutzen Sie dafür einen Weg, den Sie bereits kennen, nicht eine Nummer aus der verdächtigen Mail. mars solutions erreichen Sie unter +49 7161 65492-50.

2

Melden Sie die Mail Ihrer IT.

Kunden von mars solutions leiten sie an helpdesk@mars-solutions.de weiter. Wir prüfen sie.

3

Löschen Sie die Mail danach.

Sie muss nicht in Ihrem Postfach bleiben.

Wichtiger Hinweis

Haben Sie bereits auf einen Link geklickt oder Daten eingegeben? Dann informieren Sie sofort Ihre IT. Kunden von mars solutions erreichen unsere IT-Notfall-Hotline unter +49 7161 654926-112. Je früher reagiert wird, desto geringer ist der Schaden.

Phishing-Schutz durch Technik und Schulung

Das Erkennen von Phishing-Mails bleibt Aufgabe jedes einzelnen Empfängers. Drei Maßnahmen senken jedoch die Zahl gefälschter Mails im Postfach und das Risiko, dass jemand darauf hereinfällt.

Mailfilter mit Phishing-Erkennung

Ein vorgeschalteter Filter prüft eingehende Mails auf bekannte Betrugsmuster, gefälschte Absender und schädliche Links oder Anhänge. Ein großer Teil der Phishing-Mails wird so abgefangen, bevor ein Mitarbeiter sie sieht.

Hintergründe dazu stehen in unserem Beitrag Phishing und Spam im Unternehmen.

Phishing-Simulationen für Mitarbeiter

Realistische, aber harmlose Test-Mails zeigen, wie aufmerksam die Belegschaft ist. Wer auf eine Testmail hereinfällt, erhält direkt eine kurze Schulung. Aufmerksame Mitarbeiter fangen so ab, was ein Filter durchlässt.

Mehr dazu im Beitrag Dein wichtigstes Sicherheits-Upgrade sitzt vor dem Bildschirm.

DMARC für die eigene Domain

Mit DMARC legen Sie fest, welche Server im Namen Ihrer Domain Mails versenden dürfen und was mit allen anderen passiert. Das erschwert es Betrügern, Ihre eigene Domain für gefälschte Mails an Kunden und Partner zu missbrauchen.

Die Grundlagen erklärt der Beitrag Mehr Sicherheit im E-Mail-Verkehr mit DMARC.

Bedeutung für Geschäftsführung und Entscheider

Gefälschte Mails im Namen bekannter Geschäftspartner wirken glaubwürdiger als allgemeiner Spam. Angreifer können dabei auch den Namen Ihres eigenen Unternehmens nutzen, um Ihre Kunden zu täuschen.

Das eigentliche Risiko sind die Folgen einer solchen Mail: abgegriffene Zugangsdaten zu Microsoft 365 oder anderen Diensten, eingeschleuste Schadsoftware oder Zahlungen auf ein fremdes Konto. Sind personenbezogene Daten betroffen, kommt die Meldepflicht nach DSGVO innerhalb von 72 Stunden hinzu.

Der Aufwand für die Vorbeugung ist gering. Eine kurze Information an alle Mitarbeiter, woran echte Absender zu erkennen sind, und die feste Regel, Zahlungsänderungen nie allein auf Grundlage einer Mail umzusetzen, schließen die häufigsten Einfallstore. Technische Maßnahmen wie Mailfilter und DMARC verringern zusätzlich, wie viele gefälschte Mails überhaupt ankommen.

FAQ zu Phishing-Mails

Woran erkenne ich, ob eine Mail wirklich vom angezeigten Absender kommt?

An der Absenderadresse. Sie muss auf die Domain des Absenders enden, bei mars solutions also auf @mars-solutions.de oder @mars-group.de. Der angezeigte Name allein sagt nichts aus, weil ihn jeder frei wählen kann.

Reicht eine korrekte Absenderadresse als Beweis?

Nur bedingt, denn in seltenen Fällen lässt sich auch eine korrekte Adresse fälschen. Wirkt eine Mail trotz richtiger Adresse ungewöhnlich, etwa wegen einer neuen Bankverbindung oder einer Kennwortabfrage, fragen Sie über einen bekannten Weg beim Absender nach.

Wie sehe ich die Absenderadresse am Smartphone?

Tippen Sie auf den Absendernamen. Erst dann zeigt die Mail-App die vollständige Adresse an. Lässt sie sich nicht anzeigen, behandeln Sie die Mail als verdächtig.

Was tue ich, wenn ich bereits auf einen Link geklickt habe?

Informieren Sie sofort Ihre IT. Kunden von mars solutions erreichen unsere IT-Notfall-Hotline unter +49 7161 654926-112. Je früher reagiert wird, desto eher lassen sich betroffene Konten sperren und Schäden begrenzen.

Kann jemand Mails im Namen von mars solutions verschicken?

Ja, den Namen kann jeder in eine Mail schreiben. Entscheidend ist die Absenderadresse: Echte Mails von uns kommen nur von @mars-solutions.de oder @mars-group.de. Kennwörter oder neue Bankdaten fordern wir nie per Mail an.

Fazit

Phishing-Mails setzen auf bekannte Namen und auf Zeitdruck. Wer Phishing-Mails erkennen will, prüft zuerst die Absenderadresse, denn der Anzeigename beweist nichts. Bei mars solutions sind nur @mars-solutions.de und @mars-group.de echt, bei jedem anderen Absender gilt dasselbe Prinzip mit seiner eigenen Domain. Im Zweifel hilft ein kurzer Anruf über einen bekannten Weg mehr als jeder Klick.

Weitere interessante Beiträge

IT-News

Phishing trotz MFA: So hebeln Angreifer den zweiten Faktor aus

12. November 2026

Zum Blogbeitrag

mars-News

Wir sind Hauptsponsor des TSG Salach: Heimvorteil in Sachen IT

11. September 2026

Zum Blogbeitrag

IT-News

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

17. September 2026

Zum Blogbeitrag

Fanden Sie den Blogbeitrag hilfreich und interessant?

Vielen Dank für Ihre Rückmeldung!

Der Beitrag Phishing-Mails erkennen: So entlarven Sie gefälschte Absender erschien zuerst auf 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

Phishing-Mails erkennen: So entlarven Sie gefälschte Absender

29. Oktober 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 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

mars-News

mars Events - Sommer / Herbst 2026

30. September 2026

Zum Blogbeitrag

IT-News

Phishing trotz MFA: So hebeln Angreifer den zweiten Faktor aus

12. November 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

OpenSSH Sicherheitslücke - SSHole (CVE-2026-123158)

10. November 2026

Zum Blogbeitrag

IT-News

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

7. September 2026

Zum Blogbeitrag

IT-News

Cyberangriff LMU München: Stammdaten von Studierenden abgeflossen

22. 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.