Hacker kombinieren zwei SharePoint-Schwachstellen zur vollständigen Serverübernahme

Eine Proof-of-Concept-Exploit-Kette gegen lokale Microsoft SharePoint Server wird inzwischen in realen Angriffen eingesetzt. Die Zeitspanne zwischen „Forschungsergebnis veröffentlicht“ und „Angreifer nutzt es aus“ betrug nur einen Tag. Das berichtet der Forscher Defused für CVE-2026-55040, die Authentifizierungsumgehung im Zentrum der aktuellen SharePoint-Exploiting-Welle, laut BleepingComputer.

Die Kette kombiniert zwei unterschiedliche Schwachstellen. CVE-2026-55040 ist eine JWT-Token-Authentifizierungsumgehung, die es einem nicht authentifizierten Angreifer ermöglicht, als SharePoint-Nutzer oder sogar als Administrator zu agieren, ohne jemals gültige Zugangsdaten vorlegen zu müssen. CVE-2026-63520 ist eine separate Schwachstelle in SharePoints Business Connectivity Services (BCS), die – nachdem die Authentifizierung umgangen wurde – mit der ersten Schwachstelle kombiniert werden kann, um auf einem ungepatchten Server vollständige Remote-Code-Ausführung zu erreichen. Stephen Fewer von Rapid7 veröffentlichte am 11. August Proof-of-Concept-Code für CVE-2026-55040. Jonathan Peterson von VulnCheck folgte am 24. August mit Proof-of-Concept-Code für CVE-2026-63520. Innerhalb von etwa zwei Wochen nach der ersten Offenlegung stand der Branche ein dokumentierter, funktionierender Weg von Null-Zugang bis zur Code-Ausführung auf einem SharePoint Server zur Verfügung.

Für Unternehmen, die weiterhin lokale SharePoint Server für den Austausch, die Speicherung oder die Zusammenarbeit an sensiblen Daten nutzen, ist dies keine entfernte Warnung. Es ist die Bestätigung, dass die Plattform weiterhin eine aktive Angriffsfläche für Cyberkriminelle darstellt, die die Authentifizierungs- und Integrationsmechanismen besser verstehen als die meisten Unternehmen, die sie betreiben. CVE-2026-55040 selbst wurde am 14. Juli 2026 im Rahmen einer Welle von SharePoint-Server-Patches behoben, die auch fünf Einträge im CISA Known Exploited Vulnerabilities Catalog hervorbrachte. Dass ein Patch seit Juli existiert, hat die Proof-of-Concept-Ausnutzung in diesem Monat nicht verhindert, weil ungepatchte Instanzen weiterhin erreichbar sind und die neu offengelegte BCS-Schwachstelle Angreifern einen neuen Weg bietet, die alte Umgehung in eine vollständige Kompromittierung umzuwandeln.

Dieser Beitrag erläutert, was die beiden CVEs tatsächlich bewirken, warum der Ein-Tages-Zeitraum bis zur Waffennutzung wichtiger ist als der CVSS-Score und was dieses Muster architektonisch für CISOs und Compliance-Verantwortliche bedeutet, die nachweisen müssen – nicht nur behaupten –, dass sensible Daten, die über Plattformen wie Kiteworks sichere Datenübertragung laufen, unter Kontrolle bleiben, unabhängig davon, was mit angrenzender Infrastruktur geschieht.

Wichtige Erkenntnisse

1. Es existiert jetzt eine funktionierende Exploit-Kette für lokale SharePoint Server.

CVE-2026-55040 (JWT-Authentifizierungsumgehung) und CVE-2026-63520 (eine Schwachstelle in den Business Connectivity Services) können kombiniert werden, um von Null-Zugang zur Remote-Code-Ausführung auf ungepatchten Servern zu gelangen.

2. Die Waffennutzung erfolgte innerhalb eines Tages.

Forscher Defused dokumentierte, dass der Proof-of-Concept-Code für CVE-2026-55040 bereits einen Tag nach der Veröffentlichung durch Rapid7 in realen Angriffen eingesetzt wurde. Veröffentlichung und Ausnutzung sind inzwischen nahezu gleichzeitige Ereignisse.

