SharePoint-Administratoren stehen vor einer eng umrissenen, aber wichtigen Aufgabe: Sie müssen feststellen, ob On-Premises-Systeme mit SharePoint Server noch für CVE-2026-65660 anfällig sind, und anschließend entscheiden, ob diese Systeme nur als ungepatcht oder auch als potenziell kompromittiert behandelt werden müssen. Diese Unterscheidung ist entscheidend, denn die Schwachstelle ist nicht mehr bloß ein Eintrag im monatlichen Update-Zyklus. Kanadische Behörden berichten von aktiver Ausnutzung, und die Sicherheitsberichterstattung ordnet den Fall in die aktuelle Diskussion um bekannte, bereits ausgenutzte Schwachstellen ein.

Unternehmensserverraum mit Sicherheitsmonitoren, die Patch-Status und Warnungen der Incident Response zeigen

Betroffen ist SharePoint Server, nicht SharePoint Online in Microsoft 365. Diese Abgrenzung verhindert zwei typische Fehler. Ein Microsoft-365-Mandant darf nicht annehmen, dass jeder Dienst mit dem Namen SharePoint von demselben serverseitigen Problem betroffen ist. Umgekehrt sollte ein Unternehmen mit einer öffentlich erreichbaren oder intern zugänglichen SharePoint-Farm nicht davon ausgehen, dass eine andere Cloud-Migration das Problem aus seiner Umgebung entfernt. Der erste Schritt ist ein belastbarer Überblick über die Assets. Der zweite ist die Entscheidung, ob das Patchen zusätzlich eine Untersuchung auf Kompromittierung erfordert.

Was bestätigt ist

Das Canadian Centre for Cyber Security beschreibt CVE-2026-65660 als fehlerhafte Kontrolle der Codegenerierung und ordnet die Schwachstelle CWE-94 zu. Nach Angaben des Zentrums betrifft der Fehler mehrere Versionen von Microsoft SharePoint Server und kann einem authentifizierten Angreifer die Ausführung beliebigen Codes auf einem verwundbaren Server ermöglichen. In der Warnung vom 24. September heißt es außerdem, dass das Zentrum von aktiver Ausnutzung Kenntnis hat. Verlinkt ist dort eine Microsoft-Sicherheitsinformation vom 11. August 2026.

Für die Verteidigung ist diese Formulierung nützlicher als eine einzelne Schlagzeilenbewertung des Schweregrads. Laut der kanadischen Warnung ist ein authentifizierter Angreifer erforderlich. Authentifiziert bedeutet jedoch nicht vertrauenswürdiger Administrator. In einer Unternehmensumgebung kann ein Angreifer ein normales Benutzerkonto, eine Dienstidentität, ein veraltetes Kennwort oder einen Zugang missbrauchen, der zwar den Zugriff auf ein Kollaborationssystem erlaubt, aber niemals die Ausführung serverseitigen Codes ermöglichen sollte. Das Risiko hängt deshalb von Identitätskontrollen, Erreichbarkeit, Berechtigungsgrenzen und dem Zustand der Farm ab, nicht allein davon, ob anonymer Datenverkehr zugelassen wird.

Microsofts Material zu den Sicherheitsupdates vom September 2026 führt SharePoint unter den Produkten auf, die Sicherheitskorrekturen erhalten, und verweist Administratoren auf die SharePoint-Update-Dokumentation. In den SharePoint-Release-Notes bezeichnet Microsoft das Update vom 8. September für SharePoint Server Subscription Edition als KB5002908 mit der Version 16.0.20326.20136. Microsoft weist außerdem darauf hin, dass SharePoint-Updates kumulativ sind: Das jeweils aktuelle anwendbare Update enthält die zuvor für diese Produktlinie veröffentlichten Korrekturen.

