CVE-2026-55040: SharePoint JWT Auth Bypass jetzt in CISA KEV

Diese Woche in unserer InSEKurity of the Week-Serie: ein Authentication Bypass in Microsoft SharePoint Server, der keine Zugangsdaten, keine Benutzerinteraktion und kein geschicktes Timing benötigt — lediglich eine einzige HTTP-Anfrage mit einem Token, das der Server niemals hätte akzeptieren dürfen. CVE-2026-55040 ist nicht ein Bug. Es sind vier voneinander unabhängige Fehler in derselben JWT-Validierungspipeline, so präzise aufeinander gestapelt, dass jeder den nächsten deckt: die Signaturprüfung ist abgeschaltet, der Signaturschlüssel wird aus einem angreiferkontrollierten Header aufgelöst, ein nicht registrierter Issuer wird mit einer entschuldigenden Logzeile akzeptiert, und die abschließende Signaturprüfung verifiziert nur, dass das Signaturfeld nicht leer ist. Verkettet man sie, lässt sich ein Token für jeden Benutzer der Farm ausstellen — einschließlich eines Site-Collection-Administrators.

Microsoft hat die Lücke am 14. Juli 2026 unauffällig gepatcht — mit CVSS 9.1 bewertet und in der nüchternen Sprache des Security Update Guide beschrieben als “bypass a security feature over a network”. Vier Wochen blieb es still. Dann veröffentlichte Rapid7, die die Schwachstelle gefunden hatten, am 11. August eine vollständige technische Analyse samt funktionierendem Proof-of-Concept. Am Tag darauf trafen Ausnutzungsversuche auf Honeypots. Am 18. August nahm CISA die Schwachstelle mit einer dreitägigen Remediationsfrist in den Katalog der Known Exploited Vulnerabilities auf. Das ist die Chronologie, die diesen Eintrag lesenswert macht: der Patch war 35 Tage verfügbar, bevor es irgendwo Eile gab — und was das Risiko verändert hat, war kein neuer Bug, sondern ein Blogartikel.

Es gibt eine zweite Hälfte dieser Geschichte, und sie ist der Teil, den die meisten Berichte übersprungen haben. CVE-2026-55040 war nie als vollständiger Exploit gedacht. Sie ist die vordere Hälfte einer Pwn2Own-Berlin-2026-Kette, und ihr Partner — CVE-2026-63520, eine unsichere .NET-Typinstanziierung in den Business Connectivity Services — wurde einen Monat später gepatcht, am 11. August 2026. Zusammen ergeben sie unauthentifizierte Remote Code Execution auf einer SharePoint-Farm. Wer im Juli gepatcht hat und dann aufgehört hat, hat die Tür geschlossen und das Fenster offen gelassen.

🚨 Zusammenfassung

