CISA markiert SharePoint Zero-Day CVE-2026-58644 mit 48-Stunden-Patch-Frist

Jeder alte Hafen hat diesen einen Holzsteg, den die Einheimischen Planke für Planke flicken. Schiffe legen noch an, Fracht wird noch bewegt, aber jeder Wintersturm reißt ein weiteres Brett heraus und irgendjemand läuft nach Nägeln. SharePoint On-Premises ist dieser Steg. Die Nachrichten vom Donnerstag sind nur die neueste fehlende Planke.

CISA hat CVE-2026-58644, eine kritische Remote-Code-Execution-Schwachstelle in SharePoint Server, am 17. Juli 2026 in den Known Exploited Vulnerabilities-Katalog aufgenommen und den Bundesbehörden der Federal Civilian Executive Branch mitgeteilt, dass sie bis zum 19. Juli Zeit haben, diese zu schließen. Zwei Tage. Das ist die Art von Frist, die man nur sieht, wenn das Wasser bereits über die Dielen kommt.

Was passiert ist

Die Schwachstelle hat einen CVSS-Score von 9.8, was so ziemlich dem Maximum entspricht. Microsoft klassifiziert sie als kritischen Deserialisierungsfehler bei nicht vertrauenswürdigen Daten, der es einem nicht autorisierten Angreifer ermöglicht, beliebigen Code auf dem SharePoint Server auszuführen. Microsofts eigene Advisory-Formulierung macht es deutlich: „In einem netzwerkbasierten Angriff könnte ein Angreifer, der mindestens als Site Owner authentifiziert ist, beliebigen Code einschleusen und diesen remote auf dem SharePoint Server ausführen."

Patches wurden als Teil des Patch Tuesday vom 14. Juli 2026 ausgeliefert, aber Microsoft überarbeitete sein Bulletin später und gab zu, dass die Schwachstelle bereits als Zero-Day in freier Wildbahn ausgenutzt worden war, bevor die Fixes verfügbar waren, wie The Hacker News berichtete. Diese Formulierung „Bulletin überarbeitet" trägt eine Menge Gewicht. Sie bedeutet, dass jemand bereits drin war, bevor die Verteidiger informiert wurden.

Die betroffenen Systeme umfassen die gesamte On-Premises-Produktlinie: SharePoint Server Subscription Edition, SharePoint Server 2019 und SharePoint Enterprise Server 2016. CISA hat außerdem drei verwandte CVEs (CVE-2026-32201, CVE-2026-45659 und CVE-2026-56164) als Teil desselben aktiven Ausnutzungsclusters markiert und gewarnt, dass das Post-Exploitation-Vorgehen das Stehlen von IIS Machine Keys und das Verketten weiterer Deserialisierungstricks umfasst, um Persistenz zu erlangen und Malware einzuschleusen.

Zusätzlich hat CISA am selben Tag zwei Fortinet FortiSandbox-Schwachstellen (CVE-2026-25089 und CVE-2026-39808) in den KEV-Katalog aufgenommen, ebenfalls mit der Bundesfrist 19. Juli. Der Donnerstag war kein ruhiger Tag für niemanden, der ein Notfall-Change-Window betreibt.

Technische Analyse

Deserialisierungsfehler sind die Kakerlaken der Unternehmenssicherheit. Man kann ein Jahrzehnt lang dagegen ankämpfen, und sie verstecken sich trotzdem hinter dem Kühlschrank. Das Muster ist immer dasselbe: Eine Komponente akzeptiert ein serialisiertes Datenobjekt (einen .NET-Objektgraph, eine ViewState-Payload, eine gecachte ASP.NET-Sitzung) und rehydriert es in lebende Objekte, ohne ordnungsgemäß zu prüfen, welchen Typ es gerade instanziiert. Gibt man dem Deserialisierer eine Gadget-Chain, lässt sich aus „lade dieses Objekt" in einem Schritt „führe diesen Code aus" machen.

