Die Schwachstelle unter aktivem Angriff

Das ist keine theoretische Warnung; die Lücke wird gerade ausgenutzt. Am 17. Juli 2026 setzte die US-Cyberbehörde CISA CVE-2026-58644, eine kritische Microsoft-SharePoint-Server-Schwachstelle, auf ihren Katalog bekannter ausgenutzter Schwachstellen und wies die zivilen Bundesbehörden an, sie bis zum 19. Juli zu patchen. Der Fehler ist eine Deserialisierung nicht vertrauenswürdiger Daten mit einem Schweregrad von 9,8 von 10, die es einem Angreifer ohne Zugangsdaten erlaubt, beliebigen Code auf dem Server auszuführen.

Er steht nicht allein. Eine Gruppe von SharePoint-Server-Lücken wird in freier Wildbahn verkettet, um die Authentifizierung zu umgehen, Codeausführung aus der Ferne zu erlangen und Folgeaktivitäten durchzuführen. Selbst gehostetes SharePoint hat hier eine lange Geschichte: Seit Ende 2021 haben Behörden fast ein Dutzend seiner Schwachstellen als in Angriffen ausgenutzt gekennzeichnet, und die meisten davon wurden später in Ransomware verwendet.

Warum ein Patch allein Sie nicht rettet

Das Gefährliche ist, was die Angreifer auf dem Weg hinein mitnehmen. Bei der Ausnutzung stehlen sie die kryptografischen Maschinenschlüssel des Servers, die Geheimnisse, mit denen SharePoint die Token signiert und prüft, die Zugriff gewähren. Sobald ein Angreifer diese Schlüssel besitzt, kann er nach Belieben gültige Zugangsdaten fälschen, und zwar gegen einen Server, den Sie bereits aktualisiert haben.

Das ist die Falle bei diesem Vorfall. Microsofts Patch schließt das Loch, durch das der Eindringling kam, aber er ändert nichts an den Schlüsseln, die dieser bereits kopiert hat. Ein gepatchter, voll aktualisierter SharePoint Server kann mit gestohlenen Schlüsseln trotzdem wieder betreten werden, weshalb die Behebung hier nicht mit dem Patch erledigt ist. Wenn Sie die Maschinenschlüssel nicht rotieren, glauben Sie sich vielleicht sicher, während die Tür leise offen bleibt.

Wer tatsächlich gefährdet ist

Das ist ein On-Premises-Problem, kein Cloud-Problem. Die Schwachstelle betrifft selbst gehostetes SharePoint Server, die Version, die eine Organisation auf ihrer eigenen Infrastruktur betreibt. Microsoft 365 SharePoint Online, der gehostete Dienst, ist nicht das Ziel dieser konkreten Angriffe. Das Risiko konzentriert sich also genau auf die Installationen, die viele europäische Mittelständler, Behörden, Kanzleien und Finanzhäuser im Haus behalten.

Oft behalten sie es aus guten Gründen im Haus: Datenresidenz, Branchenregeln oder die Entscheidung, sensible Dokumente auf selbst kontrollierter Infrastruktur zu halten. Diese Wahl ist legitim, aber sie bedeutet auch, dass Patchen, Schlüsselrotation und Überwachung ganz in Ihrer Verantwortung liegen. Die Bequemlichkeit, die ein Cloud-Anbieter still erledigt hätte, ist On-Premises eine Aufgabe mit Ihrem Namen darauf und einer laufenden Uhr.

Was das nach EU-Recht bedeutet

Die US-Frist bindet Sie nicht, die Dringlichkeit schon. Der 19. Juli gilt für amerikanische Bundesbehörden; ein europäischer Betreiber ist ihm rechtlich nicht verpflichtet. Behandeln Sie ihn stattdessen als öffentliches Signal, wie schnell sich das bewegt, denn dieselben Server und derselbe Exploit-Code machen an keiner Grenze halt. Nationale Stellen wie das deutsche BSI und das britische NCSC geben zu genau solchen aktiv ausgenutzten Lücken eigene Warnungen heraus.

Unter NIS2 und, für Finanzunternehmen, DORA ist ein erfolgreicher Einbruch hier ein meldepflichtiger Vorfall mit engen Fristen und Verantwortung auf Vorstandsebene. Ein Dokumentenspeicher voller Verträge, personenbezogener Daten und interner Unterlagen ist genau das Gut, zu dessen Schutz diese Regeln existieren. Beim Patchen einer bekannten, ausgenutzten Schwachstelle langsam zu sein, ist die Art von Versäumnis, die eine Aufsicht als Fahrlässigkeit liest, nicht als Pech.

Was jetzt zu tun ist

Gehen Sie der Reihe nach vor und nehmen Sie das Schlimmste an, wo Sie das Gegenteil nicht beweisen können. Spielen Sie Microsofts SharePoint-Server-Updates sofort ein, rotieren Sie dann die IIS-Maschinenschlüssel, damit gestohlene Schlüssel nutzlos werden. Suchen Sie nach Anzeichen einer Kompromittierung: unerwartete Web-Shells, unbekannte Dateien in den Serververzeichnissen, neue oder veränderte Schlüssel und Anmeldeereignisse, die nicht zu Ihren Nutzern passen. Verkleinern Sie die Angriffsfläche, indem Sie jedes aus dem Internet erreichbare SharePoint vom offenen Netz nehmen, wo es geht.

War Ihr Server seit der Offenlegung zu irgendeinem Zeitpunkt erreichbar und ungepatcht, behandeln Sie ihn als kompromittiert und ermitteln Sie auf dieser Grundlage, statt zu hoffen, er sei übersehen worden. Die Kosten, eine nicht vorhandene Kompromittierung anzunehmen, sind ein paar Stunden Prüfung; die Kosten, eine nicht vorhandene Sicherheit anzunehmen, sind der Vorfall selbst.