CVE-ID: CVE-2026-55040
CVSS-3.1-Score: 9.1 Kritisch (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-1390: Weak Authentication
Betroffene Software: SharePoint Server Subscription Edition, SharePoint Server 2019, SharePoint Enterprise Server 2016. SharePoint Online (Microsoft 365) ist nicht betroffen.
Angriffsvektor: Netzwerk — eine einzige HTTP-Anfrage mit gefälschtem Authorization: Bearer-Header
Authentifizierung erforderlich: Keine
Auswirkung: Vollständige Impersonation jedes SharePoint-Site-Benutzers oder Site-Collection-Administrators; Lese- und Schreibzugriff auf Site-Inhalte; ein fertiges Frontend für eine authentifizierte RCE
Patch-Status: Verfügbar seit 2026-07-14 (Juli-Patchday)
Veröffentlicht: NVD-Eintrag veröffentlicht 2026-07-14, letzte Änderung 2026-08-19
Ausnutzungsstatus: Aktiv ausgenutzt. Honeypot-Treffer ab 2026-08-12, einen Tag nach dem öffentlichen PoC
CISA KEV: Gelistet — aufgenommen 2026-08-18, Remediationsfrist 2026-08-21, Ransomware-Nutzung erfasst als Unknown
Gemeldet von: Stephen Fewer, Rapid7 — an Microsoft gemeldet am 2026-05-18 als Teil eines Pwn2Own-Berlin-2026-Beitrags
Kettenpartner: CVE-2026-63520 (CVSS 8.1, RCE) — separat gepatcht am 2026-08-11

🖥️ Was ist Microsoft SharePoint Server?

Microsoft SharePoint Server ist die On-Premises-Variante von SharePoint: eine Plattform für Dokumentenmanagement, Zusammenarbeit und Intranets, die auf Windows Server und IIS läuft und von SQL Server gestützt wird. Dort liegen die Dokumente, die zu sensibel, zu stark reguliert oder zu tief in interne Systeme integriert sind, um in die Cloud zu wandern — genau deshalb existiert das On-Premises-Produkt 2026 überhaupt noch, während SharePoint Online alles andere übernimmt.

Dieser Selektionseffekt ist für diese CVE entscheidend. Eine SharePoint-Farm ist selten ein Ziel von geringem Wert. Typischerweise enthält sie Verträge, Personalakten, Vorstandsunterlagen, technische Dokumentation und das interne Wiki, das erklärt, wie alles andere konfiguriert ist. Sie ist außerdem tief integriert: SharePoint hält Dienstkonto-Zugangsdaten, spricht mit Active Directory, indexiert Dateifreigaben über den Suchcrawler und läuft häufig unter einem Dienstkonto, dessen Berechtigungen vor Jahren von jemandem vergeben wurden, der das Unternehmen längst verlassen hat. Die Kompromittierung einer SharePoint-Farm ist selten das Ende eines Einbruchs — sie ist ein sehr guter Anfang.

Für etwas so Wertvolles ist SharePoint außerdem ungewöhnlich exponiert. Weil SharePoint der Weg ist, über den Remote-Mitarbeiter und externe Partner interne Dokumente erreichen, werden Farmen routinemäßig ins Internet publiziert. Shadowserver verfolgt knapp 10.000 aus dem Internet erreichbare Microsoft-SharePoint-Server. Und SharePoint ist zu einem der zuverlässigsten Angriffsziele des Jahrzehnts geworden: CVE-2026-55040 ist allein im Jahr 2026 die fünfte SharePoint-Schwachstelle, deren Ausnutzung bekannt ist — neben CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-56164 und CVE-2026-58644. Angreifer haben gelernt, dass die On-Premises-Installationsbasis groß, wertvoll, langsam beim Patchen und oft aus dem Internet erreichbar ist.

Typische Einsatzszenarien

Unternehmensintranets und Teamsites — die Standard-Startseite für zehntausende Mitarbeiter
Dokumentenmanagement und Aufbewahrung — versionierte, berechtigungsgesteuerte Ablage für Verträge, Richtlinien und regulierte Unterlagen
Enterprise Search — ein Crawler, der SharePoint-Inhalte und angebundene Dateifreigaben indexiert, wodurch der Suchindex zur Landkarte der Unternehmensdaten wird
Business Connectivity Services (BCS) — externe Systeme (SQL, SAP, Line-of-Business-APIs) werden als SharePoint-Listen dargestellt. Genau hier liegt der Kettenpartner CVE-2026-63520.
Extranets und Partnerportale — der Grund, warum so viele Farmen überhaupt ins Internet publiziert werden
Workflow- und Formularplattformen — langlebige Geschäftsprozesse, die eine Stilllegung der Farm extrem erschweren

🔍 Technische Analyse

Beschreibung der Schwachstelle

SharePoint Server unterstützt Server-to-Server-Authentifizierung (S2S), ein auf OAuth 2.0 basierendes Protokoll, mit dem vertrauenswürdige Server — eine andere SharePoint-Farm, Exchange Server, Workflow Manager — Ressourcen im Namen eines Benutzers anfordern können. Der Mechanismus ist ein verschachteltes JWT: ein äußeres Token belegt, welcher Server anfragt, und ein eingebettetes Actor Token trägt die behauptete Benutzeridentität. Das Vertrauen ist in einem Zertifikat verankert: Man registriert den Security Token Service (STS) eines Peer-Servers mit New-SPTrustedSecurityTokenIssuer und verweist dabei auf dessen JSON-Metadaten-Endpunkt; danach akzeptiert SharePoint Tokens, die von diesem STS signiert wurden.

Die Sicherheit des gesamten Designs beruht auf einer einzigen Bedingung: die Signaturen müssen tatsächlich geprüft werden. CVE-2026-55040 ist die Erkenntnis, dass sie im Codepfad von SPJsonWebSecurityTokenHandlerV2 nicht geprüft werden — und zwar auf vier verschiedene Weisen. Ein unauthentifizierter Angreifer kann ein verschachteltes Token konstruieren, das eine beliebige Identität behauptet, nichts signieren und SharePoint dazu bringen, es als gültige S2S-Anfrage zu akzeptieren. SharePoint verarbeitet die Anfrage dann als dieser Benutzer.

Microsofts eigene Beschreibung — “Weak authentication in Microsoft Office SharePoint allows an unauthorized attacker to bypass a security feature over a network” — ist technisch korrekt und untertreibt radikal, was danach passiert. Der CVSS-Vektor erzählt die ehrlichere Geschichte: AV:N/AC:L/PR:N/UI:N — Netzwerk, niedrige Komplexität, keine Privilegien, keine Benutzerinteraktion — bei hoher Auswirkung auf Vertraulichkeit und Integrität.

Ursachenanalyse

Rapid7s Analyse identifiziert vier eigenständige Schwächen, alle in derselben Validierungspipeline. Einzeln wäre jede von ihnen vielleicht überlebbar. Zusammen entfernen sie jede kryptografische Prüfung der Kette.

Die Signaturprüfung ist explizit deaktiviert. SPJsonWebSecurityTokenHandlerV2.ValidateToken() setzt RequireSignedTokens = false. Das ist die folgenreichste einzelne Zeile: sie bedeutet, dass der Handler ein Token akzeptiert, dessen Header "alg": "none" deklariert. Die Signatur des äußeren Tokens wird nie geprüft, weil aus Sicht des Handlers gar keine vorhanden sein soll.
Der Signaturschlüssel wird aus einem angreiferkontrollierten Header aufgelöst. GetSigningKeyIdentifier() liest das Feld x5t — einen X.509-Zertifikats-Thumbprint — direkt aus dem Header des Actor Tokens und übergibt es an SPIssuerTokenResolver.TryResolveToken(), das es brav zu einem Signaturschlüssel auflöst. An keiner Stelle dieser Sequenz wird die Signatur des Actor Tokens gegen diesen Schlüssel validiert. Der Angreifer bestimmt, welchen Schlüssel SharePoint nachschlägt — und das Nachschlagen wird mit dem Verifizieren verwechselt.

Diese Schwäche ist nur deshalb trivial ausnutzbar, weil eine andere Designentscheidung mitspielt: SharePoint veröffentlicht sein eigenes STS-Signaturzertifikat an einem unauthentifizierten Endpunkt. GET /_layouts/15/metadata/json/1 — der dokumentierte JSON-Metadaten-Endpunkt zum Aufbau von S2S-Vertrauen — gibt das Zertifikat samt Thumbprint an jeden heraus, der fragt. Der Angreifer muss den x5t-Wert nicht erraten oder stehlen. Der Server liefert ihn aus.
Ein nicht registrierter Issuer wird trotzdem akzeptiert. Die in diesem Pfad verwendete Überladung von ValidateIssuer() ruft GetProviderBySigningCertificate() auf, um den registrierten STS zum Zertifikat zu finden. Wenn dieser Lookup null zurückgibt — also wenn kein vertrauenswürdiger Issuer passt —, verwirft die Methode das Token nicht. Sie akzeptiert es und protokolliert die Entscheidung im ULS-Log:

ValidateTokenIssuer accepted Issuer because no registered STS matches

Das ist ein Fail-Open genau bei der Bedingung, zu deren Erkennung die Funktion existiert. Es ist zugleich, wie wir weiter unten nutzen werden, eine ausgezeichnete Detection-Signatur.
Die abschließende “Signaturprüfung” ist nicht kryptografisch. GetTokenSignature() prüft, dass die Signaturkomponente ein nicht-leerer String ist. Nicht, dass sie gültig ist. Nicht, dass sie wohlgeformtes Base64 ist. Nur, dass irgendetwas da ist. Eine Signatur von AAAA genügt.

Der strukturelle Fehler unter allen vier Punkten: der Codepfad behandelt äußeres und inneres Token unterschiedlich und vertraut jedem auf Basis des anderen. Das äußere Token ist von der Signaturprüfung befreit, weil das verschachtelte Actor Token den kryptografischen Beweis tragen soll; das Actor Token wird nie verifiziert, weil das Auflösen seines Schlüssels mit dem Validieren verwechselt wird. Keines wird geprüft, und die Befreiung des einen wird jeweils mit dem anderen begründet.

Angriffsvektor

Der vollständige Ablauf benötigt zwei HTTP-Anfragen — eine, um den Zertifikats-Thumbprint zu holen, eine, um ihn zu verwenden.

Angreifer                                 SharePoint Server
   |                                             |
   |  (1) GET /_layouts/15/metadata/json/1       |
   |      keine Authentifizierung erforderlich   |
   +-------------------------------------------->|
   |<--------------------------------------------+
   |      STS-Signaturzertifikat, inkl. x5t-Thumbprint
   |                                             |
   |  (2) Verschachteltes Token bauen:           |
   |      Outer-Header  { "alg": "none" }             <-- Schwaeche 1
   |      Actor-Header  { "alg": "RS256",
   |                      "x5t": "<Thumbprint>" }     <-- Schwaeche 2
   |      Actor-Claims  Identitaet = SID oder UPN des Zielbenutzers
   |      Signatur      "AAAA"                        <-- Schwaeche 4
   |                                             |
   |  (3) GET /_api/web/currentuser               |
   |      Authorization: Bearer <gefaelschtes Token>
   +-------------------------------------------->|
   |                                             |
   |    RequireSignedTokens = false   -> aeussere Signatur nicht geprueft
   |    GetSigningKeyIdentifier()     -> loest x5t des Angreifers auf
   |    ValidateIssuer()              -> kein registrierter STS, akzeptiert  <-- Schwaeche 3
   |    GetTokenSignature()           -> String nicht leer, akzeptiert
   |                                             |
   |<--------------------------------------------+
   |      200 OK -- Anfrage verarbeitet als der impersonierte Benutzer

Schritt 1 — den Thumbprint abholen. Ein unauthentifiziertes GET gegen den Metadaten-Endpunkt liefert das STS-Signaturzertifikat der Farm. Das ist dokumentiertes, beabsichtigtes Verhalten zum Aufbau von S2S-Vertrauen; es wird nur wegen Schwäche 2 zum Problem. Sie können prüfen, ob Ihre eigene Farm es offenlegt — das ist ein einfacher Lesezugriff auf einen öffentlichen Endpunkt auf einem Server, der Ihnen gehört:

# Pruefen, ob der S2S-Metadaten-Endpunkt erreichbar ist, und was er zurueckgibt.
# -s still, -k selbstsigniertes/internes CA-Zertifikat tolerieren,
# -o Body verwerfen, -w nur den HTTP-Statuscode ausgeben.
curl -sk -o /dev/null -w 'HTTP %{http_code}\n' \
  https://sharepoint.example.com/_layouts/15/metadata/json/1

# Um das JSON selbst zu betrachten (das ist das Zertifikat, das ein Angreifer liest):
curl -sk https://sharepoint.example.com/_layouts/15/metadata/json/1

Ein 200 ist hier normal und erwartet — es ist für sich genommen kein Nachweis einer Schwachstelle oder einer Kompromittierung. Der Punkt ist: auf einer ungepatchten Farm ist diese Antwort die erste Hälfte eines Exploits, und sie kostet den Angreifer nichts.

Schritt 2 — das Token fälschen. Die folgende Tokenstruktur ist illustrativ — sie zeigt die Form der von Rapid7 dokumentierten Claims, keinen funktionierenden Exploit:

// NUR ILLUSTRATIV -- Struktur des gefaelschten verschachtelten Tokens, dekodiert.
// Dies ist KEIN funktionierender Exploit und authentifiziert sich so nicht.
{
  "outer_header":  { "alg": "none", "typ": "JWT" },
  "outer_payload": {
    "actortoken": "<base64url Actor Token, siehe unten>"
  },
  "outer_signature": "",

  "actor_header":  { "alg": "RS256", "x5t": "<Thumbprint aus Schritt 1>" },
  "actor_payload": {
    "nameid": "<SID oder UPN des zu impersonierenden Benutzers>",
    "aud":    "<Realm-GUID der Zielfarm>"
  },
  "actor_signature": "AAAA"
}

Schritt 3 — wissen, wen man impersoniert. Das ist die einzige echte Voraussetzung, und sie ist der Grund, warum AC:L fast wohlwollend erscheint. Impersonation erfordert die Nennung einer realen Identität: eine Windows-SID oder eine UPN. Rapid7 weist darauf hin, dass ein Angreifer diese über Active-Directory-SID-Enumeration oder UPN-Discovery beschafft — und der öffentliche PoC automatisiert das, indem er RIDs (standardmäßig bis 10000) gegen den Domänencontroller des Ziels durchläuft, um Konten zu finden und Site-Administratoren zu lokalisieren. Die dokumentierten Flags des PoC machen den Ablauf explizit:

# ILLUSTRATIV -- die im oeffentlichen PoC-Repository von Rapid7 dokumentierten Flags
# (github.com/sfewer-r7/CVE-2026-55040). Wiedergegeben, um zu zeigen, was der
# Angreifer automatisiert. Nur gegen Systeme einsetzen, fuer die eine
# ausdrueckliche Testfreigabe vorliegt.

--target      Ziel-IP; ermittelt die restlichen Parameter automatisch
--host        SharePoint-Hostname (fuer Host-Header / Realm-Aufloesung)
--x5t         Thumbprint des STS-Signaturzertifikats (vom Metadaten-Endpunkt)
--realm       SharePoint-Realm-GUID
--sid         Windows-SID, die als Identitaet behauptet wird
--upn         User Principal Name, z. B. administrator@domain.local
--auto-upn    UPN aus dem HTTPS-Zertifikat des Servers ableiten
--username    Benutzername fuer die abgeleitete UPN (Standard: administrator)
--rid         eine bestimmte RID (ueberspringt die Enumeration)
--max-rid     hoechste zu durchlaufende RID (Standard: 10000)
--domain-ip   IP des Domaenencontrollers, fuer SMB-basierte Discovery
--port/--http abweichender Port / unverschluesseltes HTTP

Beachten Sie die Bedeutung von --auto-upn und --max-rid: der Angreifer braucht kein Vorwissen über Ihre Umgebung. Er leitet die Domäne aus dem TLS-Zertifikat ab und probiert dann RIDs durch, bis er einen Administrator findet. Die Voraussetzung “der Angreifer muss die Zielidentität kennen” ist eine Bremsschwelle, keine Schutzmaßnahme.

Schritt 4 — als dieser Benutzer handeln. Das gefälschte Token wird als ganz normales Bearer-Credential an eine beliebige authentifizierte Oberfläche gesendet. Rapid7s Analyse und PoC nutzen /_api/web/currentuser (Bestätigung, welche Identität der Server annimmt), /_api/contextinfo (Abruf des Form Digest, der für schreibende Operationen nötig ist) und /_vti_bin/sites.asmx. Von dort hat der Angreifer genau den SharePoint-Zugriff, den der impersonierte Benutzer hat.

Die vollständige Kette: Bypass plus RCE

CVE-2026-55040 war nie das Endziel. Sie ist die Hälfte einer Zwei-Bug-Kette, die Rapid7 Labs als Pwn2Own-Berlin-2026-Beitrag gebaut hat — und der Grund, warum der Authentication Bypass viel mehr bedeutet als “einen Benutzer impersonieren”:

  CVE-2026-55040                        CVE-2026-63520
  Weak Authentication (CWE-1390)        Improper Input Validation (CWE-20)
  CVSS 9.1                              CVSS 8.1
  gepatcht 2026-07-14                   gepatcht 2026-08-11
        |                                       |
        v                                       v
  +--------------------+                +----------------------+
  | JWT faelschen,     | authentifi-    | unsichere .NET-Typ-  |
  | als jeder Benutzer | zierte Session | instanziierung in    |
  | handeln (ohne      | -------------> | Business Connectivity|
  | Zugangsdaten)      |                | Services             |
  +--------------------+                +----------------------+
                                                 |
                                                 v
                                     beliebige Codeausfuehrung als
                                     das SharePoint-Dienstkonto

CVE-2026-63520 (CVSS 8.1, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C, CWE-20) ist eine unsichere .NET-Typinstanziierung, erreichbar über die Business Connectivity Services. Für sich allein ist das ein authentifizierter Bug von begrenztem Interesse. Hinter CVE-2026-55040 geschaltet ergibt das Paar unauthentifizierte RCE gegen jede unterstützte SharePoint-Version, ausgeführt als SharePoint-Dienstkonto.

Das operativ wichtige Detail: die beiden Hälften wurden im Abstand eines Monats gepatcht. Der Bypass ging am 14. Juli raus, die RCE am 11. August. Eine Farm, die im Juli gepatcht wurde und seitdem nicht mehr, fehlt die zweite Hälfte.

Microsofts August-Update hat das betroffene Feature auch direkt gehärtet. Laut KB5002893 deaktiviert das August-2026-Update den dateibasierten Import von Business-Data-Connectivity-(BDC)-Modellen standardmäßig; ein neues Cmdlet Enable-BdcmFileImport steht bereit, um es pro Site Collection wieder einzuschalten. Behandeln Sie dieses Cmdlet als Entscheidung, nicht als Komfortfunktion — siehe den Abschnitt zu Mitigationen.

Ausnutzung in der Praxis

Die Ausnutzungskurve wird hier vollständig von der Veröffentlichung von Informationen getrieben, nicht vom Patch:

2026-07-14 — Patch erscheint. Microsofts Advisory-Sprache ist bewusst vage; keine technischen Details öffentlich.
2026-07-19 — KEVIntel erfasst den ersten Ausnutzungsversuch. Ein einzelner Probe-Versuch, vier Wochen vor der Analyse. Jemand hat mit dem Patch-Diff gearbeitet.
2026-07-14 bis 2026-08-11 — Nahezu Stille. Insgesamt 12 Versuche werden über diesen gesamten Zeitraum erfasst.
2026-08-11 — Rapid7 veröffentlicht die technische Analyse und einen funktionierenden PoC.
2026-08-12 — Defused meldet Angriffe auf seine Honeypots, ausdrücklich unter Verwendung von Rapid7s PoC. 8 der insgesamt 12 erfassten Versuche fallen auf den 12./13. August — zwei Drittel der Monatsaktivität in 48 Stunden.
Quell-IPs: 8 eindeutige Adressen aus Hongkong, Japan, den Niederlanden, Taiwan und den USA.
2026-08-18 — CISA nimmt CVE-2026-55040 in den KEV-Katalog auf, Remediationsfrist 2026-08-21.
Attribution: keine. SecurityWeek formulierte es so: “there does not appear to be any public information on who is behind the exploitation of these weaknesses.” Die Ransomware-Nutzung ist in KEV als Unknown erfasst.

Die absoluten Zahlen sind klein, und man könnte sie leicht als beruhigend lesen. Sind sie nicht. Sie sind früh. Das Muster — ein stiller Monat, dann ein Sprung innerhalb von 24 Stunden nach einem öffentlichen PoC — ist genau das Muster, das kommerziellem Massenscanning vorausgeht, und es ist dasselbe Muster, dem SharePoint dieses Jahr bereits viermal gefolgt ist.

Auswirkungen nach erfolgreicher Ausnutzung

Vollständiger Lesezugriff auf Site-Inhalte als der impersonierte Benutzer. Ist dieser Benutzer ein Site-Collection-Administrator, sind das alle Dokumente der Site Collection.
Schreibzugriff. Der PoC holt bewusst den Form Digest von /_api/contextinfo — das Token, das SharePoint für zustandsändernde Operationen verlangt. Das ist kein reiner Lese-Bug.
Eskalation zur Codeausführung. Verkettet mit CVE-2026-63520 läuft beliebiger Code als SharePoint-Dienstkonto.
Abgreifen von Zugangsdaten und Geheimnissen. Eine SharePoint-Farm hält Dienstkonto-Zugangsdaten, Connection Strings und Secrets in der Konfigurationsdatenbank und in BCS-Verbindungen. Codeausführung als Dienstkonto erreicht sie.
Active-Directory-Reconnaissance aus einer vertrauenswürdigen Position. Der Exploit-Pfad beinhaltet bereits Abfragen gegen den Domänencontroller; ein Fußabdruck auf der Farm macht diese Enumeration authentifiziert und unauffällig.
Zugriff auf indexierte Inhalte jenseits von SharePoint. Der Suchcrawler indexiert angebundene Dateifreigaben. Der Index ist eine Landkarte, wo die sensiblen Daten der Organisation liegen.
Persistenz. SharePoint bietet reichlich dauerhafte Fußabdrücke — Webparts, Event Receiver, Timer Jobs, Custom Solutions, geänderte web.config-Dateien. Keiner davon wird durch das Einspielen eines Patches entfernt.
Eine vertrauenswürdige Position für internes Phishing. Dokumente und Links, die vom Unternehmensintranet ausgeliefert werden, tragen ein implizites Vertrauen, das keine externe Domain erreichen kann.

⚠️ Bewertung der Auswirkungen

Unmittelbare Auswirkungen

Unauthentifizierte Impersonation jedes Benutzers, einschließlich Administratoren, über das Netzwerk, ohne Benutzerinteraktion.
Kein Workaround für die Schwachstelle selbst. Die Behebung ist der Patch. Netzwerkbeschränkung und ein Layer-7-Reverse-Proxy reduzieren, wer den Endpunkt erreicht; sie reparieren die Validierungspipeline nicht.
Ein öffentlicher, automatisierter PoC existiert — und er ermittelt die benötigten Parameter selbst, einschließlich Administratorkonten.
Es sind zwei Patches nötig, nicht einer. Der Juli schließt den Bypass, der August die RCE. Farmen, die nur im Juli gepatcht wurden, bleiben für die zweite Hälfte der Kette angreifbar.
Die KEV-Frist ist bereits verstrichen. CISAs Remediationsdatum war 2026-08-21. Wenn das noch offen ist, liegen Sie hinter einer behördlichen Frist, die eine reale Risikoeinschätzung widerspiegelt.
Patchen vertreibt keinen Angreifer. War Ihre Farm irgendwann seit dem 14. Juli erreichbar und ungepatcht — und besonders seit dem 11. August —, ist Patchen Schritt eins von zwei. Schritt zwei ist Threat Hunting.

Betroffene Versionen

Produkt	Anfällige Versionen	Behobener Build	Juli-2026-KB (CVE-2026-55040)
SharePoint Server Subscription Edition	< 16.0.19725.20434	16.0.19725.20434	KB5002882
SharePoint Server 2019	< 16.0.10417.20175	16.0.10417.20175	KB5002883 (+ MUI KB5002885)
SharePoint Enterprise Server 2016	< 16.0.5561.1001	16.0.5561.1001	KB5002891 (+ MUI KB5002892)
SharePoint Online (Microsoft 365)	Nicht betroffen	—	—

Und die zweite Hälfte der Kette — CVE-2026-63520, einen Monat später veröffentlicht:

Produkt	Behobener Build	August-2026-KB (CVE-2026-63520)
SharePoint Server Subscription Edition	16.0.19725.20522	KB5002893
SharePoint Server 2019	16.0.10417.20198	KB5002894 (+ MUI KB5002896)
SharePoint Enterprise Server 2016	16.0.5565.1001	KB5002905 (+ MUI KB5002906)

Das Lifecycle-Problem. Laut Microsofts eigenen Lifecycle-Seiten haben SharePoint Server 2016 und SharePoint Server 2019 beide am 2026-07-15, 06:59:59 PT das Ende des Extended Support erreicht — das heißt, das Update vom 14. Juli, das CVE-2026-55040 behoben hat, war der letzte Patchday innerhalb ihres Supportfensters. Microsoft hat dennoch am 11. August ein Update für beide ausgeliefert (KB5002905/KB5002906 für 2016, KB5002894/KB5002896 für 2019, laut Microsofts eigener SharePoint-Release-Notes-Seite), und dieses Update enthält den Fix für CVE-2026-63520. Spielen Sie es ein. Bauen Sie aber keinen Plan darauf, dass sich das wiederholt: es gibt kein angekündigtes Extended-Security-Update-Programm für SharePoint Server 2016 oder 2019, und der Migrationspfad, auf den Microsoft verweist, ist die SharePoint Server Subscription Edition. Für die nächste Kettenhälfte kommt möglicherweise kein Patch für Sie.

Betroffene Umgebungen

Ins Internet publizierte Farmen — Extranets, Partnerportale, Remote-Access-Intranets. Knapp 10.000 SharePoint-Server sind laut Shadowserver aus dem Internet erreichbar. Das ist der akute Fall.
Nur intern erreichbare Farmen in flachen Netzen. AV:N heißt “Netzwerk”, nicht “Internet”. Wenn irgendein Arbeitsplatzrechner die Farm über HTTPS erreicht, dann erreicht sie auch alles, was auf einem Arbeitsplatzrechner landet.
Farmen mit Server-to-Server-Authentifizierung — hybrides SharePoint, Exchange-Integration, Workflow Manager. Das sind die Deployments, in denen der S2S-Codepfad ein aktiv genutztes Feature ist und nicht schlafender Code.
Farmen mit genutzten Business Connectivity Services — direkt relevant für den Kettenpartner und verbreitet in genau jenen integrationslastigen Umgebungen, die nicht leicht zu SharePoint Online wechseln können.
Alle, die noch SharePoint 2016 oder 2019 betreiben — betroffen, seit dem 15. Juli 2026 außerhalb des Extended Support und für künftige Fixes auf Microsofts Kulanz angewiesen.
Farmen mit quartalsweiser Patch-Kadenz. Der Abstand zwischen “PoC veröffentlicht” und “Honeypots angegriffen” war ein Tag. Eine Quartals-Kadenz ist dagegen keine Verteidigung, sondern eine Methode, es später zu erfahren.

Angreiferprofile

Opportunistische Massenscanner. Die Voraussetzung für Massen-Ausnutzung — ein öffentlicher PoC, der seine Parameter selbst ermittelt — ist bereits erfüllt. Das ist die Population, die die Telemetrie mit 8 IPs repräsentiert, und sie ist diejenige, die wächst.
Ransomware-Betreiber. Unternehmens-Dokumentenarchive sind ideale Ransomware-Ziele: hohe Geschäftsauswirkung, hohe regulatorische Exposition und eine glaubwürdige Erpressungsgeschichte. KEV erfasst die Ransomware-Nutzung heute als Unknown. SharePoints eigene 2026er-Bilanz — CVE-2026-45659 ist im gleichen KEV-Katalog als bekannt ransomware-assoziiert markiert — deutet darauf hin, wie sich dieses Feld typischerweise entwickelt.
Staatlich unterstützte Akteure. Ein Intranet ist ein kuratiertes Archiv des sensibelsten Materials einer Organisation, und ein Authentication Bypass erzeugt Zugriff, der genau wie ein legitimer Benutzer aussieht. Für langfristige Spionage ist das nahezu ideal.
Initial Access Broker. Administrativer Zugriff auf eine Unternehmens-SharePoint-Farm ist erstklassige, weiterverkäufliche Ware.
Insider und Dienstleister. Keine Zugangsdaten heißt kein Audit-Trail, der an ein echtes Konto gebunden ist. Wer Netzwerkzugriff hat, kann als jeder anderen handeln.

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1) ⚡

