Nach dem Mittwald-Hack: KI-Schnittstellen von neun Hostern im Sicherheitsvergleich

Darum geht es

Immer mehr Webhoster lassen KI-Assistenten wie Claude, ChatGPT oder Cursor direkt an die Verwaltung von Websites, Domains und Servern. Dafür gibt es das Model Context Protocol (MCP), einen offenen Standard, über den eine KI fremde Dienste wie Werkzeuge bedienen kann. Beim Hoster Mittwald aus Espelkamp hat genau diese Schnittstelle Angreifern den Weg geöffnet.

Unsere These: Das Problem ist weniger ein einzelner Fehler im Code als die Bauart. Ein zentraler Remote-MCP-Server, also ein Dienst beim Anbieter, über den alle Kunden laufen, sammelt die Zugangsschlüssel vieler Kunden an einer Stelle. Ein lokaler MCP-Server läuft dagegen auf dem eigenen Rechner und kennt nur das eigene, eng begrenzte Token. Wir haben anhand der öffentlichen Dokumentation verglichen, wie neun Angebote aufgebaut sind. Geprüft haben wir, ob sie remote oder lokal laufen, wie die Anmeldung funktioniert, ob sich die Rechte begrenzen lassen, ob es einen Nur-Lesen-Modus gibt, wann Token ablaufen und ob die Aktionen des Agenten protokolliert werden. Eigene Angriffstests haben wir nicht gemacht.

Was bei Mittwald passiert ist

Laut Mittwald-FAQ und dem Bericht von webhosting.today lief der Angriff so ab:

• 21. Oktober: Der Angreifer testet die Lücke im MCP-Server und legt Testkonten an.
• 23. Oktober: Er bewegt sich wie ein normaler Nutzer durch die Plattform, probiert Extensions aus und versucht einfache Injection-Angriffe, bei denen eingeschleuste Befehle ausgeführt werden sollen.
• 27. Oktober: Er registriert ein weiteres Konto, nutzt fünf Minuten später die Lücke und liest die Sitzungstoken der MCP-Nutzer aus.
• 4. November: Mittwald bemerkt ungewöhnliches Verhalten und schaltet den MCP-Server ab.
• 5. bis 7. November: mStudio-Login, SSH, Extensions und Bestellungen werden gesperrt. Externe Forensiker prüfen 56 kompromittierte Projekte, danach geht mStudio wieder online.

Zwischen dem ersten Test und der Entdeckung lagen also 14 Tage, die eigentliche Ausnutzung blieb acht Tage unbemerkt. Ein Sitzungstoken ist ein digitaler Ausweis, der nach dem Login gilt. Wer ihn besitzt, braucht weder Passwort noch zweiten Faktor. Laut webhosting.today wirkte jedes gestohlene Token mit den Rechten seines Besitzers, also auf alle Projekte, die dieser Kunde erreichen konnte. Ob die Lücke in Mittwalds eigenem Code lag oder in einer Open-Source-MCP-Bibliothek, ist laut The Record offen. Dass der Angreifer KI eingesetzt hat, leitet Geschäftsführer Robert Meyer nur aus dem Tempo in den Logs ab, andere Belege nannte er nicht.

In der Nacht zum 12. November wurde Mittwald erneut angegriffen. Laut Statusseite kompromittierten die Angreifer über eine Sicherheitslücke die Unternehmenswebsite. Kundencenter, mStudio und alle SSH-Verbindungen wurden wieder abgeschaltet. Einen Zugriff auf interne Systeme hat Mittwald nach eigener Aussage nicht festgestellt. Wie die Angreifer diesmal hineinkamen, ist nicht veröffentlicht, der MCP-Server war ja schon seit dem 4. November offline. Laut dem jüngsten Eintrag der Statusseite laufen SSH und mStudio wieder, das Kundencenter sollte am 13. November gegen 12 Uhr folgen. Einen ausführlichen Bericht hat Mittwald angekündigt. Der MCP-Server bleibt bis auf Weiteres abgeschaltet.

Gute Regeln, falsche Stelle

Auf dem Papier war Mittwalds Anschluss ordentlich gebaut. Die Entwicklerdoku beschreibt OAuth 2.1 mit PKCE: Man meldet sich im Browser an, erlaubt bestimmte Rechte und das Werkzeug bekommt ein Token statt des Passworts. Zugriffstoken liefen nach etwa einer Stunde ab, Refresh-Token (Verlängerungsschlüssel, mit denen sich ein neues Zugriffstoken holen lässt) hielten „tagelang“. Die Standard-Scopes, also die erlaubten Rechte, waren nur lesend: user:read customer:read project:read app:read.