Die operative Schlussfolgerung ist klar: Edition und Build jedes Servers feststellen, das aktuelle unterstützte kumulative Update oder die vom Hersteller empfohlene Korrektur für diese Edition installieren und den resultierenden Build verifizieren. Ein allgemeiner Status wie Windows ist gepatcht ist kein Beleg dafür, dass SharePoint selbst behoben wurde. SharePoint folgt einem eigenen Wartungsweg. Außerdem können Farms mehrere Serverrollen oder mehrere Versionen enthalten, sodass eine Prüfung in nur einer Konsole ein falsches Sicherheitsbild erzeugen kann.

Warum daraus ein Incident-Response-Fall wird

Ein gewöhnlicher Patch-Auftrag fragt, ob das Update installiert wurde. Bei einer aktiv ausgenutzten Schwachstelle kommt eine zweite Frage hinzu: Wurde der verwundbare Dienst genutzt, bevor das Update verfügbar war? Eine erfolgreiche Installation schließt den bekannten Softwarefehler. Sie entfernt aber keine Webshell, geplante Aufgabe, gestohlenen Zugangsdaten, veränderte Konfiguration oder andere Persistenz, die ein Angreifer zuvor eingerichtet haben könnte.

Bei SharePoint ist diese Unterscheidung besonders wichtig, weil das Produkt nahe an wertvollen Geschäftsdaten und Identitätssystemen arbeitet. Ein Server kann Projektdokumente, Suchindizes, Workflow-Daten, Anwendungsintegrationen sowie Verbindungen zu Datenbanken oder Dateispeichern bereitstellen. In vielen Organisationen besitzt er außerdem eine weitreichende Netzwerkanbindung, weil Kollaborationssoftware als zentraler interner Dienst betrieben wird. Wer auf dem Server Code ausführen kann, muss nicht sofort jedes Dokument kopieren. Der Server kann zunächst als Ausgangspunkt für Aufklärung, das Sammeln von Zugangsdaten, laterale Bewegungen oder einen langsamen Zugriff auf Daten dienen.

Microsofts frühere Berichterstattung über die aktive Ausnutzung von On-Premises-SharePoint-Schwachstellen liefert relevanten Kontext, beweist aber nicht, dass bei CVE-2026-65660 dieselben Akteure oder Techniken verwendet werden. In dem Fall aus dem Jahr 2025 beschrieb Microsoft einen Ablauf von der Ausnutzung internetseitig erreichbarer SharePoint-Systeme über die Einrichtung von Webshells und die Aufklärung bis zum Zugriff auf Zugangsdaten, zur lateralen Bewegung und zu Ransomware-Aktivitäten. Diese Vorgeschichte ist ein Grund, die Umgebung nach der Behebung zu untersuchen. Sie ist kein Beleg dafür, dass die Kampagne von 2026 exakt derselben Kette folgt.

Verteidiger sollten bestätigte Fakten strikt von plausiblen Annahmen trennen. Bestätigt ist: Das Canadian Cyber Centre berichtet über die aktive Ausnutzung von CVE-2026-65660; die Schwachstelle betrifft mehrere SharePoint-Server-Versionen; als Auswirkung wird die Ausführung beliebigen Codes durch einen authentifizierten Angreifer genannt; und Microsoft hat Sicherheitsupdates für SharePoint veröffentlicht. Nicht durch diese Quellen bestätigt sind die Identität der Angreifer, ein universell verwendetes Post-Exploitation-Payload, die Zahl kompromittierter Organisationen oder die Behauptung, jeder exponierte Server sei bereits erfolgreich angegriffen worden.

Welche Umgebungen sofort geprüft werden müssen

Beginnen Sie mit sämtlichen selbst betriebenen SharePoint-Server-Instanzen, auch mit Systemen, die das Anwendungsteam nicht als Produktion einstuft. Entwicklungs-, Test-, Notfallwiederherstellungs-, Reporting- und partnerseitig erreichbare Farms enthalten häufig echte Zugangsdaten, kopierte Daten oder Netzwerkpfade, die sie zu attraktiven Zwischenstationen machen. Ein Inventar, das nur die primäre Farm aufführt, reicht nicht aus.

