CISAs Aufnahme von CVE-2026-45659 in den Known Exploited Vulnerabilities Catalog ist kein Grund zur Panik für jeden Microsoft-365-Kunden. Sie ist ein klares Signal für Organisationen, die noch selbst verwaltete, lokale SharePoint-Server betreiben.

Lokaler Collaboration-Server hinter einer Firewall mit Dokumenten, Identitäten und Patch-Checkliste

Microsoft hat das Problem in den Mai-Updates 2026 behoben. CISA nahm es am 1. Juli wegen aktiver Ausnutzung in KEV auf und setzte für betroffene US-Bundesbehörden den 4. Juli als Frist. Für alle anderen bleibt die Frage: Wissen Sie, wo lokale SharePoint-Farmen stehen, ob sie korrigierte Builds haben, ob sie exponiert waren und ob vor dem Patch etwas passiert ist?

Es ist keine unauthentifizierte Pre-Auth-Wurmgeschichte. Microsoft verlangt Authentifizierung und niedrige Rechte. Das senkt die Lautstärke, nicht die Priorität. Low-Privilege-Konten werden gephisht, von Infostealern gestohlen, Dienstleistern überlassen oder in alten Gruppen vergessen. Eine authentifizierte RCE in SharePoint kann ein Identitätsproblem zu einem Serverproblem machen.

Was passiert ist

CVE-2026-45659 ist eine Remote-Code-Execution in Microsoft SharePoint Server durch Deserialisierung nicht vertrauenswürdiger Daten, CWE-502. Microsoft bewertet sie mit CVSS 8.8: Netzwerk, niedrige Komplexität, niedrige Privilegien, keine Nutzerinteraktion und hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Betroffen sind SharePoint Server Subscription Edition, SharePoint Server 2019 und SharePoint Enterprise Server 2016 / SharePoint Server 2016. Die korrigierten Builds sind 16.0.19725.20280 mit KB5002863, 16.0.10417.20128 mit KB5002870 und 16.0.5552.1002 mit KB5002868.

SharePoint Online steht nicht in der betroffenen Produktliste für Kundenpatching. Das Risiko liegt im Hybrid- und Legacy-Bereich: alte Farmen für Workflows, Archive, Fachseiten, regulierte Lasten, Custom Web Parts oder nie abgeschlossene Migrationen.

Im Mai gefixt, im Juli dringend

MSRC schreibt, dass die Schwachstelle durch Mai-Updates behoben wurde, aber versehentlich in der Liste May 2026 Security Updates fehlte. Die Revision vom 26. Mai war informativ für Kunden, die bereits aktualisiert hatten.

Ein Team mit installierten Mai-Updates kann fertig sein. Ein anderes sah den Eintrag später, mit geringerer erwarteter Ausnutzung, und verschob ihn ins normale Wartungsfenster. KEV ändert diese Priorität, weil es reale Ausnutzung signalisiert.

Das ist nicht automatisch ein Fehler des Herstellers. Vulnerability Intelligence ändert sich. Einschätzungen sind Momentaufnahmen. Angreifer testen, Verteidiger beobachten.

Authentifiziert heißt nicht harmlos

Microsoft sagt: Ein authentifizierter Angreifer kann die Schwachstelle auslösen; Adminrechte sind nicht nötig; Site-Member-Rechte können reichen. In alten Collaboration-Umgebungen ist das kein hoher Balken.

SharePoint-Berechtigungen wachsen: Projekte, Partner, Abteilungen, vererbte Gruppen, Testkonten, Dienstleister. Ein gestohlenes Konto liest vielleicht nur wenige Dokumente; mit verwundbarer Farm kann es Codeausführung, Web Shell oder Lateral Movement ermöglichen.

Die richtige Reaktion ist Scope: betroffene Editionen, Builds, Internet-/VPN-/Partnerzugang, breite Site-Member-Gruppen, jüngste Identitätsvorfälle und SharePoint-Anomalien.

Warum SharePoint wertvoll ist

SharePoint wirkt wie ein altes Intranet, enthält aber Dokumente, Freigaben, Workflows, Apps, Archive und Geschäftsprozesse. Es hängt oft nahe an Active Directory, SQL Server, Service Accounts, Office-Integrationen, Custom Code und Backups.

Lokale Farmen sind wegen Anpassungen schwer zu patchen. Das erklärt Verzögerung, macht aktive Ausnutzung aber nicht weniger ernst. BleepingComputer zitierte Shadowserver-Daten mit mehr als 10.000 internetexponierten SharePoint-Servern. Das ist keine Zahl verwundbarer Systeme, sondern ein Expositionssignal.

KEV macht aus Patching incident-aware Patching

Ein normales Ticket fragt: Update installiert? Eine ausgenutzte Schwachstelle fragt zusätzlich: War der Server vorher erreichbar? Gab es Versuche? Braucht es forensische Prüfung?