3. Ein Patch schließt die CVE, aber nicht die Architektur.

CVE-2026-55040 wurde am 14. Juli 2026 gepatcht, doch das zugrunde liegende Muster – Authentifizierungsumgehung, kombiniert mit Deserialisierung oder Integration-Layer-RCE – tritt bei lokalen SharePoint Servern immer wieder auf, weil die Angriffsfläche der Plattform strukturell ist.

4. Es geht um lokale SharePoint Server, nicht um SharePoint Online.

Die beiden zu verwechseln ist ein sachlicher Fehler, der Unternehmen zu falschen Schlüssen über ihre eigene Gefährdung verleitet; SharePoint Online war nicht Ziel dieser Exploit-Kette.

5. Die Compliance-Frage ist genauso wichtig wie die technische.

Für CISOs und Compliance-Beauftragte besteht das eigentliche Risiko nicht nur in der Übernahme des Servers, sondern in der Unfähigkeit, auf Abruf nachzuweisen, dass sensible Inhalte während des Zeitfensters der Gefährdung autorisiert, verschlüsselt und protokolliert wurden.

Was CVE-2026-55040 und CVE-2026-63520 tatsächlich bewirken

CVE-2026-55040 betrifft die Art, wie lokale SharePoint Server JWT (JSON Web Token) Authentifizierung validieren. Eine korrekt implementierte Token-Validierung sollte es Dritten rechnerisch unmöglich machen, eine gültige Sitzung zu fälschen. Diese Schwachstelle bricht diese Annahme. Ein Angreifer ohne Berechtigungen, ohne gültige Zugangsdaten und ohne vorherigen Zugang kann eine Anfrage konstruieren, die der SharePoint Server als legitimen Nutzer – oder im schlimmsten Fall als Administrator – akzeptiert. Das ist eine vollständige Authentifizierungsumgehung, keine Privilegienausweitung von einem bestehenden Low-Privilege-Account.

CVE-2026-63520, mit CVSS 8.1 (Hoch) bewertet laut VulnCheck, liegt in einem anderen Teil der Plattform: den Business Connectivity Services, der Integrationsschicht, mit der SharePoint externe Datenquellen wie Datenbanken, ERP-Systeme und individuelle Anwendungen anbindet. Die Ursache ist eine unsichere .NET-Typeninstanziierung, die es Angreifern ermöglicht, eine Deserialisierungskette auf Basis der System.Web.UI.LosFormatter-Klasse zu missbrauchen, um beliebigen Code auf dem Server auszuführen. BCS ist von Haus aus mächtig; es soll SharePoint ermöglichen, im Namen des Nutzers Daten in externen Systemen zu lesen und zu schreiben. Genau diese Designabsicht macht es gefährlich, sobald ein Angreifer die Authentifizierung umgangen hat. Eine Komponente, die für den Zugang zu externen Systemen gebaut wurde, wird in Kombination mit Angreifer-gesteuerten Eingaben zum Einfallstor für Remote-Code-Ausführung auf dem Server selbst.

Keine der beiden Schwachstellen ist für sich genommen ungewöhnlich. Authentifizierungsumgehungen sowie Deserialisierungs- oder Injektionslücken in Integrationsschichten treten immer wieder in Enterprise-Collaboration-Plattformen auf. Was diese Kombination besonders macht, ist ihre Einfachheit: CVE-2026-55040 verschafft dem Angreifer Zugang ohne Zugangsdaten, CVE-2026-63520 ermöglicht ihm anschließend die Code-Ausführung. Jede für sich ist gravierend, zusammen bilden sie einen vollständigen, nicht authentifizierten Weg zur Server-Kompromittierung – genau die Art von Schwachstelle, die zuerst als Proof-of-Concept auftaucht und dann, oft binnen Tagen, als aktive Angriffskampagne.

Vom Proof of Concept zur aktiven Ausnutzung in wenigen Tagen