Berücksichtigen Sie Server hinter Reverse-Proxys, Load-Balancern, VPN-Gateways und privaten Access-Brokern. Eine Instanz wird nicht dadurch irrelevant, dass sie von keiner öffentlichen Suchmaschine erfasst wird. Ein Angreifer kann über ein kompromittiertes Unternehmenskonto, ein anderes bereits verletztes internes System, eine Partnerverbindung oder einen Managementpfad eintreffen. Umgekehrt beweist ein Listener mit Internetverbindung nicht, dass genau diese CVE ausnutzbar ist. Produkt, Version, Konfiguration und Herstellervorgaben müssen geprüft werden.

Trennen Sie SharePoint Server und SharePoint Online während der Triage. In den Microsoft-Hinweisen zu früheren On-Premises-SharePoint-Schwachstellen wurde diese Produktgrenze ausdrücklich genannt. Sie bleibt eine wichtige administrative Prüfung. Für die genaue Anwendbarkeit von CVE-2026-65660 müssen Teams jedoch die aktuelle Warnung von 2026 und die Wartungshinweise von Microsoft heranziehen. Eine Organisation, die ausschließlich einen Mandanten nutzt, muss möglicherweise Aktivitäten an Identitäten oder Anwendungen untersuchen. Sie sollte aber keinen Plan für einen selbst betriebenen Server auf einen Dienst anwenden, den sie gar nicht betreibt.

Die wichtigsten Inventarfelder sind überschaubar: Farmname, Servernamen, Produktedition, Buildnummer, Internet- und interne Erreichbarkeit, Authentifizierungsweg, verantwortliches Team, Backup-Status, letztes erfolgreiches Update sowie die Systeme, mit denen die Farm kommunizieren kann. Ergänzen Sie die von SharePoint-Diensten und Integrationen verwendeten Identitätskonten. So wird aus einer allgemeinen Sicherheitswarnung eine begrenzte Menge konkreter Entscheidungen.

Ein praktikabler Plan für den ersten Tag

1. Umfang feststellen

Fordern Sie von Infrastruktur- und Anwendungsteams die verbindliche Liste aller SharePoint-Server-Farms an. Gleichen Sie sie mit Endpoint-Management, Schwachstellenscans, DNS, Zertifikaten, Reverse-Proxy-Konfiguration, Virtualisierungsdaten sowie Cloud- und Colocation-Inventaren ab. Suchen Sie nach alten Farmnamen und scheinbar stillgelegten Hosts, die im Netz noch antworten. Kann ein Asset nicht eingeordnet werden, behandeln Sie es als ungeklärt und nicht automatisch als sicher.

Erfassen Sie den Build auf jedem relevanten Server. Microsofts SharePoint-Dokumentation bezeichnet die Updates als kumulativ, doch das konkrete Paket und der unterstützte Wartungsweg hängen von der Produktedition ab. Dokumentieren Sie für jede Farm das installierte Update, den resultierenden Build, den Installationszeitpunkt, den Status von Neustart oder Dienstneustart und eine Gesundheitsprüfung nach dem Update. Diese Angaben benötigt später auch ein Incident-Response-Team, falls der Server isoliert oder wiederhergestellt werden muss.

2. Herstellerkorrektur installieren

Verwenden Sie die aktuelle Sicherheitsinformation von Microsoft und die SharePoint-Update-Seite, um das passende Update auszuwählen. Für SharePoint Server Subscription Edition führt Microsoft KB5002908 als Update vom 8. September 2026 mit dem Build 16.0.20326.20136 auf. Dieser Eintrag ist ein wichtiger Bezugspunkt. Vor der Bereitstellung müssen Administratoren jedoch die Produktedition, möglicherweise nachfolgende Updates und die aktuelle Microsoft-Anleitung prüfen.

Testen Sie das Update nach dem üblichen Farm-Verfahren, sofern dies möglich ist, ohne die gefährliche Exposition zu verlängern. Ein reguläres Änderungsfenster darf nicht zum Grund werden, einen internetseitig erreichbaren verwundbaren Server noch tagelang offen zu lassen. Kann das System nicht sofort gepatcht werden, verringern Sie die Erreichbarkeit mithilfe der Herstellermitigierung und von Netzwerkregeln, beschränken Sie den Zugriff auf vertrauenswürdige Administrationspfade und benennen Sie einen konkreten Verantwortlichen mit Frist. Kompensierende Kontrollen verringern die Gelegenheit zur Ausnutzung; sie lassen eine bereits ausgenutzte Schwachstelle nicht verschwinden.