Ermitteln Sie den exakten Farm-Build. Führen Sie dies in der SharePoint Management Shell auf einem Farmserver aus (oder laden Sie das Snap-In zuvor in die Windows PowerShell). Get-SPFarm liefert die lokale Farm; BuildVersion ist eine schreibgeschützte System.Version in der Form major.minor.phase.build.

# SharePoint-Snap-In laden, falls Sie nicht in der SharePoint Management Shell sind.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

# Aktuelle Build-Nummer der Farm.
Get-SPFarm | Select-Object -ExpandProperty BuildVersion

Vergleichen Sie das Ergebnis mit den Tabellen oben. Sie brauchen beide Schwellenwerte:

Produkt	Gepatcht für CVE-2026-55040 (Juli)	Gepatcht für CVE-2026-63520 (August)
Subscription Edition	>= 16.0.19725.20434	>= 16.0.19725.20522
SharePoint 2019	>= 16.0.10417.20175	>= 16.0.10417.20198
SharePoint 2016	>= 16.0.5561.1001	>= 16.0.5565.1001

Ein Build, der die Juli-Schwelle erreicht, aber nicht die August-Schwelle, bedeutet: der Bypass ist behoben und die RCE-Hälfte nicht.

Prüfen Sie jeden Server der Farm, nicht nur einen. Eine Farm auf Build N kann trotzdem einen Server enthalten, bei dem das Upgrade nicht abgeschlossen wurde. Get-SPProduct listet die installierten SharePoint-Produkte und die Versionen aller eingespielten Updates; -Local beschränkt die Ausgabe auf den aktuellen Server.
```
# Produkte und eingespielte Update-Versionen auf diesem Server.
Get-SPProduct -Local

# Farmweite Sicht (ohne -Local): listet alle Server und deren Patch-Status.
Get-SPProduct
```
Verwenden Sie dafür nicht Get-HotFix. Get-HotFix fragt Win32_QuickFixEngineering ab, was Betriebssystem-Updates auflistet. SharePoint-Public-Updates sind Office-Familien-Patches und erscheinen dort nicht zuverlässig. Eine Farm kann massiv veraltet sein, während Get-HotFix vollkommen gesund aussieht. Nutzen Sie Get-SPProduct und die Farm-Build-Version, oder die Zentraladministrationsseite Upgrade und Migration > Produkt- und Patchinstallationsstatus überprüfen.
Spielen Sie beide Updates ein, falls noch nicht erfolgt. Das Juli-KB schließt CVE-2026-55040, das August-KB schließt CVE-2026-63520. Bei SharePoint 2016 und 2019 ist das August-Update trotz des Supportendes am 15. Juli verfügbar — nehmen Sie es jetzt, statt anzunehmen, es sei später noch da. Folgen Sie Microsofts üblicher Reihenfolge: erst das sprachunabhängige Paket, dann das MUI-/Sprachpaket, danach den SharePoint-Produktkonfigurations-Assistenten (bzw. PSConfig) auf jedem Server ausführen, um das Upgrade abzuschließen. Eine installierte Binärdatei mit unvollständigem Konfigurations-Upgrade ist keine gepatchte Farm.
Reduzieren Sie, wer die Farm erreichen kann. Es gibt keine Konfigurationsänderung, die die Validierungspipeline reparieren würde — beschränken Sie also die Erreichbarkeit. CISAs Empfehlung für SharePoint Server ist eindeutig: SharePoint-Server nicht direkt ins Internet stellen, sofern nicht notwendig, und wo es notwendig ist, den Server hinter einen Layer-7-Reverse-Proxy oder eine gleichwertige Kontrolle auf Anwendungsebene stellen, die Authentifizierung verlangt und Anfragen inspizieren und filtern kann. Intern gilt dieselbe Logik — eine Farm, die aus jedem Arbeitsplatz-VLAN erreichbar ist, ist von jedem kompromittierten Arbeitsplatz erreichbar.
Aktivieren Sie den dateibasierten BDC-Modell-Import nicht ohne Grund erneut. Das August-Update deaktiviert ihn standardmäßig, genau um die Angriffsfläche von CVE-2026-63520 zu verkleinern. Das Cmdlet Enable-BdcmFileImport existiert, um ihn für eine Site Collection wieder einzuschalten, wo das Geschäft ihn wirklich braucht. Vergewissern Sie sich, dass niemand es reflexartig ausgeführt hat, um einen fehlgeschlagenen Import zu “reparieren”.
Gehen Sie bei exponierten Farmen von einer Kompromittierung aus. War eine aus dem Internet erreichbare Farm am oder nach dem 12. August 2026 ungepatcht — dem Tag, an dem die PoC-getriebene Ausnutzung begann —, ist eine Compromise Assessment verpflichtend, nicht optional. Weiter mit dem Detection-Abschnitt.