Der Zeitfaktor ist der Aspekt, der in dieser Geschichte mehr Aufmerksamkeit verdient als die einzelnen CVE-Nummern. Stephen Fewer von Rapid7 veröffentlichte am 11. August Proof-of-Concept-Code für CVE-2026-55040. Laut Forscher Defused wurde dieser Code bereits am Folgetag in realen Angriffen eingesetzt. Jonathan Peterson von VulnCheck veröffentlichte am 24. August Proof-of-Concept-Code für CVE-2026-63520, was Angreifern etwa zwei Wochen später die zweite Hälfte der Kette lieferte.

Diese Beschleunigung ist nicht neu für 2026, wird aber immer kürzer – und lokale SharePoint Server sind ein wiederkehrendes Testfeld dafür. Ein Patch im Microsoft-Release-Kalender nützt einem Unternehmen nichts, wenn er nicht tatsächlich eingespielt wurde. Patch-Tuesday-Rhythmen sind nicht darauf ausgelegt, mit einer Ausnutzung am selben Tag zu konkurrieren. Sicherheitsteams, die die Veröffentlichung eines Proof-of-Concepts als Signal zum Start der Patch-Planung sehen, reagieren in der Praxis bereits zu spät, wenn sie die Warnung lesen.

Palo Alto Networks Unit42 analysierte die verwandte SharePoint-„ToolShell“-Kampagne 2025, eine frühere Authentifizierungsumgehung-zu-RCE-Kette gegen dieselbe On-Premises-Plattform, und kam zu dem klaren Schluss: „Patching alone is insufficient to fully evict the threat.“ Diese Erkenntnis entstand im Kontext von Angreifern, die nach einer Authentifizierungsumgehung lateral agierten und in einigen Fällen IIS-Maschinenschlüssel stahlen – Zugangsdaten, die einen Patch und die Entfernung von Webshells überdauern, weil sie nie rotiert wurden. Die gleiche Lektion lehrt auch die aktuelle Kette: Ein Server kann heute vollständig gepatcht sein und dennoch kompromittiert bleiben, wenn Zugangsdaten aus einem früheren Angriff nie ungültig gemacht wurden. Patching beantwortet die Frage „Ist diese spezifische Schwachstelle noch ausnutzbar?“ Es beantwortet nicht die Frage „Ist dieser Server und alles, was daran angeschlossen ist, noch vertrauenswürdig?“

Dies ist ein Muster, kein Einzelfall

Betrachtet man diese beiden CVEs im Kontext, wird ein Muster in der jüngeren Geschichte lokaler SharePoint Server sichtbar: Authentifizierungs- und Integrationsschicht-Schwachstellen werden miteinander verkettet, führen zu nicht authentifizierter Remote-Code-Ausführung und werden rasch als Proof-of-Concepts weaponized. Die Juli-2026-Welle, die CVE-2026-55040 patchte, führte auch zu CISAs SharePoint-Hardening-Alert vom 14. Juli 2026 und mehreren Einträgen im CISA Known Exploited Vulnerabilities Catalog, jeweils mit eigenen Fristen für die Behebung, gemessen in Tagen, nicht Monaten. Resecuritys Analyse dieser Angriffskette dokumentierte einen Ablauf von initialem, nicht authentifiziertem Zugang über Code-Ausführung, Webshell-Installation, Credential-Diebstahl bis hin zur lateralen Bewegung und Domain-Kompromittierung.

CVE-2026-63520 erweitert diese strukturelle Geschichte um eine neue Integrationsoberfläche. Es ist ein anderer Codepfad als die im Juli dokumentierten Deserialisierungslücken, führt aber über denselben Mechanismus zum gleichen Ergebnis: Eine Authentifizierungsschicht, die umgangen werden kann, leitet Anfragen an eine zweite Komponente weiter, die authentifizierten Zugriff erwartet und daher nie gegen Angreifer-gesteuerte Eingaben gehärtet wurde. Tenable weist in seinem FAQ zu verwandten SharePoint-CVEs auf dasselbe hin: Es handelt sich weniger um isolierte Programmierfehler als um wiederkehrende Symptome einer Plattform, bei der Authentifizierung, Deserialisierung und Integration jeweils eigene Angriffsflächen bieten – und ein Fehler in einer Komponente mit einem Fehler in einer anderen kombiniert werden kann, um eine vollständige Kompromittierung zu ermöglichen.