Interessant ist der Aufbau dahinter. Laut der Projektbeschreibung auf Glama besteht der Dienst aus dem MCP-Server und einer OAuth-Brücke, die sich einen verwalteten Redis-Speicher als gemeinsamen Zustands- und Sitzungsspeicher teilen. Der MCP-Server führt die Befehle über das Mittwald-Kommandozeilenwerkzeug mw aus. Ein solcher Proxy verwaltet zwangsläufig die Sitzungen aller angeschlossenen Kunden. Das GitHub-Repo mittwald/mcp-server, auf das Verzeichnisse verweisen, war bei unserem Abruf am 13. November nicht erreichbar (Fehler 404).

Die MCP-Spezifikation kennt diese Risiken. Sie warnt vor dem Confused-Deputy-Problem: Ein Proxy, der im Auftrag vieler Nutzer handelt, kann dazu gebracht werden, die Rechte des einen an einen anderen weiterzugeben. Proxy-Server müssen deshalb für jeden Client eine eigene Einwilligung einholen. Außerdem gilt: MCP-Server dürfen keine Token annehmen, die nicht ausdrücklich für sie ausgestellt wurden. Dass dieses Muster in der Praxis anfällig ist, zeigen die Lücken dieses Jahres. Die verbreitete Bibliothek FastMCP hatte bis Version 3.2.0 genau einen solchen Confused-Deputy-Fehler in ihrem OAuth-Proxy (CVE-2026-27124, „hoch“). Im offiziellen TypeScript-SDK konnte ein bösartiger Server laut Sicherheitshinweis gespeicherte Refresh-Token abgreifen (CVE-2026-104850, behoben in 1.31.0).

Unsere Einschätzung: Kurze Laufzeiten und enge Scopes begrenzen den Schaden eines einzelnen Tokens. Sie helfen aber wenig, wenn alle Token an einer Stelle liegen, die von außen erreichbar ist. Dann entscheidet ein Fehler über alle Kunden gleichzeitig.

Der Vergleich

Was die Tabelle zeigt

Am saubersten ist die IONOS Cloud. Der Server ionoscloud-mcp läuft lokal und spricht die IONOS-API direkt an. Laut FAQ ist er standardmäßig nur lesend. Schreibwerkzeuge für Compute Engine und Kubernetes werden erst registriert, wenn man IONOS_MCP_TOOL_SCOPE auf write oder destructive setzt. Vorher sieht die KI sie gar nicht. Anlegen und Löschen laufen in zwei Schritten: Zuerst kommt eine Vorschau mit einem Einmal-Code, der nach fünf Minuten verfällt. Die Doku empfordert ein eigenes Token mit Ablaufdatum, möglichst für einen eingeschränkten Sub-User. Einen Haken gibt es: Der optionale HTTP-Modus hat laut README keine eigene Anmeldung.

IONOS Hosting bedient seit August Domains, DNS, SSL, Webhosting und Server über „ein Token“. Schreibende Aktionen sollen laut Blog ausdrücklich freigegeben, protokolliert und auf den Scope des Tokens beschränkt sein. Ob der Dienst lokal oder remote läuft, beschreibt der Beitrag nicht, und Audit-Trails nennt IONOS erst als Ziel.

Bei den Remote-Anbietern gibt es große Unterschiede. Cloudflare lässt beim OAuth-Login die Rechte auswählen. Die zugehörige Bibliothek speichert Token, Codes und Geheimnisse laut README nur als Hashes, also als nicht umkehrbare Fingerabdrücke. Die eigentlichen Zugangsdaten sind mit einem Schlüssel verschlüsselt, den nur der Tokenbesitzer entschlüsseln kann. Ein abgegriffener Speicherinhalt nützt damit wenig. So wird die zentrale Bauart deutlich robuster. Vercel lässt nur geprüfte Clients zu und verlangt pro Verbindung eine Einwilligung. Gleichzeitig schreibt Vercel selbst:

Die Verbindung mit Vercel MCP gibt dem KI-System, das du nutzt, denselben Zugriff wie dein Vercel-Benutzerkonto.