Detection-Maßnahmen 🔍

Die gute Nachricht: Schwäche 3 protokolliert sich selbst. SharePoint schreibt jedes Mal einen ULS-Eintrag, wenn es einen Issuer akzeptiert, dem es nicht vertraut. Diese Meldung ist der zuverlässigste verfügbare Indikator für diese CVE, denn eine gesunde Farm hat keinen legitimen Grund, sie zu erzeugen.

Suchen Sie die Fail-Open-Meldung im ULS. Get-SPLogEvent liest die ULS-Trace-Logs; -StartTime und -EndTime begrenzen die Suche und sind aus Performancegründen ausdrücklich empfohlen.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

# ULS-Trace-Log nach der Fail-Open-Entscheidung aus Schwaeche 3 durchsuchen.
# Ein Treffer bedeutet: SharePoint hat ein Token von einem Issuer akzeptiert,
# dem es nicht vertraut.
Get-SPLogEvent -StartTime (Get-Date).AddDays(-30) |
    Where-Object { $_.Message -like '*accepted Issuer because no registered STS matches*' } |
    Select-Object Timestamp, Area, Category, Message |
    Format-List

Zwei Vorbehalte, bevor Sie ein leeres Ergebnis als gute Nachricht werten. Erstens ist die ULS-Aufbewahrung endlich — prüfen Sie, was Sie tatsächlich behalten, denn 30 Tage Historie existieren möglicherweise nicht:

# ULS-Einstellungen der Farm. LogLocation ist das Trace-Log-Verzeichnis,
# DaysToKeepLogs gibt an, wie lange Eintraege erhalten bleiben.
Get-SPDiagnosticConfig

Zweitens hängt es vom konfigurierten Trace-Level der betreffenden Kategorie ab, ob diese Meldung überhaupt geschrieben wird. Ist ULS heruntergedreht, ist das Fehlen der Meldung kein Beleg für das Fehlen des Angriffs.

Durchsuchen Sie die ULS-Dateien direkt — schneller als Get-SPLogEvent über eine große Historie und nützlich bei archivierten Logs. Setzen Sie den LogLocation-Wert aus dem Befehl oben ein:

# Standard-ULS-Pfad fuer den 16er-Hive; an Ihr LogLocation anpassen.
$uls = 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS'

Select-String -Path (Join-Path $uls '*.log') `
    -Pattern 'accepted Issuer because no registered STS matches' |
    Select-Object Filename, LineNumber, Line

Korrelieren Sie das Zwei-Anfragen-Muster in den IIS-Logs. Der Exploit liest den Metadaten-Endpunkt und ruft dann eine authentifizierte API auf. Eine einzelne Client-IP, die beides tut, ist ein starkes Signal.
```
# IIS-Standard-Log-Wurzel; W3SVC<siteid> pro Site.
$iis = 'C:\inetpub\logs\LogFiles'