3. Beweise sichern, bevor unnötige Änderungen erfolgen

Gibt es Anzeichen für eine mögliche Ausnutzung, stimmen Sie sich mit dem Incident-Response- oder Sicherheitsteam ab, bevor Dateien gelöscht, Server neu aufgebaut, Logs rotiert oder Backups eingespielt werden. Sichern Sie relevante Telemetrie aus Betriebssystem, IIS, SharePoint, Authentifizierung, Proxy, Endpoint-Schutz und Netzwerk entsprechend den Aufbewahrungs- und rechtlichen Vorgaben der Organisation. Erfassen Sie den aktuellen Zustand des Servers und die Nachweise zum Update.

Das bedeutet nicht, dass eine dringende Eindämmung verzögert werden soll. Es bedeutet, Maßnahmen zu wählen, die einen nachvollziehbaren Weg zur Aufklärung offenhalten. Zeigt eine Farm aktuell verdächtiges Verhalten, isolieren Sie sie nach dem Incident-Plan und dokumentieren Sie die Entscheidungen. Eine übereilte Bereinigung, die den einzigen Hinweis auf den initialen Zugriff zerstört, kann später verhindern, dass die Organisation erkennt, ob der Angreifer weitere Systeme erreicht hat.

4. Nach Anzeichen unbefugter Nutzung suchen

Prüfen Sie Authentifizierungsereignisse auf ungewöhnliche Konten, Quellorte, unmögliche Reisebewegungen, neue Aktivitäten von Dienstkonten, unerwartete Rechteerweiterungen und Zugriffe zu Zeiten, die nicht zum Betriebsprofil der Farm passen. Korrelieren Sie diese Ereignisse mit SharePoint- und IIS-Aktivitäten, Endpoint-Erkennungen, Reverse-Proxy-Logs und Netzwerkverbindungen. Ein einzelner ungewöhnlicher User-Agent oder Request reicht nicht aus, um eine Kompromittierung festzustellen. Ein Muster aus Identitäts-, Web-, Prozess- und Netzwerkdaten ist deutlich aussagekräftiger.

Suchen Sie nach unerwarteten Dateien, Änderungen an Webanwendungsinhalten, unbekannten Assemblies, neuen geplanten Aufgaben und Diensten, geänderten Startobjekten oder Konfigurationen sowie Prozessen, die nicht zur Rolle des Servers passen. Prüfen Sie ausgehende Verbindungen der Farm, besonders zu Zielen, die nicht Teil dokumentierter Integrationen sind. Untersuchen Sie privilegierte Konten und Dienstzugänge, die während des Expositionszeitraums auf dem Server vorhanden waren.

Veröffentlichen Sie keine Exploit-Details und übernehmen Sie keine unbestätigten Indikatoren ungeprüft in produktive Erkennungsregeln. Nutzen Sie Indikatoren von Microsoft, CISA, nationalen Cyberbehörden, Ihrem Sicherheitsanbieter oder einem vertrauenswürdigen Incident-Response-Partner und gleichen Sie sie mit der lokalen Umgebung ab. Eine zu breite Regel kann einen Kollaborationsdienst stören; eine zu enge Regel kann falsches Vertrauen erzeugen.

5. Zugangsdaten abhängig von der Exposition rotieren

Ergibt die Untersuchung, dass der Server kompromittiert worden sein könnte, müssen alle Zugangsdaten überprüft werden, die dem Prozess oder Host zur Verfügung standen. Priorität haben SharePoint-Dienstidentitäten, Datenbankkonten, Anwendungsintegrationen, Administratorkonten, Zertifikate, Geheimnisse in Konfigurationen sowie Zugangsdaten, die über denselben Server oder seinen Netzwerkpfad erreichbar waren. Stimmen Sie die Rotation so ab, dass die Farm betreibbar bleibt und neue Geheimnisse nicht sofort einem weiterhin kompromittierten Host zugänglich sind.