Bei SharePoint wird dieses Problem durch IIS Machine Keys noch verschärft. Der Machine Key ist das gemeinsame Geheimnis, das zum Signieren und Verschlüsseln von ViewState und anderen serverseitigen Daten verwendet wird. Jeder, der Incident Response auf einem ASP.NET-Server durchgeführt hat, kennt das Muster: Sobald ein Angreifer den Machine Key hat, kann er nach Belieben signierte ViewState-Payloads fälschen, sie durch die Vordertür zurückspielen und Deserialisierungs-Sinks mit legitim aussehendem, kryptographisch gültigem Input treffen. Deshalb konzentriert sich die von CISA beschriebene Post-Exploitation-Aktivität auf die Entwendung von Machine Keys. Das RCE ist der Eingang; der Key ist der Weg, drin zu bleiben.

Microsofts eigene Hinweise zur Angriffskomplexität bei CVE-2026-58644 lesen sich wie eine Checkliste für ein skriptbares Exploit. Die Angriffskomplexität ist gering. Es sind keine nennenswerten Vorkenntnisse des Systems erforderlich. Wiederholbarer Erfolg mit der Payload gegen die verwundbare Komponente. Aus dem CVSS-Jargon ins Alltägliche übersetzt: Tool auf Server richten, Shell bekommen, morgen wiederholen.

Ja, Microsofts Formulierung besagt, dass der Angreifer „mindestens als Site Owner authentifiziert" sein muss. Darauf würde ich mich nicht als Schutzmaßnahme verlassen. Site Owner ist keine Vertrauensgrenze für Nationalstaaten. Es ist eine Rolle, die in den meisten großen SharePoint-Farmen dutzendfach vergeben wird, und wenn der Angreifer phishen, eine Sitzung kapern oder einen Token von einem kompromittierten Endpunkt in ein Site-Owner-Konto einschleusen kann, ist die Authentifizierungsanforderung hinfällig. Der Steg ist immer noch der Steg.

Wer betroffen ist

Bundesbehörden sind die offensichtlichen ersten Betroffenen, schlicht weil die KEV-Frist für sie rechtlich bindend ist. Zwei Tage, um einen Patch über jede On-Premises-SharePoint-Farm hinweg zu testen und einzuspielen, ist kein komfortabler Zeitrahmen. Jeder, der schon einmal ein kumulatives SharePoint-Update um 3 Uhr morgens eingespielt, die Timer-Jobs der Central Administration langsam wieder zum Leben erwacht gesehen und gebetet hat, dass der Suchindex nicht beschädigt ist, weiß, dass das keine Routinearbeit ist.

Der größere Schadensradius liegt im privaten Sektor, der keinen vergleichbaren 48-Stunden-Countdown hat. Back-Office-Teams im Finanzwesen, Versicherungsgesellschaften, Gesundheitssysteme und Regierungsauftragnehmer betreiben noch enorme Mengen an institutionellem Wissen auf SharePoint 2016 und 2019. Im Fintech- und iGaming-Bereich ist On-Premises-SharePoint oft die Intranet-Schicht, auf der KYC-Verfahren, Compliance-Memos, Incident-Postmortems und Lieferantenverträge gespeichert sind. Genau die Art von Inhalten, die ein Angreifer lesen möchte, bevor die Ransomware-Nachricht verschickt wird.

Zahlungsplattformen und lizenzierte Betreiber in regulierten Branchen sollten besonders aufmerksam sein. Wenn die SharePoint-Farm im selben Active Directory-Forest wie die Produktionsidentitätsebene liegt (was meist der Fall ist), kann Machine-Key-Diebstahl kombiniert mit Lateral Movement in einem Golden-SAML-Angriff oder einer domänenweiten Kompromittierung enden. Die Schwachstelle selbst ist ein SharePoint-Fehler; der dadurch ausgelöste Vorfall ist ein unternehmensweiter Identitätsvorfall.