Select-String -Path (Join-Path $iis 'W3SVC*\*.log') `
    -Pattern '/_layouts/15/metadata/json/1|/_api/contextinfo|/_vti_bin/sites\.asmx|/_api/web/currentuser' |
    Select-Object -ExpandProperty Line
```
Wichtige Einschränkung: IIS-Logs erfassen standardmäßig keine Request-Header, das heißt das Authorization: Bearer-Token steht nicht darin. Sie können IIS-Logs nicht nach alg: none durchsuchen. Was Sie können: das Zugriffs-Muster erkennen — Metadaten-Endpunkt gefolgt von authentifizierten API-Aufrufen derselben Quelle — und beachten, dass cs-username bei diesen Anfragen oft leer oder unerwartet ist, weil der Aufrufer nie eine normale Anmeldung durchgeführt hat.

Eine Sentinel-/Log-Analytics-Abfrage für dasselbe Muster. Diese markiert jede Client-IP, die zwei oder mehr der relevanten Endpunkte berührt hat. Die Spaltennamen entsprechen dem W3CIISLog-Schema.

W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any (
    "/_layouts/15/metadata/json/1",
    "/_api/contextinfo",
    "/_api/web/currentuser",
    "/_vti_bin/sites.asmx")
| summarize
    Endpoints  = make_set(csUriStem),
    Requests   = count(),
    Statuses   = make_set(scStatus),
    Users      = make_set(csUserName),
    FirstSeen  = min(TimeGenerated),
    LastSeen   = max(TimeGenerated)
    by cIP, Computer
| where array_length(Endpoints) >= 2
| order by LastSeen desc

Vor dem Ausrollen tunen: legitime S2S-Peers und Monitoring-Agenten treffen einige dieser Endpunkte routinemäßig. Erstellen Sie eine Baseline Ihrer bekannten Quelladressen und schließen Sie diese aus, anstatt die Endpunkte aus der Abfrage zu entfernen.

Suchen Sie nach dem, was ein Angreifer als Nächstes tut, nicht nur nach dem Einstieg. Der Bypass ist leise; die Folgeaktivität nicht. Prüfen Sie über denselben Zeitraum:
- Neue oder geänderte Farm Solutions, Webparts, Event Receiver und Timer Jobs — die klassischen SharePoint-Persistenzmechanismen.
- Änderungen an web.config auf jedem Web-Frontend.
- Neu hinzugefügte Site-Collection-Administratoren und Berechtigungsvergaben, die kein Change-Ticket erklärt.
- w3wp.exe, das Kindprozesse startet — insbesondere cmd.exe, powershell.exe, csc.exe oder net.exe. Auf einem gesunden SharePoint-Frontend liegt das nahe bei null, was es zu einer ungewöhnlich klaren Detection für die CVE-2026-63520-Hälfte der Kette macht.
- Unerwartete ausgehende Verbindungen von Web-Frontends.
- Auffällige Massenzugriffe auf Dokumente oder Suchabfragen von einer einzelnen Identität.
Prüfen Sie Ihre KEV-Lage insgesamt. Die Remediationsfrist für CVE-2026-55040 war der 2026-08-21. Ist sie verstrichen, trägt derselbe Prozess sehr wahrscheinlich auch die anderen vier ausgenutzten SharePoint-CVEs des Jahres 2026 mit sich. Fragen Sie Ihren Scanner nach dem gesamten Set ab: CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-55040, CVE-2026-56164, CVE-2026-58644, CVE-2026-63520.

