SharePoint CVE-2026-55040: Aktiv ausgenutzt, Patch liegt seit Juli bereit

SharePoint CVE-2026-55040 steht seit dem 18. August 2026 im KEV-Katalog der US-Cybersicherheitsbehörde CISA – also auf der Liste jener Schwachstellen, für die es Belege für aktive Ausnutzung gibt. Der Patch dafür liegt allerdings schon seit dem Juli-Patchday bereit. Wer ihn bis heute nicht eingespielt hat, betreibt seit über einem Monat einen ungepatchten SharePoint-Server – und seit dem 11. August kursiert dafür öffentlicher Exploit-Code.

Was hinter SharePoint CVE-2026-55040 steckt

Die Lücke sitzt in der Prüfkette für JWT-Token in SharePoint Server. Mehrere Fehler in dieser Pipeline erlauben es einem entfernten, nicht angemeldeten Angreifer, die Authentifizierung zu umgehen und Aktionen als beliebiger Benutzer einer SharePoint-Site auszuführen – bis hinauf zum Site-Administrator. Rapid7 und Microsoft führen den Fehler mit CVSS 3.1 auf 9.1 (kritisch), eingeordnet als CWE-1390 („Weak Authentication”).

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Betroffen sind die On-Premises-Varianten: SharePoint Server Subscription Edition, SharePoint Server 2019 und SharePoint Enterprise Server 2016. Microsoft hat die Lücke mit dem Juli-Patchday 2026 geschlossen – über KB5002882 (Build 16.0.19725.20434), KB5002883 (Build 16.0.10417.20175) und KB5002891 (Build 16.0.5561.1001).

Eine Voraussetzung gibt es: Der Angreifer muss vorher wissen, als welcher Benutzer er auftreten will – etwa über dessen Active-Directory-SID oder den User Principal Name. Und der Bypass ist nur die halbe Kette. Rapid7 hat ihn mit CVE-2026-63520 verbunden, einer unsicheren .NET-Typinstanziierung in den Business Connectivity Services (CVSS 8.1). Zusammen ergibt das unauthentifizierte Codeausführung auf dem Server. Diese zweite Hälfte hat Microsoft erst mit dem August-Patchday geschlossen: KB5002893 (16.0.19725.20522) für die Subscription Edition, KB5002894 und KB5002896 (16.0.10417.20198) für 2019 sowie KB5002905 und KB5002906 (16.0.5565.1001) für Enterprise Server 2016. Wer nur die Juli-Updates eingespielt hat, ist zwar aus der Angriffskette raus, hat die RCE-Lücke aber weiterhin offen.

Vom Wettbewerbs-Exploit zum Angriff in freier Wildbahn

Entdeckt hat die Lücke Stephen Fewer von Rapid7 Labs, ursprünglich als Beitrag für den Hacking-Wettbewerb Pwn2Own Berlin – dort scheiterte der Antritt am Wettbewerbstag. Rapid7 meldete die Exploit-Kette am 18. Mai 2026 an Microsoft und veröffentlichte den Bypass am 14. Juli. Die vollständige technische Analyse samt Proof-of-Concept folgte am 11. August.

Danach ging es schnell: Bereits am 13. August meldete die Threat-Intelligence-Firma Defused, dass Angreifer den Rapid7-PoC gegen ihre SharePoint-Honeypots einsetzen. Fünf Tage später folgte der KEV-Eintrag der CISA. Bemerkenswert ist auch, wie die Lücke gefunden wurde: Rapid7 beschreibt, dass ein erheblicher Teil der Arbeit über KI-Agenten lief – rund 80.000 Tool-Aufrufe in 96 Sessions über 24 Arbeitstage. Der erste Anlauf im Januar blieb ergebnislos, der zweite im März führte zur Exploit-Kette. Ohne fachliche Steuerung, so Rapid7, lieferte der Agent zu oft fragwürdige oder schlicht falsche Ergebnisse.

Was das für dich bedeutet

Aus CISO-Sicht ist das Spannende an diesem Fall nicht die Lücke, sondern das Zeitfenster. Zwischen Patch (14. Juli) und öffentlichem PoC (11. August) lagen exakt vier Wochen – zwischen PoC und ersten Angriffen keine zwei Tage. Genau dieses Muster hat sich in den letzten Monaten wiederholt, zuletzt bei SharePoint CVE-2026-50522. Wer monatliche Patchzyklen mit mehrwöchiger Testphase fährt, verliert dieses Rennen strukturell.

Zweitens: Die scheinbare Hürde „der Angreifer muss den Benutzer kennen” ist in der Praxis keine. Ein UPN sieht aus wie eine Mailadresse und ist bei den meisten Organisationen aus Signaturen, Karriereseiten oder alten Leaks bekannt. Eine Identitätsangabe ist kein Geheimnis – sie ist ein Name. Und drittens zeigt der KI-Anteil an dieser Forschung, wohin die Reise geht: Wenn das Finden von Lücken billiger wird, wird jede Woche ungepatchte Laufzeit teurer. Was das für den Umgang mit KI-gestützter Offensivforschung heißt, habe ich hier ausführlicher eingeordnet.

Drei Schritte für heute

• Build-Stand prüfen, nicht vermuten. In der SharePoint Management Shell liefert (Get-SPFarm).BuildVersion die tatsächliche Farm-Version. Liegt sie unter den Juli-Builds, ist der Server für den Auth-Bypass verwundbar. Liegt sie unter den August-Builds (16.0.19725.20522 / 16.0.10417.20198 / 16.0.5565.1001), fehlt zusätzlich der Fix für CVE-2026-63520.
• Erreichbarkeit reduzieren. Die CISA empfiehlt, SharePoint-Server nicht direkt aus dem Internet erreichbar zu machen. Ist es unvermeidbar, gehört ein Layer-7-Reverse-Proxy davor, der Authentifizierung erzwingt und Requests filtern kann.
• Rückwärts schauen. War der Server seit dem 11. August ungepatcht und erreichbar, reicht Patchen allein nicht. Prüfe IIS- und ULS-Logs auf auffällige Token-Authentifizierungen, kontrolliere neu hinzugekommene Site-Collection-Administratoren und ungewöhnliche Massendownloads.

Und ganz grundsätzlich: SharePoint ist in vielen Häusern die Brücke zwischen Dateiablage, Active Directory und Cloud. Eine Authentifizierungs-Umgehung dort ist kein Anwendungsproblem, sondern ein Identitätsproblem.

Quellen

• Rapid7: CVE-2026-55040 – Microsoft SharePoint JWT Token Authentication Bypass (FIXED)
• Rapid7: CVE-2026-63520 – Microsoft SharePoint Remote Code Execution (FIXED)
• Microsoft Security Update Guide: CVE-2026-55040
• CISA: Adds Four Known Exploited Vulnerabilities to Catalog (18.08.2026)
• Help Net Security: Attackers exploit critical SharePoint flaw after PoC goes public
• NHS England Digital: Cyber Alert CC-4829