Die Rotation von Zugangsdaten allein beweist keine Eindämmung. Wenn eine Webshell oder andere Persistenz bestehen bleibt, kann der Angreifer das Ersatzkennwort abfangen. Die Behebung muss deshalb einen sauberen, unterstützten Softwarezustand mit der Untersuchung von Endpoint und Server, validierten Backups und einer Entscheidung zwischen Neuaufbau und Wiederherstellung im Bestand verbinden.

Wie sich eine erfolgreiche Behebung verifizieren lässt

Ein belastbarer Verifikationsnachweis beantwortet vier getrennte Fragen. Erstens: Läuft jeder relevante Server auf einem unterstützten und behobenen Build? Zweitens: Ist der verwundbare Dienst noch über einen nicht autorisierten Netzwerkpfad erreichbar? Drittens: Gibt es Hinweise auf eine Ausnutzung vor dem Update? Viertens: Wurden während dieses Zeitraums Identitäten, Geheimnisse oder nachgelagerte Systeme offengelegt?

Die erste Antwort ergibt sich aus Build- und Update-Nachweisen. Die zweite erfordert die Prüfung von Netzwerk und Zugriffskontrollen, nicht nur einen Scan gegen die öffentliche Schnittstelle. Die dritte verlangt Logs und eine Untersuchung des Hosts. Für die vierte müssen Identitäts-, Datenbank-, Dateifreigabe-, API- und Endpoint-Daten korreliert werden. Wer die erste Antwort so behandelt, als würde sie alle vier Fragen erledigen, begeht den häufigsten Fehler bei der Reaktion auf dringende Schwachstellen.

Führen Sie nach dem Update eine kontrollierte Gesundheitsprüfung der Farm durch: Authentifizierung, Suche, Serviceanwendungen, Workflows, Integrationen, geplante Jobs, Datenbankverbindungen und Dokumentzugriff. Vergleichen Sie das Verhalten mit einer bekannten guten Ausgangsbasis. Überwachen Sie neue Fehler, unerwartete Prozessaktivität, ausgehenden Datenverkehr und wiederholte Authentifizierungsfehler. Halten Sie die verstärkte Überwachung so lange aufrecht, wie es zur Protokollabdeckung der Organisation und zur möglichen Expositionsdauer des Systems passt.

Findet die Untersuchung keine Hinweise auf eine Kompromittierung, dokumentieren Sie, warum diese Schlussfolgerung belastbar ist und welche Telemetrie zur Verfügung stand. Keine Beweise gefunden ist nicht dasselbe wie Beweise für keine Kompromittierung. Waren Logs nicht vorhanden oder war ihre Aufbewahrung zu kurz, muss diese Einschränkung festgehalten werden. Schließen Sie die Lücke vor der nächsten Schwachstelle mit hoher Auswirkung.

Was der Vorfall über die SharePoint-Architektur zeigt

Die unmittelbare Maßnahme ist ein Microsoft-Update. Die längerfristige Lehre ist architektonischer Natur: Ein Kollaborationsserver sollte nicht allein deshalb übermäßig viel Vertrauen erhalten, weil er im Dokumentenbetrieb zentral ist. Erfassen Sie Identitäten, Datenbanken, Speichersysteme, APIs, Verwaltungsnetze und Backup-Ziele, die SharePoint erreichen kann. Entfernen Sie nicht benötigte Routen und Berechtigungen. Trennen Sie administrative Zugriffe von normalen Benutzerzugriffen. Statten Sie Dienstkonten mit den praktisch geringsten erforderlichen Rechten aus und verwenden Sie für Administratoren eine starke Authentifizierung.

