Die Kette, erklärt

CVE-2026-55040 ist eine Umgehung der JWT-Token-Validierung, die es einem entfernten, nicht authentifizierten Angreifer erlaubt, sich als SharePoint-Nutzer oder -Administrator auszugeben. CVE-2026-63520 ist eine separate Schwachstelle in den Business Connectivity Services von SharePoint, eine unsichere .NET-Typinstanziierung, mit der ein Angreifer eine eigene Objektkette baut, um Betriebssystembefehle mit den Rechten des SharePoint-Dienstkontos auszuführen. Für sich allein ist keine der beiden Lücken katastrophal, doch Rapid7-Forscher Stephen Fewer meldete beide bereits im Mai als eine zusammenhängende Kette an Microsoft, und gemeinsam ergeben sie unauthentifizierte Remotecodeausführung gegen SharePoint Server Subscription Edition, SharePoint Server 2019 und SharePoint Enterprise Server 2016.

Microsoft behob die beiden Hälften nach unterschiedlichem Zeitplan: CVE-2026-55040 kam mit dem Juli-2026-Patchday, CVE-2026-63520 folgte einen Monat später am 11. August 2026, zusammen mit den Knowledge-Base-Updates KB5002893, KB5002894, KB5002896, KB5002905 und KB5002906 für die verschiedenen betroffenen Produktversionen. Rapid7 zufolge gibt es bislang keine bestätigte Ausnutzung der vollständigen RCE-Kette in freier Wildbahn, da die Offenlegung koordiniert erfolgte. Für die erste Hälfte sieht es anders aus.

Warum die Aufteilung des Patches auf zwei Monate zählt

Rapid7 veröffentlichte eine ausführliche technische Analyse samt Proof-of-Concept für CVE-2026-55040, und die Threat-Intelligence-Firma Defused erklärt, ihre SharePoint-Honeypots hätten bereits echte Angreifer erfasst, die diesen öffentlichen Proof-of-Concept schon wenige Tage nach Veröffentlichung zur Authentifizierungsumgehung nutzten. Microsoft selbst hat eine Ausnutzung in freier Wildbahn noch nicht bestätigt, doch ein unabhängiges Erkennungsnetzwerk, das reale Versuche einfängt, ist ein starkes Signal dafür, dass opportunistisches Scannen bereits begonnen hat.

Der unangenehme Teil ist der Kalender. Weil die beiden Hälften der Kette im Abstand von einem Monat gepatcht wurden, glaubte eine Organisation, die den Juli-Fix pflichtbewusst einspielte, wochenlang, das Authentifizierungsproblem sei geschlossen, während die zweite, RCE-vervollständigende Hälfte bis zum 11. August ungepatcht blieb. Wer beide August-KB-Updates und den Juli-Fix noch nicht zusammen eingespielt hat, betreibt derzeit einen dokumentierten, öffentlich vorgeführten Pfad zu unauthentifizierter Codeausführung auf dem eigenen SharePoint-Server -- keinen theoretischen.

Was Sie in Ihrer eigenen SharePoint-Umgebung prüfen sollten

Dies ist eindeutig ein On-Premises-Problem: SharePoint Online ist nicht betroffen, aber Installationen von SharePoint Server 2016, 2019 und Subscription Edition sind bei europäischen und britischen Behörden, Universitäten und mittelständischen Unternehmen weit verbreitet, die nie vollständig in die Cloud migriert sind. Die praktische Checkliste besteht darin, zu bestätigen, dass beide KB-Updates aus Juli und August gemeinsam installiert sind, nicht nur eines davon, denn ein Teilpatch lässt die Kette intakt.

Der Standardrat der CISA lohnt sich unabhängig vom Patchstatus: einen On-Premises-SharePoint-Server nicht direkt dem Internet aussetzen, und wo er erreichbar sein muss, hinter einen Layer-7-Reverse-Proxy oder eine äquivalente Kontrolle auf Anwendungsebene stellen, die genau die Art von präparierten Anfragen filtern kann, auf die diese Kette angewiesen ist. Da für die Hälfte der Kette bereits ein funktionierender, öffentlicher Proof-of-Concept existiert, sollte dies diese Woche als aktiver Incident-Response-Posten behandelt werden, nicht als Routinepunkt im Patchzyklus.

Weiterlesen: Der SharePoint-Patch, den Sie im Mai übersprungen haben, ist jetzt dringend  |  Gunra-Ransomware Nutzt Fortinet-Lücken von 2025