SharePoint CVE-2026-45659 ist jetzt ein Ransomware-Risiko

CVE-2026-45659 ist längst kein reines SharePoint-Patch-Problem mehr, sondern ein Ransomware-Problem. Seit August 2026 führt CISA die Schwachstelle als aktiv ausgenutzt und mit bekannten Ransomware-Kampagnen assoziiert — jeder betroffene On-Premises-SharePoint-Server, der vor dem Patchen exponiert war, verdient daher sowohl eine Behebung als auch eine Kompromittierungsprüfung.

Die wichtigen Daten zählen. Microsoft veröffentlichte die Sicherheitsupdates im Mai 2026. CISA nahm die Schwachstelle am 1. Juli in ihren Known-Exploited-Vulnerabilities-Katalog auf, im August wurde dann die Ransomware-Verbindung öffentlich bekannt. Diese Abfolge bedeutet, dass Administratoren die Lücke zwischen der Verfügbarkeit des Patches und dem Moment, in dem ein Server tatsächlich abgesichert wurde, mitdenken müssen.

Mr.PlanB berichtete bereits über die ursprüngliche CISA-Ransomware-Einstufung, als sich der Status änderte. Die relevantere Frage jetzt ist, was ein Infrastruktur-Team tun sollte, wenn eine Schwachstelle sowohl gepatcht als auch bewaffnet wurde — vor allem, wenn der Server wochenlang aus dem Internet erreichbar war.

Wird CVE-2026-45659 wirklich in Ransomware-Angriffen eingesetzt?

Ja. CISAs Known-Exploited-Vulnerabilities-Programm hat das Thema durch die Bestätigung aktiver Ausnutzung über die rein theoretische Ausnutzbarkeit hinausgehoben, und die Behörde markierte sie später als mit Ransomware-Kampagnen assoziiert. Das ist ein stärkeres operatives Signal als ein reiner Schweregrad-Score, weil es Verteidigern zeigt, dass die Schwachstelle Teil realen Angreiferverhaltens ist.

CVE-2026-45659 ist eine Deserialisierungs-Schwachstelle in Microsoft SharePoint Server. Microsoft beschreibt sie so, dass ein authentifizierter Angreifer darüber Code über das Netzwerk ausführen kann. Das entscheidende Detail ist die Berechtigungsanforderung. Der Angreifer muss nicht als SharePoint-Administrator beginnen. Ein Einstiegspunkt mit niedrigeren Berechtigungen kann ausreichen, um aus Anwendungszugriff Codeausführung auf dem Server zu machen.

Das Ransomware-Label sagt nicht, dass jeder Ausnutzungsversuch in einer Verschlüsselung endet. CISA hat für diese CVE öffentlich keinen konkreten Ransomware-Akteur benannt, und die öffentliche Berichterstattung enthielt Spekulationen, die nicht als Attribution behandelt werden sollten. Die sichere Schlussfolgerung ist enger gefasst und trotzdem ernst: Ransomware-Operationen nutzen die Schwachstelle, exponierte Systeme sollten also als reale Angriffsziele behandelt werden.

Welche SharePoint-Server sollten Administratoren zuerst prüfen?

Zu den betroffenen On-Premises-Bereitstellungen gehören SharePoint Enterprise Server 2016, SharePoint Server 2019 und SharePoint Server Subscription Edition. Die erste Aufgabe besteht darin, jede Instanz zu inventarisieren — einschließlich alter Server, die noch auf einer internen Adresse antworten, Disaster-Recovery-Replikate, Testsysteme und aus dem Internet erreichbare Knoten, von denen irgendjemand annahm, sie seien nur vorübergehend.

Verlassen Sie sich nicht darauf, dass eine Windows-Update-Richtlinie existiert, als Beweis dafür, dass der SharePoint-Fix vorhanden ist. Bestätigen Sie, dass das relevante SharePoint-Sicherheitsupdate auf jedem Server erfolgreich installiert wurde. Dokumentieren Sie anschließend, wann es installiert wurde. Eine im August gepatchte Maschine hat eine andere Untersuchungshistorie als eine im Mai gepatchte, weil das Expositionsfenster unterschiedlich ist.