Für CISOs ist die entscheidende Frage nicht „Haben wir CVE-2026-55040 und CVE-2026-63520 gepatcht?“, sondern „Wie viele weitere Komponenten dieser Plattform bergen dasselbe Risiko, und wie erkennen wir das, bevor der nächste Proof of Concept es offenbart?“ Das ist eine Architekturfrage, keine Patch-Management-Frage – und sie hat keine Patch-Management-Antwort.

Warum Patching allein die Lücke nicht schließt

Drei Dinge sind gleichzeitig wahr – und Unternehmen, die nur den ersten Punkt beachten, bleiben oft noch Monate später verwundbar. Erstens: Microsoft hat am 14. Juli 2026 einen Patch für CVE-2026-55040 ausgeliefert, und Unternehmen, die ihn eingespielt haben, sind nicht mehr für diese spezifische Umgehung anfällig. Zweitens: Das Ein-Tages-Fenster bis zur Waffennutzung bedeutet, dass jedes Unternehmen, das den Patch nicht bereits vor Veröffentlichung des Proof-of-Concept-Codes eingespielt hatte, praktisch sofort der aktiven Ausnutzung ausgesetzt war – ohne nennenswerte Vorwarnzeit zwischen „theoretisch ausnutzbar“ und „wird tatsächlich ausgenutzt“. Drittens, und am wenigsten diskutiert: Das Patchen einer Schwachstelle macht nicht rückwirkend ungeschehen, was ein Angreifer während eines früheren Kompromittierungsfensters bereits erreicht, kopiert oder dauerhaft installiert hat.

Deshalb stellt sich für Compliance- und Audit-Verantwortliche eine andere, oft dringlichere Frage als für Security Engineers. Die Sicherheitsfrage lautet: „Ist der Server gepatcht?“ Die Compliance-Frage ist: „Können wir nachweisen, dass jedes sensible Dokument, das dieser Server während des Gefährdungszeitraums verarbeitet hat, ausschließlich von autorisierten Identitäten abgerufen wurde, und falls nicht, haben wir einen belastbaren, beweisfähigen Audit-Trail darüber, was genau exponiert wurde?“ HIPAA, CMMC und ITAR unterscheiden nicht zwischen „Wir wurden kompromittiert, weil wir nicht gepatcht haben“ und „Wir wurden einen Tag nach Verfügbarkeit eines Patches kompromittiert“. Regulierungsbehörden, Auditoren und gegnerische Anwälte werden fragen, welche Daten auf der Plattform lagen, wer darauf zugreifen konnte und was der Audit-Trail zeigt. Eine lokale SharePoint-Server-Umgebung, die für diese Nachweise erst individuell instrumentiert werden muss, startet im Ernstfall mit einem Nachteil.

Die Architekturfrage, die Compliance- und Sicherheitsverantwortliche stellen sollten

Kiteworks war bei diesem Vorfall nicht direkt im Datenpfad. Lokale SharePoint Server sind eine Microsoft-eigene Plattform, vor der Kiteworks nicht sitzt – und nichts hier ist als Behauptung zu verstehen, Kiteworks hätte diese Angriffskette verhindert. Die Parallele ist architektonisch, nicht hypothetisch.

Kiteworks sichere Datenübertragung setzt keine JWT-Token-Validierung wie bei CVE-2026-55040 ein und nutzt keine Business-Connectivity-Services-ähnliche Integrationsschicht für den Datenzugriff. Jede Anfrage – ob von Menschen oder Maschinen – läuft über die Kiteworks Control Plane, die Richtlinien pro Anfrage auf zero trust-Basis durchsetzt, statt dauerhafte, sitzungsbasierte Vertrauensstellungen für Token-Präsentationen zu vergeben. Diese Unterscheidung ist entscheidend, weil genau Token-Fälschung und Sitzungs-Vertrauensfehler die aktuelle Exploit-Kette ermöglicht haben.

