ToolShell, SharePoint – und die Bequemlichkeit des Kontrollverlusts

Warum Sicherheitslücken nicht nur technische Risiken sind, sondern politische Entscheidungen provozieren sollten

Die neu entdeckte Sicherheitslücke CVE-2025-53770, in Fachkreisen unter dem Namen „ToolShell" bekannt, offenbart einmal mehr ein fundamentales Dilemma moderner IT: die wachsende Diskrepanz zwischen technischer Machbarkeit und strategischer Abhängigkeit. Betroffen ist diesmal Microsofts SharePoint – genauer gesagt die On-Premise-Versionen Enterprise Server 2016 und Server 2019. Die Cloud-Varianten? Natürlich nicht.

Und hier beginnt das eigentliche Problem.

Eine Lücke mit System – technisch, wirtschaftlich, strategisch

Die Lücke ermöglicht die Remote Code Execution via manipulierten HTTP-Requests. Ein Angreifer muss keinen Benutzer kompromittieren, keine Authentifizierung umgehen – ein gezielter Request reicht. Die Folge: Vollständiger Zugriff auf den Server, Diebstahl der ASP.Net Machine Keys, Persistenz durch gefälschte Tokens. Kritischer geht es kaum.

Microsoft hat Patches für einige Versionen bereitgestellt, nicht aber für SharePoint 2016 – obwohl diese Version nach wie vor im Einsatz vieler Behörden, mittelständischer Unternehmen und institutioneller Umgebungen ist. Selbst dort, wo Updates vorliegen, sind zusätzliche Maßnahmen notwendig: Key-Rotation, IIS-Neustart, manuelle Prüfung auf Kompromittierung.

Und doch ist es nicht die technische Komplexität allein, die Fragen aufwirft. Es ist die – mittlerweile fast schon ritualisierte – Erkenntnis, dass Microsofts Cloud-Angebote regelmäßig von diesen Problemen „zufällig" verschont bleiben.

„Die Cloud ist sicher" – sagt der Anbieter der Lücke

In Microsofts Kommunikation zur ToolShell-Lücke findet sich ein bemerkenswerter Satz:

„Microsofts Cloudangebote sind nicht betroffen."

Ein Hinweis, der rein technisch korrekt ist – aber strategisch viel sagt. Denn während On-Prem-Kunden um Updates und Workarounds ringen, während Systeme kompromittiert und Forensik-Teams aktiviert werden müssen, präsentiert sich Azure als Insel der Stabilität. Sicher, wartungsarm, sorgenfrei.

Doch diese Sicherheit hat ihren Preis. Und der wird in der Debatte zu oft ausgeblendet.

Die stille Migration in den Lock-In

Was die Branche als „Modernisierung" oder „Cloud-First-Strategie" feiert, ist in Wirklichkeit oft nichts anderes als ein strategisch orchestrierter Kontrollverlust. Schritt für Schritt verlieren IT-Entscheider die Hoheit über ihre Systeme. Erst kommt die Abhängigkeit vom Patch-Zyklus. Dann von der Plattform. Dann von der Roadmap des Anbieters. Und am Ende von seiner Rechtsordnung.

Denn was in Azure läuft, unterliegt nicht der DSGVO – sondern dem CLOUD Act. Und spätestens seit Microsoft unter Eid zugeben musste, dass kein Schutz vor US-Zugriff garantiert werden kann, sollte klar sein: Die Cloud ist nicht das bessere Rechenzentrum. Sie ist ein anderes Land – mit anderen Gesetzen, anderen Interessen und anderen Zugriffen.

Wer in diese Welt migriert, gibt nicht nur Wartung ab. Sondern auch Souveränität.

Warum Alternativen nicht nur „nett gemeint" sind

Dabei gibt es sie längst: deutsche Anbieter, die containerisierte Plattformen betreiben, mit Fokus auf Sicherheit, Nachvollziehbarkeit und Kontrolle. Managed Kubernetes. Self-Hosted GitOps. Service Meshes für Isolierung und Mandantenschutz. Alles verfügbar, alles bewährt. Und: alles unter europäischer Rechtsprechung, auditierbar, nachvollziehbar – souverän.

Doch diese Anbieter haben keinen Milliarden-Marktetingapparat, keine Eventbudgets für CIO-Gipfel, keine Budgets für Incentives. Sie überzeugen mit Substanz statt Symbolik. Und gerade deshalb laufen sie Gefahr, übersehen zu werden – von denen, die kurzfristige Entlastung mit langfristiger Abhängigkeit verwechseln.

Der wahre Kern der Debatte

ToolShell ist keine Einzelfall-Meldung. Es ist ein Beispiel für ein systemisches Problem:

Sicherheitslücken sind die eine Gefahr. Die Reaktion darauf ist die andere.

Wenn Patches verzögert werden. Wenn Cloudlösungen überbetont, Alternativen ignoriert und Risiken relativiert werden. Dann entsteht kein sicherer Digitalstaat – sondern ein verwundbarer. Einer, der sich mehr um Skalierbarkeit als um Souveränität sorgt. Einer, der nicht mehr selbst entscheidet, sondern von Plattformen abhängig ist, die ihm jederzeit den Zugriff entziehen könnten.

Fazit: Wer Verantwortung will, muss Kontrolle behalten

IT-Sicherheit ist kein Produkt. Sie ist eine Architekturfrage. Eine Frage der Verantwortlichkeiten. Und eine Frage, ob wir unsere digitale Infrastruktur so gestalten, dass sie auch dann noch funktioniert, wenn politische, wirtschaftliche oder regulatorische Interessen sich ändern.

Microsofts Cloud-Angebote mögen komfortabel wirken – aber Komfort ist selten ein guter Berater für Resilienz.

Denn am Ende bleibt die zentrale Frage:

Wem gehört unsere digitale Zukunft – und wem sind wir im Zweifel ausgeliefert?