Ad-Tech- und Kryptounternehmen, die On-Premises-SharePoint vor Jahren zugunsten von Google Workspace oder Notion aufgegeben haben, erleben eine seltene ruhige Woche. Alle anderen müssen sich beeilen. In den nächsten 90 Tagen ist mit einem langsamen Rinnsal von „unbefugtem Zugriff"-Meldungen mittelständischer Unternehmen zu rechnen, die am 20. Juli oder später gepatcht haben und erst im September feststellen, dass Machine Keys bereits Anfang Juli das Haus verlassen haben.

Maßnahmenplan für Security-Teams

Beginnen Sie mit dem langweiligen Teil. Spielen Sie die Patch-Tuesday-Updates vom 14. Juli auf jeder SharePoint Subscription Edition-, 2019- und 2016-Farm ein, die Sie betreiben. Überprüfen Sie, ob der Patch tatsächlich angewendet wurde, denn SharePoints Update-Pipeline hat eine lange Geschichte von „installiert, aber nicht wirklich"-Zuständen. Gehen Sie dann von einer Kompromittierung aus, bis Sie das Gegenteil beweisen können.

CISAs Härtungsliste ist es wert, vollständig gelesen zu werden, aber der Kern lautet wie folgt. Aktivieren Sie die Antimalware Scan Interface (AMSI)-Integration für jede SharePoint-Webanwendung. Suchen Sie nach Artefakten der Machine-Key-Entwendung, bevor Sie Keys rotieren, denn einen gestohlenen Key zu rotieren, ohne den Angreifer zu vertreiben, sagt ihm nur, dass er den neuen nehmen soll. Entfernen Sie SharePoint Central Administration von jeder Schnittstelle, die vom Internet aus erreichbar ist, und hinterfragen Sie dabei, ob das SharePoint-Frontend überhaupt über das Internet erreichbar sein muss.

Auf der Erkennungsseite ordnen Sie das Post-Exploitation-Verhalten den MITRE ATT&CK-Techniken zu, die Ihr SIEM bereits kennt: T1505.003 (Web Shell), T1552 (ungesicherte Anmeldedaten über Machine Keys) und die deserialisierungsgesteuerten Ausführungspfade unter T1059. Tunen Sie das Logging für w3wp.exe-Kindprozesse und für ungewöhnliche .NET-Assembly-Ladevorgänge innerhalb der SharePoint-App-Pools. Wenn Ihr EDR nicht anschlägt, wenn powershell.exe aus einem IIS-Arbeitsprozess heraus gestartet wird, ist das der Alert, den Sie heute Nacht erstellen müssen.

Noch eine Sache. Wenn Sie als CTO SharePoint noch im Jahr 2026 On-Premises betreiben, weil „Migration ein Projekt für nächstes Jahr ist", ist diese Woche das Memo, das Sie dem Vorstand vorlegen können. Nächstes Jahr ist bereits mehrmals gekommen.

Wichtigste Erkenntnisse

• CVE-2026-58644 ist ein CVSS 9.8-Deserialisierungs-RCE in SharePoint Server, der als Zero-Day ausgenutzt wurde, bevor der Patch-Tuesday-Fix vom 14. Juli 2026 ausgeliefert wurde.
• CISA gab Bundesbehörden bis zum 19. Juli 2026 Zeit zum Patchen, zusammen mit zwei FortiSandbox-Schwachstellen (CVE-2026-25089, CVE-2026-39808), die am selben Tag in KEV aufgenommen wurden.
• Alle unterstützten On-Premises-SharePoint-Versionen sind betroffen: Subscription Edition, 2019 und 2016. Es gibt keine Hintertür für nicht unterstützte Versionen.
• Die Post-Exploitation konzentriert sich auf IIS-Machine-Key-Diebstahl, was bedeutet, dass Patchen allein einen entschlossenen Angreifer nicht vertreibt. Erst suchen, dann rotieren.
• Die Planke fault weiter. Wenn SharePoint in einem regulierten Umfeld noch Ihr Intranet-Backbone ist, ist dieser Vorfall Ihre Rechtfertigung, das Migrationsgespräch zu beschleunigen.