Das ist auch ein guter Moment, um nach vergessenen Veröffentlichungspfaden zu suchen. Reverse-Proxys, VPN-Regeln, alte NAT-Einträge, Application Delivery Controller und Cloud-Firewall-Regeln können eine Instanz noch lange erreichbar halten, nachdem das Team sie für isoliert hält. Die Schwachstelle steckt in der Anwendung, aber das praktische Risiko hängt stark davon ab, wer sie erreichen konnte und welche Zugangsdaten oder Sitzungen ein Angreifer erlangen könnte.

Warum ist eine authentifizierte SharePoint-RCE trotzdem gefährlich?

Eine authentifizierte Remote-Code-Execution-Schwachstelle ist gefährlich, weil Unternehmens-SharePoint-Umgebungen oft viele legitime Konten mit niedrigen Berechtigungen enthalten. Auftragnehmer, Projektnutzer, Dienstkonten, migrierte Identitäten und veraltete Konten können den Pool an Zugangsdaten vergrößern, die missbraucht werden könnten, bevor die Schwachstelle ausgelöst wird.

Authentifizierung kann auch der zweite Schritt sein statt der erste. Phishing, wiederverwendete Passwörter, Infostealer-Logs, Sitzungsdiebstahl und kompromittierte Endgeräte können Zugangsdaten liefern. Sobald ein Angreifer über ein gültiges Konto verfügt, kann eine serverseitige Schwachstelle diesen Identitäts-Einstiegspunkt in eine deutlich mächtigere Position verwandeln.

SharePoint ist besonders unangenehm, weil es nah an sensiblen Dokumenten, internen Workflows, Berechtigungen, Identitätssystemen und oft anderer Microsoft-Infrastruktur sitzt. Ein kompromittierter Anwendungsserver kann so zum Einstiegspunkt für Diebstahl von Zugangsdaten, Persistenz, laterale Bewegung und Data Staging werden. Ransomware ist das sichtbare Ergebnis. Das leisere Problem ist alles, was ein Angreifer tun kann, bevor die Verschlüsselung überhaupt beginnt.

Deshalb dürfen Schwachstellenmanagement und Ransomware-Recovery nicht in getrennten Räumen stattfinden. Das Security-Team mag die CVE schließen, während das Recovery-Team immer noch beantworten muss, ob sich die Umgebung aus vertrauenswürdigen Daten wiederherstellen lässt.

Reicht Patchen aus, nachdem aktive Ausnutzung begonnen hat?

Patchen ist unverzichtbar, aber Patchen löscht keine Historie. War ein verwundbarer SharePoint-Server während eines Zeitraums bekannter Ausnutzung erreichbar, verhindert das Update zwar die erneute Nutzung der bekannten Schwachstelle, beweist aber nicht, dass der Server vor dem Einspielen des Patches sauber war.

CISAs SharePoint-Anleitung vom Juli äußerte konkret Bedenken darüber, dass Angreifer IIS-Machine-Keys stehlen und Deserialisierungstechniken zur Persistenz nutzen. Das ist relevant, weil ein Incident Responder eine erfolgreiche Update-Installation nicht als Ende des Vorfalls behandeln kann. Logs, Endpoint-Telemetriedaten, Authentifizierungsereignisse, neue Dateien, Webshell-Indikatoren, Dienständerungen, geplante Aufgaben und ungewöhnliche ausgehende Verbindungen verdienen alle eine Prüfung, wenn sich das Expositionsfenster mit bekannter Ausnutzung überschneidet.

Dieselbe Logik gilt für Zugangsdaten und Secrets. Hatte der Server Zugriff auf Dienstkonten, Datenbank-Zugangsdaten, Zertifikate, API-Keys oder administrative Sitzungen, sollten Sie prüfen, ob diese Secrets rotiert werden müssen. Der richtige Umfang hängt von den Beweisen ab, aber die Frage sollte explizit gestellt werden, statt sie stillschweigend zu übergehen.