Die Compliance-Schicht unterhalb dieser Architektur ist ebenso wichtig wie die Architektur selbst. Kiteworks besitzt die FedRAMP High In-Process-Auszeichnung und hält seit 2017 durchgehend die FedRAMP Moderate Authorization – neun Jahre unabhängige Kontrolle, die lokal betriebene Software nicht selbst nachweisen kann; FedRAMP-Zertifizierung bezieht sich auf Managed Services, nicht auf Software, die Unternehmen eigenständig betreiben und absichern. Kiteworks unterstützt zudem 90 % der CMMC Level 2-Anforderungen out of the box, nutzt FIPS 140-3-validierte Verschlüsselung und hält SOC 2 Type II– und ISO 27001-Zertifizierungen sowie ITAR-, HIPAA-BAA-, DSGVO- und CCPA-Unterstützung. Das ist kein Anspruch auf Immunität gegen jede Schwachstellenkategorie – diesen Anspruch kann keine Plattform ehrlich erheben. Es ist eine Aussage darüber, welche Angriffsflächen – nicht authentifizierte JWT-Umgehung und Integrations-Layer-RCE über eine allgemeine Collaboration-Plattform – auf Kiteworks nicht zutreffen.

Für Unternehmen, die abwägen, wie sie sensible Workflows weiterhin über lokale SharePoint Server abwickeln, ist die praktische Frage nicht, ob SharePoint komplett aufgegeben werden sollte. Es geht darum, welche Workflows regulierte oder sensible Inhalte betreffen, die besser auf einer Plattform aufgehoben wären, bei der Zugriffskontrollen, RBAC und beweisfähige Protokollierung integraler Bestandteil der Architektur sind – und nicht erst nachträglich durch individuelle Instrumentierung ergänzt werden müssen.

Was regulierte Unternehmen jetzt tun sollten

Überprüfen Sie umgehend den Patch-Status für CVE-2026-55040 und CVE-2026-63520, falls Sie lokale SharePoint Server 2016, 2019 oder Subscription Edition betreiben; SharePoint Online ist nicht betroffen. Belassen Sie es nicht bei der Patch-Bestätigung. Rotieren Sie IIS-Maschinenschlüssel und alle Zugangsdaten, auf die der Server Zugriff hatte, da Palo Alto Unit42 explizit festgestellt hat, dass „Patching alone is insufficient to fully evict the threat“ – insbesondere, weil Credential- und Schlüsselpersistenz einen Patch überdauern kann. Prüfen Sie Authentifizierungs- und Business-Connectivity-Services-Protokolle für das Zeitfenster zwischen Erstveröffentlichung und Patch-Einspielung und betrachten Sie jede Lücke in der Protokollierung als eigenen Befund, nicht nur als technische Unannehmlichkeit. Führen Sie abschließend eine Bestandsaufnahme durch, welche sensiblen oder regulierten Workflows weiterhin über lokale SharePoint Server laufen, und bewerten Sie, ob jeder einzelne den Incident-Response– und Nachweisaufwand dieser Plattform rechtfertigt – oder ob er besser auf Infrastruktur aufgehoben ist, die von Grund auf für regulierten, kontrollierten Datenaustausch gebaut wurde.

Erfahren Sie mehr darüber, wie Sie jede Datenanfrage über eine zero trust Control Plane statt über eine sitzungsbasierte Authentifizierungspipeline steuern: Vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen

• Blog-Beitrag Zero Trust Architecture: Never Trust, Always Verify
• Video Microsoft GCC High: Nachteile, die Verteidigungsauftragnehmer zu besseren Lösungen treiben
• Blog-Beitrag Wie man klassifizierte Daten absichert, sobald DSPM sie erkennt
• Blog-Beitrag Vertrauen in Generative KI mit einem Zero Trust-Ansatz aufbauen
• Video Der Leitfaden für IT-Leiter zur sicheren Speicherung sensibler Daten