SharePoint-Kette wird angegriffen: Zwei Lücken führen bis zur Codeausführung
Eine Behördenwarnung vom 28. August 2026 bestätigt Angriffe auf zwei verkettete Schwachstellen in lokal betriebenen Microsoft-SharePoint-Servern. CVE-2026-55040 umgeht die Authentifizierung; CVE-2026-63520 ermöglicht anschließend die Ausführung von Code. Die Warnung der Cyber Security Agency of Singapore stuft beide Lücken als aktiv ausgenutzt ein, verweist auf öffentlich verfügbaren Proof-of-Concept-Code und nennt die abgesicherten Versionsgrenzen.
Ein am 26. August veröffentlichter Bericht über SharePoint-Honeypots dokumentiert die konkreten Angriffsversuche seit dem 25. August: Auf die Ausnutzung der JWT-Schwachstelle folgten umfangreiche administrative Abfragen und Zugriffe auf den Business Data Catalog. Bei diesen Versuchen wurde noch keine erfolgreiche Codeausführung beobachtet. Betreiber müssen deshalb zwei Fragen getrennt beantworten: Erreicht ihre Farm den Mindest-Build ihrer Edition, und war sie vorher so exponiert, dass eine Kompromittierung untersucht werden muss?
Was bei den Angriffsversuchen beobachtet wurde
Die erfassten Anfragen folgten der bekannten Reihenfolge der beiden Schwachstellen. Zunächst wurde CVE-2026-55040 gegen die JWT-Prüfung eingesetzt. Danach suchten die Angreifer nach administrativen Strukturen und dem Business Data Catalog, der für den zweiten Schritt der Kette relevant ist.
Damit wurde nicht lediglich nach einer einzelnen offenen Schnittstelle gescannt. Die Aktivität erreichte beide Glieder des veröffentlichten Angriffspfads. Dennoch ist die Grenze des Befunds wichtig: Die Honeypot-Daten zeigen das Erproben der Kette, aber keine dort abgeschlossene Übernahme des Servers.
Das relativiert das Risiko nicht. Für beide Schwachstellen sind technische Details und funktionsfähige Angriffsmethoden öffentlich. Die dokumentierten Versuche zeigen, dass diese Informationen bereits gegen erreichbare SharePoint-Systeme eingesetzt werden.
Wie die beiden Lücken zur Codeausführung führen
CVE-2026-55040 betrifft die Validierung von JSON Web Tokens. Ein Angreifer ohne gültige Anmeldung kann die Authentifizierung umgehen und gegenüber SharePoint als Site-Benutzer oder Administrator auftreten. Dadurch wird eine Zugriffshürde beseitigt, die den nachfolgenden Angriff normalerweise verhindern würde.
CVE-2026-63520 liegt im Business-Data-Connectivity-Subsystem. Die technische Analyse von Rapid7 zeigt, dass ein manipuliertes BDC-Modell nicht ausreichend beschränkte .NET-Typen instanziieren und Eigenschaften setzen kann. Daraus kann die Ausführung von Betriebssystembefehlen mit den Rechten des Dienstkontos der betroffenen SharePoint-Site entstehen.
Allein erfordert CVE-2026-63520 einen authentifizierten Angreifer. CVE-2026-55040 beseitigt diese Voraussetzung. Zusammen bilden die beiden Lücken deshalb einen Pfad zur unauthentifizierten Codeausführung auf einem verwundbaren SharePoint-Server.
Diese Mindest-Builds müssen lokale Server erreichen
Ob eine Installation geschützt ist, entscheidet nicht die bloße Anzeige eines installierten Updates, sondern die tatsächlich erreichte Buildnummer. Für jede betroffene Edition gilt eine eigene Untergrenze:
- SharePoint Server Subscription Edition: Versionen vor 16.0.19725.20522 sind betroffen; erforderlich ist mindestens Build 16.0.19725.20522.
- SharePoint Server 2019: Versionen vor 16.0.10417.20198 sind betroffen; erforderlich ist mindestens Build 16.0.10417.20198.
- SharePoint Enterprise Server 2016: Versionen vor 16.0.5565.1001 sind betroffen; erforderlich ist mindestens Build 16.0.5565.1001.
Der vollständige Stand ist entscheidend, weil die Korrekturen für die beiden Schwachstellen aus unterschiedlichen Update-Zyklen stammen. Eine Installation, die nur gegen die Authentifizierungsumgehung aktualisiert wurde, bleibt für den vollständigen Angriffspfad anfällig. Maßgeblich ist mindestens die jeweils genannte Grenze oder ein neuerer, für dieselbe Edition freigegebener Sicherheitsstand.
In einer Farm muss die Kontrolle alle beteiligten Server umfassen. Ein einzelner Knoten unterhalb der Grenze kann den Schutz der Gesamtinstallation unterlaufen. Produktname, heruntergeladenes Paket oder ein erfolgreich beendeter Installationsdialog ersetzen daher nicht den Abgleich der laufenden Builds.
Warum ein Patch keine frühere Kompromittierung ausschließt
Ein Update verhindert die weitere Ausnutzung der geschlossenen Schwachstellen, beseitigt aber keine Spuren oder Veränderungen eines früheren Angriffs. War ein verwundbarer Server vor dem vollständigen Update direkt aus dem Internet erreichbar, sind Patchen und nachträgliche Untersuchung deshalb zwei getrennte Aufgaben.
Für die Untersuchung ist die beobachtete Reihenfolge ein sinnvoller Ausgangspunkt: auffällige JWT-Sitzungen, ungewöhnliche administrative Abfragen, Zugriffe auf den Business Data Catalog sowie neu angelegte oder veränderte BDC-Modelle. Ebenfalls relevant sind Betriebssystembefehle oder Prozesse, die durch den SharePoint-Webprozess beziehungsweise das Dienstkonto der Site ausgelöst wurden und nicht zum üblichen Betrieb passen.
Keines dieser Merkmale beweist für sich allein eine erfolgreiche Ausnutzung. Zusammengenommen können Protokolle, Konfigurationsänderungen und Prozessaktivitäten jedoch zeigen, ob nach der umgangenen Anmeldung auch der zweite Schritt erreicht wurde. Fehlen Aufzeichnungen aus dem Zeitraum vor dem Update, lässt sich ein früherer Zugriff unter Umständen nicht zuverlässig ausschließen.
Was jetzt bestätigt ist und was offenbleibt
Bestätigt sind Angriffsversuche gegen beide Teile der Kette, öffentlich verfügbare Angriffsmethoden und eine Behördenwarnung vor aktiver Ausnutzung. Ebenfalls bestätigt ist die technische Folge: Werden die Schwachstellen erfolgreich kombiniert, kann ein nicht angemeldeter Angreifer Code mit den Rechten des SharePoint-Site-Dienstkontos ausführen.
Für die konkret veröffentlichten Honeypot-Beobachtungen ist dagegen keine abgeschlossene Codeausführung dokumentiert. Offen bleibt außerdem, wie viele erreichbare Systeme tatsächlich verwundbar waren oder bereits kompromittiert wurden. Betreiber können diese Unsicherheit nicht allein durch die Installation des Updates auflösen: Sie müssen den Buildstand der gesamten Farm belegen und bei früherer Exposition die vorhandenen Spuren auswerten.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.