Ein sauberer Neuaufbau ist bei einem hochwertigen Server mit glaubwürdigen Kompromittierungsanzeichen oft der endlosen Unsicherheit vorzuziehen. Diese Entscheidung ist operativ teuer — genau deshalb zählen getestete Konfigurations- und Content-Wiederherstellung schon vor dem Notfall.

Was sollten Backup-Teams jetzt überprüfen?

Backup-Teams sollten überprüfen, ob sie SharePoint-Inhalte und unterstützende Komponenten in eine saubere Umgebung wiederherstellen können, ohne auf dieselben Identitäten und administrativen Pfade angewiesen zu sein, die ein Angreifer möglicherweise kompromittiert hat. Ein als erfolgreich markierter Backup-Job ist ein nützlicher Beleg, aber kein Wiederherstellungstest.

Beginnen Sie mit der Recovery-Kette. Identifizieren Sie die SharePoint-Datenbanken, Konfigurationsinformationen, Zertifikate, Dienstkonten, DNS-Abhängigkeiten, Load-Balancer-Einstellungen und alle externen Dienste, die ein Wiederaufbau benötigen würde. Entscheiden Sie dann, welche Teile aus dem Backup kommen und welche aus vertrauenswürdiger Konfiguration neu erstellt werden müssen. Wenn das Team diese Abfolge an einem normalen Tag nicht erklären kann, wird ein aktiver Ransomware-Vorfall die Lücke erheblich verschärfen.

Die umfassendere Lehre zur Ransomware-Wiederherstellung lautet: Ausfallunabhängigkeit. Wiederherstellungskopien sollten nicht vollständig von denselben Zugangsdaten, Verzeichnisdiensten, Speicherberechtigungen oder demselben Management-Netzwerk wie die Produktivumgebung abhängen. Ein Angreifer mit Domänen-Zugriff sollte nicht automatisch in der Lage sein, jeden Wiederherstellungspunkt zu zerstören.

Für Proxmox-Umgebungen, die unterstützende Workloads hosten, hilft die Anleitung zu Proxmox Backup Server beim Nachdenken über getrennte Wiederherstellungskopien — das Prinzip ist aber plattformneutral. Halten Sie unabhängige Kopien vor, schützen Sie die Management-Ebene, überprüfen Sie die Integrität, und führen Sie tatsächlich Wiederherstellungen durch.

Was würde ich heute mit einem exponierten SharePoint-Server tun?

Ich würde zunächst die genaue SharePoint-Version und den Patch-Level bestätigen und dann dokumentieren, wann der Fix für CVE-2026-45659 eingespielt wurde. War der Server aus dem Internet erreichbar und blieb bis Juli oder August 2026 verwundbar, würde ich ihn als Untersuchungsziel behandeln, statt ihn nach dem Patchen einfach für sicher zu erklären.

Als Nächstes würde ich anhand der Microsoft- und CISA-Anleitung nach Kompromittierungsanzeichen suchen, Identitäts- und Endpoint-Telemetriedaten prüfen und sensible Zugangsdaten rotieren, wenn die Beweislage oder der Expositionspfad das rechtfertigt. Gleichzeitig würde ich eine saubere Wiederherstellungsoption vorbereiten, damit das Incident-Team nicht gezwungen ist, zwischen dem Vertrauen in einen fragwürdigen Server und einem improvisierten Wiederaufbau unter Druck zu wählen.

Für einen Server, der bereits im Mai zügig gepatcht wurde und keine nennenswerte Exposition aufweist, kann die Reaktion angemessen ausfallen. Für einen Server, der exponiert blieb, während die Ausnutzung bereits bestätigt war, sollte die Schwelle deutlich höher liegen. Die praktische Faustregel ist einfach: Sobald bekannt ist, dass eine Schwachstelle Teil von Ransomware-Aktivität ist, beantwortet der Patch-Status nur eine Frage. Sie brauchen weiterhin den Beweis, dass das System, das Sie behalten, auch wirklich das System ist, für das Sie es halten.