Prüfen Sie, wie schnell die Organisation grundlegende Fragen beantworten kann: Wo befinden sich alle Farms? Welcher Build ist installiert? Wer ist für jede Farm verantwortlich? Welche Konten können sie administrieren? Wie lange werden relevante Logs aufbewahrt? Kann eine betroffene Farm isoliert werden, ohne sämtliche Kollaborations-Workflows abzuschalten? Wenn die Antworten eine Woche voller Besprechungen erfordern, ist die technische Exposition nur ein Teil des Risikos. Der Reaktionsprozess selbst ist eine Abhängigkeit.

Die von Microsoft beschriebene SharePoint-Ausnutzungskampagne von 2025 zeigt ebenfalls, warum Webserver-Patching, Endpoint-Schutz, Identitätsüberwachung und Netzwerksegmentierung zusammenwirken müssen. Kein einzelnes Kontrollsystem sollte jede Phase erkennen müssen. Ein Patch schließt den ursprünglichen Codefehler. Anwendungs- und Proxy-Logs helfen bei der Rekonstruktion von Requests. Endpoint-Telemetrie macht verdächtige Prozesse und Persistenz sichtbar. Identitätslogs zeigen gestohlene oder missbrauchte Konten. Netzwerkkontrollen begrenzen den Wirkungsbereich. Backups bieten eine Wiederherstellungsoption, aber nur, wenn sie vor denselben Zugangsdaten und Pfaden geschützt sind wie die Produktion.

Fragen, die die Leitung heute stellen sollte

Sicherheits- und Infrastrukturverantwortliche brauchen keinen dramatischen Lagebericht, sondern präzise Antworten. Betreibt die Organisation SharePoint Server, SharePoint Online oder beides? Wie viele On-Premises-Farms existieren, einschließlich Nichtproduktions- und Notfallwiederherstellungssystemen? Welche Farms waren während des Zeitraums der aktuellen Warnung exponiert? Welches Update und welcher Build schützen jede Farm? Wurde die aktive Ausnutzung von einer nationalen Cyberbehörde gemeldet? Welche Beweise wurden auf eine Kompromittierung geprüft? Welche Zugangsdaten und nachgelagerten Systeme wären betroffen, wenn die Farm kontrolliert worden wäre?

Die Antworten müssen an Belege und Verantwortliche gebunden sein. Der Scanner meldet grün genügt nicht, wenn er eine Offline-Farm übersehen hat. Das Update wurde erfolgreich installiert genügt nicht, wenn der Server zuvor verdächtige Aktivitäten zeigte. Wir nutzen Microsoft 365 genügt nicht, wenn ein alter SharePoint Server für einen historischen Workflow weiterhin in einem Rechenzentrum läuft.

CVE-2026-65660 erfordert Eile, weil die öffentliche Faktenlage die Schwelle von theoretischer Gefährdung zu bestätigtem Bewusstsein für aktive Ausnutzung überschritten hat. Die richtige Reaktion ist diszipliniert, nicht theatralisch: den tatsächlichen Serverbestand feststellen, die passende Microsoft-Korrektur einspielen, den Expositionszeitraum untersuchen, Zugangsdaten bei begründetem Anlass schützen oder rotieren und genügend Beweise erhalten, um eine behobene Schwachstelle von einer bereinigten Umgebung zu unterscheiden. Diese Reihenfolge senkt sowohl das technische Risiko als auch die Gefahr, dass ein hastiger Patchbericht einen größeren Vorfall verdeckt.

Quellen und Grundlage der Berichterstattung

Dieser Artikel basiert auf Microsofts Dokumentation zur SharePoint-Wartung und den Sicherheitsupdate-Informationen vom September 2026, der Warnung des Canadian Centre for Cyber Security zu CVE-2026-65660, dem CISA-Programm für bekannte ausgenutzte Schwachstellen sowie Microsofts früherer eigener Berichterstattung über die aktive Ausnutzung von On-Premises-SharePoint-Schwachstellen. Der Microsoft-Bericht von 2025 dient als Kontext für die Reaktionsplanung. Er wird nicht als Beleg dafür dargestellt, dass die Aktivitäten von 2026 denselben Akteur, dasselbe Payload oder dieselbe Angriffskette aufweisen.