Langfristige Sicherheitsverbesserungen

Holen Sie SharePoint aus dem öffentlichen Internet. Wenn externe Benutzer Dokumente brauchen, setzen Sie einen authentifizierenden Reverse-Proxy oder ein VPN vor die Farm — genau wie CISA es empfiehlt. Ein Angreifer, der keinen TLS-Handshake mit Ihrer Farm zustande bringt, kann darin auch keinen Token-Validierungsfehler ausnutzen, so elegant er auch sei.
Migrieren Sie von SharePoint 2016 und 2019 weg. Beide haben den Extended Support am 15. Juli 2026 verlassen. Es gibt kein angekündigtes ESU-Programm. Das August-2026-Update für diese Versionen war ein glücklicher Ausgang, kein Anspruch — und einen Sicherheitsplan auf Microsofts fortgesetzte Großzügigkeit zu bauen, ist kein Plan.
Patchen Sie das managementnahe Umfeld in der schnellsten Kadenz, die Sie haben. Der Abstand zwischen öffentlichem PoC und beobachteter Ausnutzung betrug bei dieser CVE einen Tag. Jeder Patch-Zyklus, der in Monaten gemessen wird, ist faktisch die Entscheidung, sich gegen diese Ereignisklasse nicht zu verteidigen.
Verfolgen Sie die Kette, nicht die CVE. Der tatsächliche Schweregrad dieser Schwachstelle zeigt sich erst, wenn man merkt, dass ihr Partner einen Monat später erschien. Machen Sie es zur Gewohnheit, bei jedem Herstelleradvisory zu fragen: ist das ein vollständiger Bug oder die Hälfte eines? Forscher-Veröffentlichungen — hier die von Rapid7 — sagen das routinemäßig ausdrücklich, das Hersteller-Advisory dagegen nicht.
Betrachten Sie ein Patch-Datum nicht länger als Entwarnung. Bei einer Schwachstelle mit öffentlichem PoC ist die interessante Frage nicht “haben wir gepatcht?”, sondern “waren wir erreichbar und ungepatcht, während sie ausgenutzt wurde?”. Das erfordert unterschiedliche Reaktionen, und nur eine davon ist ein Update.
Machen Sie aus ULS-Logging etwas, das Sie tatsächlich lesen. SharePoint hat in seinen eigenen Logs die Wahrheit gesagt — accepted Issuer because no registered STS matches ist ein Fail-Open-Geständnis. Es ist nichts wert, wenn die Logs nur lokal liegen, kurz aufbewahrt und nicht gelesen werden. Leiten Sie ULS an Ihr SIEM weiter, bewahren Sie es passend zu Ihren Detection-Ambitionen auf und alarmieren Sie auf hochwertige Strings wie diesen.
Inventarisieren Sie Ihre S2S-Vertrauensbeziehungen. Wissen Sie, welche Server per New-SPTrustedSecurityTokenIssuer registriert sind und warum. Vertrauen, das vor Jahren für eine längst abgeschaltete Integration konfiguriert wurde, ist reine Angriffsfläche — und es erschwert zusätzlich die Detection, weil es legitimes Rauschen in den Codepfad bringt.
Reduzieren Sie die Privilegien des SharePoint-Dienstkontos. Codeausführung als Dienstkonto ist der Endzustand der Kette. Wie viel das für einen Angreifer wert ist, ist eine Konfigurationsentscheidung, die Sie bereits getroffen haben — und überdenken können.
Nehmen Sie das Intranet in die Incident-Response-Planung auf. Stellen Sie die unangenehme Frage, bevor Sie die Antwort brauchen: wenn die SharePoint-Farm nicht mehr vertrauenswürdig ist, was hat der Angreifer gelesen? Die meisten Organisationen können das nicht beantworten, weil SharePoint-Zugriffs-Logging nie für forensische Zwecke ausgelegt wurde.

🎯 Warum ist das kritisch?

Vier unabhängige Fehler in einer Validierungspipeline. Das ist kein subtiler Logikfehler. Die Signaturprüfung ist komplett abgeschaltet, der Schlüssel kommt aus Angreifer-Eingaben, ein unbekannter Issuer wird akzeptiert, und die Signaturprüfung ist ein String-Längentest. Wäre eine einzige davon korrekt gewesen, hätte sie den Angriff gestoppt.
Null Voraussetzungen. Keine Zugangsdaten, keine Benutzerinteraktion, niedrige Komplexität, eine HTTP-Anfrage. Die einzige Hürde ist die Kenntnis eines Benutzernamens — und der öffentliche PoC probiert den für Sie durch.
Der Server liefert das Schlüsselmaterial selbst aus. SharePoint veröffentlicht sein STS-Signaturzertifikat an einem unauthentifizierten Endpunkt. Das ist unproblematisch, solange Signaturen geprüft werden. Es ist der erste Schritt eines Exploits, wenn sie es nicht werden.
Sie wird ausgenutzt und steht in KEV. Aufgenommen am 2026-08-18, Remediation fällig am 2026-08-21. Diese Frist ist verstrichen.
Die Ausnutzung folgte dem PoC um einen Tag. 12 erfasste Versuche in einem Monat, 8 davon in den 48 Stunden nach der Veröffentlichung. Der limitierende Faktor war nie die Schwierigkeit — es war die Information.
Im Juli zu patchen war nicht genug. Die RCE-Hälfte der Kette erschien am 11. August. Eine Farm, die das Juli-Update genommen hat und dann aufhörte, ist genau für die Schwachstelle exponiert, die den Bypass erst bedeutsam macht.
Die Zielmenge ist konstruktionsbedingt hochwertig. On-Premises-SharePoint hält 2026 das Material, das zu sensibel oder zu stark integriert war, um in die Cloud zu wandern. Knapp 10.000 dieser Server sind aus dem Internet erreichbar.
Zwei der drei betroffenen Versionen sind außerhalb des Supports. SharePoint 2016 und 2019 haben den Extended Support am 15. Juli 2026 verlassen, ohne ESU-Programm. Sie haben trotzdem einen August-Patch bekommen. Für den nächsten gibt es keine Garantie.
Das ist SharePoints fünfte ausgenutzte Schwachstelle in 2026. CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-56164, CVE-2026-58644 — und jetzt diese. Irgendwann hört ein Muster auf, eine Pechsträhne zu sein, und wird zum Anlass, neu zu bewerten, ob das Produkt an Ihren Perimeter gehört.

🚀 Zeitleiste und Disclosure