Seit Juli kann der Dienst auch deployen. Bei Hostinger erbt ein API-Token laut Doku die Rechte des Nutzers, der es erstellt hat, und das Ablaufdatum ist optional. Bei Netlify fehlen Angaben zu Scopes und Laufzeit ganz.

Lokal heißt nicht automatisch sicher. Bei den Community-Projekten liegt das Token meist im Klartext in der Client-Konfiguration. netcup-mcp ist nicht mit netcup verbunden und kann Server abschalten, Snapshots löschen und über ein allgemeines Werkzeug jeden API-Endpunkt aufrufen. Bestätigungen überlässt das Projekt dem KI-Client. Hostinger warnt im eigenen README davor, den Server über npx zu starten, weil ein geklontes Repository sonst eigenen Code mit den Hostinger-Zugangsdaten ausführen könnte. Die MCP-Spezifikation widmet lokalen Servern ein eigenes Kapitel, denn sie laufen mit den Rechten des Nutzers. Vorteilhaft bei Hetzner: Die API vergibt Token pro Projekt mit „Read“ oder „Read & Write“. Ein „Read“-Token darf nur GET-Anfragen stellen, also nur abfragen. Das begrenzt den Schaden auf der Seite des Anbieters, egal was der MCP-Server tut.

Kaum jemand protokolliert, was der Agent tut. Außer IONOS dokumentiert kein Anbieter ein Protokoll der Agentenaktionen. Bei Mittwald war genau das der Punkt, an dem der Angriff hätte auffallen können.

Das Muster ist nicht auf Hoster beschränkt. Beim KI-Dienstleister Fireworks lagen laut Notion Chatverläufe mit eingefügten API-Schlüsseln, die beim Angriff offengelegt wurden. Notion hat betroffene Schlüssel am 11. November widerrufen. Bei Railway entschlüsselten Angreifer zentral gespeicherte Umgebungsvariablen. Und der Ausfall von Microsoft 365 hat diese Woche die Connectoren von Claude stundenlang lahmgelegt. Wo viele Schlüssel oder Abhängigkeiten zusammenlaufen, ist der Ausfall größer und die Beute attraktiver.

Checkliste für Agenturen und Shopbetreiber

1. Bestandsaufnahme: Liste alle KI-Anbindungen, API-Tokens, Project Tokens und SSH-Schlüssel auf und lösche, was du nicht zuordnen kannst.
2. Ein Token pro Agent und Projekt: Nutze nie das Token des Hauptkontos. Bei Agenturen sollten nicht alle Kundenprojekte an einem Benutzer hängen, mit dem auch der Agent arbeitet.
3. Nur lesen als Standard: Gib Schreibrechte nur zeitweise und nur für das Produkt, das wirklich geändert werden soll.
4. Ablaufdatum setzen: Nie „unbefristet“. IONOS empfiehlt etwa 24 Stunden für einmalige Abfragen.
5. Token sauber ablegen: Nicht in geteilte Konfigurationen oder Repos, besser in den Schlüsselbund des Betriebssystems. Lokale Server per festem Pfad starten und MCP-Bibliotheken aktuell halten.
6. Rückfragen anlassen: Schalte die Bestätigung im KI-Client für schreibende Aktionen nicht ab.
7. Keine Geheimnisse in Chats: Was du in einen KI-Chat kopierst, kann beim Anbieter oder dessen Zulieferer landen.
8. Notfallplan: Prüfe, ob sich ein Token in einem Schritt widerrufen lässt, halte Backups außerhalb des Hosters vor und bereite Texte für deine Kunden vor. Mittwald hat dafür Vorlagen veröffentlicht.

Unser Fazit

Mittwald hatte OAuth, kurze Token und lesende Standardrechte, also vieles, was Sicherheitsleitfäden fordern. Trotzdem reichte eine Lücke an einer zentralen Stelle für 56 Projekte. Unsere Einschätzung: Die Bauart bestimmt, wie groß der Schaden werden kann. Ein lokaler Server mit eng begrenztem, befristetem Token ist für Agenturen und Shops derzeit die robustere Wahl. Er verlagert die Verantwortung aber auf den eigenen Rechner. Remote-Dienste können mit verschlüsselter Token-Ablage wie bei Cloudflare deutlich sicherer gebaut werden, ob die Hoster das tun, sieht man in ihrer Doku meist nicht. Offen bleibt, was genau bei Mittwald schiefging. Erst der angekündigte Vorfallsbericht wird zeigen, ob die Lücke im eigenen Code oder in einer Bibliothek steckte.