CISAs KEV-Text verweist auf Exposure Evaluation und Forensics Triage. Patchen ist notwendig, aber bei vorher exponierten Servern möglicherweise nicht ausreichend. Eine interne, schnell gepatchte Farm braucht Nachweis. Eine exponierte, ungepatchte Farm braucht Patch oder Isolation plus Logprüfung. Verdächtige Aktivität braucht Incident Response.

Praktische Prüfungen

Inventarisieren Sie alle SharePoint-Farmen: Migration, Test, DR, Partnerportale, Abteilungsserver, Reverse Proxies. Vergleichen Sie Edition und Build mit MSRC.

Reduzieren Sie Exposition, wenn sofortiges Patchen nicht geht: öffentliche Zugänge begrenzen, vertrauenswürdige Netzpfade nutzen, unnötige Eingänge schließen, Proxy-/WAF-Regeln prüfen. Nicht benötigte Dienste abschalten.

Prüfen Sie IIS- und SharePoint-Logs: ungewöhnliche authentifizierte Requests, Uploads oder Script-Aktivität, neue Konten, Site-Collection-Änderungen, auffällige Worker-Prozesse, PowerShell, Scheduled Tasks, ausgehende Verbindungen. Prüfen Sie Identität: verdächtige Konten, breite Gruppen, alte Dienstleister, interaktive Service Accounts.

Was nicht hilft

SharePoint Online ist nicht wie eine lokale Farm für diesen CVE zu patchen. “Authentifiziert” ist kein Grund zum Warten bei exponierten Farmen. Führen Sie keine zufälligen PoCs aus und nutzen Sie schwache GitHub-Repos nicht als Kampagnenbeweis. CISA bestätigt Ausnutzung; das reicht zur Priorisierung. Ransomware-Zuordnung nicht übertreiben: CISA markiert sie als unbekannt.

Fünf Fragen

Gibt es ein vollständiges Inventar? Sind alle betroffenen Systeme auf korrigierten Builds oder Mai-Updates? Waren sie internetexponiert oder breit erreichbar? Wurden Logs und Kontoänderungen geprüft? Ist klar, welche Low-Privilege-Konten sich authentifizieren können?

CVE-2026-45659 ist ernst, weil sie Legacy Collaboration, Identität und langsames Patchen verbindet. Sie bedeutet nicht, dass jede SharePoint-Umgebung verloren ist. Sie bedeutet, dass alte lokale Collaboration-Server nicht unsichtbar sein dürfen.

Priorisieren ohne Hysterie

Priorität entsteht nicht nur aus CVSS. Eine interne, bereits aktualisierte SharePoint-Farm hinter kontrollierten Netzen ist etwas anderes als ein internetexponierter Server mit externen Nutzern und über Jahre gewachsenen Berechtigungen. KEV ändert aber die Diskussion: Bei bestätigter Ausnutzung muss der tatsächliche Zustand überprüft werden.

Die praktische Reihenfolge lautet Exposition, Version, Identität, Signale. Exposition: Wer erreicht den Server? Version: Ist der Build korrigiert? Identität: Welche Low-Privilege-Konten können sich anmelden? Signale: Zeigen Logs auffällige Aktivität vor dem Patch? Diese Reihenfolge verhindert Panik und Selbstberuhigung.

Für MSPs und kleine Teams ist Inventar oft die Schwachstelle. Ein Kunde kann glauben, vollständig in die Cloud migriert zu sein, während eine alte Farm für Archive, Workflows oder Abteilungen weiterläuft. Dann ist nicht SharePoint Online die Frage, sondern der vergessene Server, der noch Logins akzeptiert.

Die größere Lehre

CVE-2026-45659 zeigt, dass Vulnerability Management 2026 nicht mehr nur nach Score sortiert wird. Entscheidungen kombinieren Exploit-Belege, Exposition, geschäftliche Bedeutung, Identitätsrealität und die Fähigkeit, zu patchen ohne kritische Prozesse zu brechen. SharePoint bündelt diese Faktoren: alt, nützlich, identitätsnah und oft angepasst.

Ein sauberer Abschluss lautet nicht nur “KB installiert”. Er umfasst aktualisiertes Inventar, verifizierte Builds, reduzierte Exposition, geprüfte Logs, behandelte verdächtige Konten und bereinigte Berechtigungen. Diese Dokumentation hilft beim nächsten Fall, in dem sich das Risiko Wochen nach dem Patch ändert.

Die ruhige Schlussfolgerung: Wer keinen lokalen SharePoint Server betreibt, sollte daraus keine unnötige Angst machen. Wer ihn betreibt, sollte ihn nicht als langweiliges Portal behandeln, sondern als kritische Infrastruktur nahe an Dokumenten und Identität.