2026-05-18 — Rapid7 meldet die vollständige Exploit-Kette an Microsoft. Die Arbeit ist ein Pwn2Own-Berlin-2026-Beitrag von Stephen Fewer und kombiniert den Authentication Bypass mit einer SharePoint-RCE.
2026-07-14 — Microsoft patcht CVE-2026-55040 im Juli-Patchday: KB5002882 (Subscription Edition, 16.0.19725.20434), KB5002883/KB5002885 (2019, 16.0.10417.20175), KB5002891/KB5002892 (2016, 16.0.5561.1001). Der NVD-Eintrag wird am selben Tag veröffentlicht, mit CVSS 3.1 9.1 und CWE-1390. Die Advisory-Sprache bleibt generisch; keine technischen Details öffentlich.
2026-07-15, 06:59:59 PT — SharePoint Server 2016 und SharePoint Server 2019 erreichen das Ende des Extended Support. Das Update vom 14. Juli war das letzte innerhalb ihres Supportfensters.
2026-07-19 — Erster Ausnutzungsversuch erfasst durch KEVIntel — fünf Tage nach dem Patch, drei Wochen vor jedem öffentlichen technischen Detail.
2026-08-11 — Rapid7 veröffentlicht die technische Analyse und einen funktionierenden Proof-of-Concept (github.com/sfewer-r7/CVE-2026-55040) und dokumentiert alle vier Schwächen. Am selben Tag patcht Microsoft CVE-2026-63520, die RCE-Hälfte der Kette: KB5002893 (SE, 16.0.19725.20522), KB5002894/KB5002896 (2019, 16.0.10417.20198), KB5002905/KB5002906 (2016, 16.0.5565.1001). Das August-Update deaktiviert außerdem den dateibasierten BDC-Modell-Import standardmäßig.
2026-08-12 — Defused meldet Honeypot-Ausnutzung, ausdrücklich unter Verwendung von Rapid7s PoC. Rapid7 liefert authentifizierte Detection-Checks in InsightVM, Nexpose und Exposure Command aus.
2026-08-12 bis 08-13 — 8 der insgesamt 12 erfassten Versuche treten auf, von 8 IPs aus Hongkong, Japan, den Niederlanden, Taiwan und den USA.
2026-08-18 — CISA nimmt CVE-2026-55040 in den KEV-Katalog auf (CWE-1390), mit einer Remediationsfrist zum 2026-08-21 nach BOD 26-04. Ransomware-Nutzung: Unknown.
2026-08-19 — Der NVD-Eintrag wird letztmalig geändert.
2026-08-21 — Die KEV-Remediationsfrist verstreicht. CVE-2026-55040 ist in der KEV-Katalogversion 2026.08.21 (1.674 Einträge) bestätigt enthalten.

🔗 Ressourcen und Referenzen

CVE: CVE-2026-55040
NVD: NVD — CVE-2026-55040
Hersteller-Advisory: MSRC Security Update Guide — CVE-2026-55040
CWE: CWE-1390: Weak Authentication
CISA-KEV-Katalog: Known Exploited Vulnerabilities — gelistet seit 2026-08-18, fällig 2026-08-21
Technische Analyse: Microsoft SharePoint JWT Token Authentication Bypass Technical Analysis — Rapid7
Kettenpartner: CVE-2026-63520 — SharePoint Remote Code Execution (Rapid7)
Patch-Referenz: SharePoint updates — Microsoft Learn (Build-Nummern und KBs für jede Version)
Support-Lifecycle: SharePoint Server 2016 und SharePoint Server 2019 — Extended Support endete am 2026-07-15
Verwandte, 2026 ausgenutzte SharePoint-CVEs: CVE-2026-32201, CVE-2026-45659 (KEV, ransomware-assoziiert), CVE-2026-50522, CVE-2026-56164, CVE-2026-58644
Unsere frühere Berichterstattung: InSEKurity of the Week KW27/2026 — SharePoint Deserialization RCE (CVE-2026-45659)

💼 SEKurity Unterstützt Sie

Das Lehrreiche an CVE-2026-55040 ist nicht, dass SharePoint einen Authentifizierungsfehler hatte. Es ist, wo der Fehler saß. Niemand hat vergessen zu authentifizieren. Hier existiert eine komplette Validierungspipeline — ein Token-Handler, ein Issuer-Resolver, eine Signaturprüfung, eine dedizierte ValidateIssuer()-Methode — und jede Stufe davon lief. Jede Stufe hat lediglich darauf vertraut, dass eine andere Stufe die Kryptografie erledigt. Das äußere Token war befreit, weil das Actor Token die Echtheit belegen sollte; das Actor Token wurde nie verifiziert, weil das Auflösen seines Schlüssels mit dem Validieren verwechselt wurde. Vier korrekt aussehende Funktionen, ein vollständiges Versagen. So sehen Sicherheitsdefekte in ausgereiften Produkten aus: nicht fehlende Kontrollen, sondern Kontrollen, von denen jede annimmt, jemand anders halte die Linie.

Genau diese Fehlerklasse findet kein automatisierter Scanner und fängt keine Checkliste. Ein Scanner sieht einen Authentifizierungsmechanismus und protokolliert, dass einer existiert. Zu testen, ob er sich überreden lässt — ob ein Token, das der Server ablehnen müsste, akzeptiert wird; ob ein Endpunkt, der Zertifikatsmetadaten veröffentlicht, zum Problem wird, wenn die Signaturprüfung schwach ist; ob sich ein Fußabdruck als niedrig privilegierter Benutzer in Codeausführung auf dem Frontend verwandeln lässt — erfordert jemanden, der den Vertrauensbeziehungen von Anfang bis Ende folgt und jede Annahme einzeln zu brechen versucht. Die zweite Lehre betrifft die Ausnutzungskurve. Am 11. August hat sich an dieser Schwachstelle nichts geändert. Der Patch war seit vier Wochen verfügbar. Geändert hat sich, dass die technischen Details öffentlich wurden — und die Ausnutzung folgte innerhalb eines Tages. Jede Patch-Kadenz, die langsamer ist als das, ist eine Wette darauf, dass niemand die Bugs in Ihrem Stack aufschreibt. Wir unterstützen unsere Kunden an beiden Fronten: wir testen, ob die Authentifizierungs- und Autorisierungsgrenzen um Kollaborationsplattformen unter Druck tatsächlich halten und nicht bloß existieren; wir kartieren, welche internen Systeme von wo aus wirklich erreichbar sind; wir verwandeln theoretische Fußabdrücke in nachgewiesene Auswirkungen, damit Priorisierungsdiskussionen aufhören, hypothetisch zu sein; und wir validieren, dass die Detections, auf die Sie sich verlassen — etwa eine ULS-Zeile, in der wörtlich “accepted Issuer because no registered STS matches” steht —, bei einem Analysten ankommen und nicht in einer Logdatei, die niemand öffnet.

Unsere Leistungen

Penetration Testing: Webanwendungen, Mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Einsätze
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

🌐 Website: www.sekurity.de

📧 Anfragen: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Kollaborations- und Intranet-Infrastruktur ist unser Antrieb.

InSEKurity of the Week (KW34/2026): Microsoft SharePoint JWT Authentication Bypass (CVE-2026-55040)