Am Samstag, dem 7. November 2026, macht der Webhoster Mittwald CM Service GmbH & Co. KG aus Espelkamp in Nordrhein-Westfalen einen Sicherheitsvorfall öffentlich. Ein Angreifer hat eine Schwachstelle im MCP-Server des Unternehmens ausgenutzt – der Schnittstelle, über die Kundinnen und Kunden KI-Assistenten an die Verwaltungsplattform mStudio anbinden konnten. Dabei wurden nach Angaben von Mittwald Sitzungstokens von Nutzern dieser Schnittstelle ausgelesen, keine Passwörter. 56 Kundenprojekte gelten als kompromittiert und wurden forensisch untersucht. Der MCP-Server bleibt abgeschaltet. mStudio und SSH-Zugänge wurden an diesem Samstag wieder freigegeben.
Fünf Tage später, in der Nacht zum 12. November, sieht Mittwald die Angriffe als wieder aufgenommen. Die Unternehmenswebsite wird kompromittiert und vom Netz genommen; Blog und Vorfallsseiten liefern daraufhin 404-Fehler. Kundencenter, mStudio und SSH werden vorsorglich erneut abgeschaltet. Gehostete Kunden-Websites und E-Mail-Postfächer bleiben nach Darstellung des Unternehmens durchgehend erreichbar. Am Nachmittag des 12. November kündigt Mittwald an, Kundencenter und mStudio am 13. November bis spätestens 11:00 Uhr wieder freizugeben.
Der Fall gehört zu den ersten öffentlich dokumentierten Einbrüchen über einen MCP-Server bei einem großen deutschen Hoster. Er zeigt, dass eine Komfort-Schnittstelle für KI-Assistenten zur Steuerungsebene einer Plattform werden kann – mit den Rechten der jeweiligen Nutzer. Und er zeigt, wie schnell ein zweiter Schlag folgen kann, während die Aufräumarbeiten der ersten Welle noch laufen. Genau das solltest du dir merken, wenn in deinem Unternehmen KI-Assistenten an Verwaltungsoberflächen, APIs oder Hosting-Konten angebunden sind.
Der Weg der Angreifer: vom Testkonto in die Steuerungsebene
MCP, das Model Context Protocol, ist ein offener Standard, über den KI-Assistenten mit fremden Diensten sprechen und dort Aktionen ausführen können. Mittwald bot einen solchen Server an, damit Kundinnen und Kunden ihr mStudio – die Oberfläche zur Verwaltung von Webprojekten – an einen Assistenten anschließen können. Genau diese Schnittstelle wird zum Einfallstor.
Nach der Zeitleiste, die The Record und andere Berichte aus Mittwalds Blogbeitrag wiedergeben, testet der Angreifer die Schwachstelle erstmals am Abend des 21. Oktober. Mittwald merkt an, das sei genau zu der Zeit gewesen, als „die ganze IT-Welt mit PHP2Shell beschäftigt“ war – einer damals aktuellen Schwachstelle in PHP. Einen technischen Zusammenhang zwischen PHP2Shell und der MCP-Lücke behauptet das Unternehmen damit nicht. Ab dem 23. Oktober bewegt sich der Angreifer wie ein regulärer Nutzer: Er legt Testkonten an, nutzt Extensions und unternimmt einfache Injection-Versuche. Am 27. Oktober um 14:58 Uhr registriert er ein weiteres Konto und nutzt um 15:03 Uhr die Lücke gezielt aus.
Was der Angreifer damit erlangt, steht in der FAQ, nicht im Blog selbst: Sitzungstokens von Nutzern der MCP-Schnittstelle. Ein solches Token wirkt mit den Rechten der jeweiligen Nutzerin oder des jeweiligen Nutzers. Passwörter wurden laut Mittwald nicht ausgelesen, die betroffenen Tokens wurden widerrufen. Ob die Lücke in Mittwalds eigenem Code oder in quelloffenen MCP-Bibliotheken steckte, ist laut The Record unklar. Eine CVE-Nummer wurde öffentlich nicht genannt.
Entdeckt wird der Vorfall erst am Vormittag des 4. November, als Mittwald ungewöhnliches Verhalten feststellt. Um 11:11 Uhr wird das erste Angreiferkonto gesperrt, der MCP-Server als Einfallstor identifiziert und abgeschaltet. Auf der Statusseite taucht der MCP-Server namentlich am 5. November um 17:02 Uhr auf: „Unsere Analysen haben einen ubefugten Zugriff auf das mStudio über unseren MCP-Server festgestellt.“ (Die Schreibweise „ubefugten“ steht so auf der Statusseite.) An diesem Tag werden mStudio-Login, SSH, Extensions und Bestellungen vorsorglich deaktiviert, ein geringer Teil der Projekte gesperrt. Externe IT-Forensiker unterstützen die Analyse, die zuständigen Behörden werden informiert.
Am 6. November wertet Mittwald nach eigenen Angaben 56 kompromittierte Projekte und den MCP-Server forensisch aus. Wiederholte Scans sollen keine weiteren betroffenen Projekte ergeben haben. Am 7. November um 10:56 Uhr sind mStudio und SSH wieder erreichbar, Passkeys können eingerichtet werden. Die vorsorglich gesperrten Websites bleiben vorerst offline. Das Kundencenter und die darin verwalteten Websites waren laut Mittwald in dieser ersten Welle zu keiner Zeit betroffen.
„Nach den Vorfällen in der letzten Woche haben die Angreifer ihre Attacken auf unsere Infrastruktur wieder aufgenommen.“
Dieser Satz gehört zur zweiten Welle, nicht zur Entdeckung im Novemberanfang. Mittwald stellt beide Vorgänge als zusammenhängend dar. Eine unabhängige Bestätigung, dass es sich um dieselben Täter handelt, liegt öffentlich nicht vor.
56 Projekte – und was die Zahl sagt
Die Zahl 56 kommt aus Mittwalds eigener Auswertung und wird in der Berichterstattung einheitlich so übernommen. Sie bezeichnet Projekte, die als kompromittiert forensisch untersucht wurden, nicht automatisch 56 verschiedene Kundinnen und Kunden: Hinter mehreren Projekten kann derselbe Account stehen. Eine öffentliche Aufschlüsselung nach Kunden oder Schaden gibt Mittwald nicht.
Berichte über eine Agentur-Vorlage von Mittwald nennen, was in einem solchen Projekt grundsätzlich erreichbar sein kann: Dateien und Code, die Datenbank, gespeicherte Zugangsdaten für andere Dienste und darüber verwaltete Postfächer. Hinweise auf einen Zugriff auf fremde Dienste oder auf eine Veröffentlichung von Daten sehe Mittwald nach eigener Prüfung nicht. Das ist die Darstellung des Unternehmens, keine unabhängige Prüfung.
Wer den MCP-Server nie genutzt und keine persönliche Mail erhalten hat, ist nach dem Stand der FAQ vom 7. November nicht betroffen. Wer ihn genutzt hat, soll laut den wiedergegebenen Hinweisen das mStudio-Passwort ändern, Zwei-Faktor-Anmeldung oder Passkey aktivieren sowie API-Keys, Projekt-Tokens, SSH-Zugänge und hinterlegte Dritt-Zugangsdaten prüfen und erneuern.
Die KI-These – und was sie nicht belegt
Mittwald begründet die Vermutung, der Angreifer habe KI-Werkzeuge eingesetzt, mit der Geschwindigkeit in den Protokollen: Zwischen Schritten, die bei einem menschlichen Angreifer deutlich länger dauern müssten, lägen teilweise nur Sekunden. Geschäftsführer Robert Meyer wird von The Record mit dieser Begründung zitiert. Weitere Belege legte Mittwald demnach nicht vor. Auf die Frage, wie sich KI-Werkzeuge von herkömmlichen Skripten unterscheiden lassen, die Angreifern ebenfalls ein höheres Tempo ermöglichen, antwortete das Unternehmen The Record zunächst nicht.
Das solltest du nicht zu einem nachgewiesenen „KI-Angriff“ verkürzen. Sekundenabstände erzeugen auch Scanner, Skripte und Automatisierungs-Frameworks. Die Logs belegen, dass sehr schnell und vermutlich automatisiert vorgegangen wurde. Ob dahinter ein Sprachmodell steckte, ist eine Einschätzung von Mittwald. Für die 56 Projekte und den Diebstahl der Tokens spielt das übrigens keine Rolle: Der Schaden entsteht durch die Lücke und die Rechte der Tokens, nicht durch das Werkzeug, mit dem sie ausgenutzt wurden.
Am 12. November wiederholt Mittwald auf der Statusseite eine ähnliche Einordnung und spricht von „professionelle[n] Akteure[n], die automatisierte KI-Systeme nutzen“. Auch das ist die Sicht des Unternehmens.
Zeitstrahl des Ablaufs
Abend des 21. Oktober 2026:
Erster Test der Schwachstelle im MCP-Server, zeitgleich zur damaligen PHP2Shell-Lage. Quelle: Mittwald-Blog, wiedergegeben von The Record und TBA Berlin.Ab 23. Oktober 2026:
Der Angreifer bewegt sich als regulärer Nutzer, legt Testkonten an, nutzt Extensions, unternimmt Injection-Versuche. Quelle: dieselben Berichte.27. Oktober 2026, 14:58 und 15:03 Uhr:
Registrierung eines weiteren Kontos, gezielte Ausnutzung der Lücke. Sitzungstokens von MCP-Nutzern werden ausgelesen. Mittwald behandelt Daten ab diesem Tag als kompromittiert. Quellen: The Record; blured.de.4. November 2026, Vormittag:
Ungewöhnliches Verhalten fällt auf. Um 11:11 Uhr wird das erste Angreiferkonto gesperrt, der MCP-Server abgeschaltet. Quelle: Mittwald-Blog, wiedergegeben in den genannten Berichten.5. November 2026:
Statusseite: mStudio-Login, SSH und Extensions deaktiviert; später ausdrücklich unbefugter Zugriff auf das mStudio über den MCP-Server; ein Teil der Projekte und AV-Manager-Zugänge gesperrt. Externe Forensik, Information der Behörden. Quelle: Statusseite.6. November 2026:
Forensische Auswertung von 56 Projekten und des MCP-Servers. Mittwald veröffentlicht eine erste Zusammenfassung unter mittwald.de/lp/mcp-faq (diese Seite ist am 12. November nicht erreichbar). Quelle: Statusseite, 17:08 Uhr; TBA Berlin.Samstag, 7. November 2026, 10:56 Uhr:
mStudio und SSH wieder erreichbar, Passkeys möglich. Vorsorglich gesperrte Websites bleiben offline. Öffentlicher Blogbeitrag. Kundencenter in dieser Welle nicht betroffen. Quellen: Statusseite; The Record.Nacht zum 12. November 2026:
SSH erneut eingeschränkt, Registrierung neuer Nutzer deaktiviert, Website mittwald.de nicht erreichbar (ab 02:51 Uhr). Gegen 04:10 Uhr auch Login ins mStudio und Kundencenter vorsorglich deaktiviert. Um 06:52 Uhr stellt Mittwald fest, die Angreifer hätten eine Lücke ausgenutzt und die Unternehmenswebsite kompromittiert; Zugriff auf interne Systeme sei bislang nicht festzustellen. Quelle: Statusseite.12. November 2026, 14:14 Uhr:
Heise berichtet über den zweiten Angriff, den Notbetrieb der Website und 404-Fehler bei Blog und Vorfallsseiten; ein Hinweisgeber spricht von einem Defacement. Quelle: heise.12. November 2026, 16:05 Uhr:
Letztes Status-Update des Tages: Kundencenter und mStudio sollen am 13. November bis spätestens 11:00 Uhr wieder freigegeben werden. Websites und E-Mails bleiben erreichbar. Ob dieser Zeitplan gehalten wird, war bei Redaktionsschluss am Abend des 12. November noch nicht bestätigt. Quelle: Statusseite.
Die zweite Welle vom 12. November
Zwischen der Freischaltung am 7. November und der Nacht zum 12. November liegen fünf Tage. Mittwald hatte für die „kommende Woche“ einen ausführlicheren technischen Bericht angekündigt; bis zum 9. November lag er öffentlich noch nicht vor. Ob er danach erschien, lässt sich an den inzwischen unerreichbaren Seiten auf mittwald.de derzeit nicht prüfen.
Am 12. November ist die Lage eine andere als in der ersten Welle. Betroffen ist nach Mittwald die Unternehmenswebsite, nicht der MCP-Server als ausdrücklich genanntes Einfallstor. Interne Systeme seien bislang nicht kompromittiert, gehostete Kundenprojekte nicht von der Abschaltung betroffen. Gleichzeitig schaltet Mittwald aus Vorsicht wieder Kundencenter, mStudio und SSH ab. Heise schreibt, Kunden klagten über eingeschränkte Erreichbarkeit.
Die ursprünglichen Quellen der ersten Welle – Blog und FAQ – sind damit vorübergehend selbst nicht mehr lesbar. Wer den Vorfall nachvollziehen will, ist auf die Statusseite und auf Berichte angewiesen, die den Blog zwischen dem 7. und 9. November ausgewertet haben. Eine kompromittierte Unternehmenswebsite vom Netz zu nehmen, kann richtig sein. Gerade deshalb braucht ein Vorfallsbericht einen zweiten Kanal, der nicht auf derselben Website liegt – die Statusseite, die Mittwald in diesem Fall weiter betrieben hat.
Was heißt das für dein Unternehmen?
Der Fall ist kein reines Hosting-Thema. Immer mehr Unternehmen binden KI-Assistenten an Ticketsysteme, Cloud-Konsolen, Code-Repos oder Kundenportale an. Die Schnittstelle heißt nicht überall MCP, die Logik ist dieselbe: Ein Assistent bekommt Werkzeuge, und diese Werkzeuge wirken mit echten Rechten.
- 1.
KI-Anbindungen wie privilegierte APIs behandeln.
Der MCP-Server war als Komfortfunktion verkauft, arbeitete aber auf der Steuerungsebene: Tokens mit den Rechten der jeweiligen Nutzer. Inventarisiere, welche Assistenten in deinem Unternehmen oder bei Dienstleistern auf Verwaltungsoberflächen zugreifen dürfen, welche Rechte sie haben und wie lange ihre Tokens gelten. Ungenutzte Anbindungen gehören abgeschaltet. - 2.
Tokens kurzlebig und mit minimalen Rechten ausstellen.
Ein gestohlenes Sitzungstoken ohne Passwort reicht, wenn es vollwertig und langlebig ist. Begrenze Gültigkeit und Berechtigungen, widerrufe Tokens zentral, und überwache ungewöhnliche Nutzung – etwa viele Administrativeingriffe aus einem frisch registrierten Konto. - 3.
Registrierung, Testkonten und Injection-Versuche als Alarm behandeln.
Zwischen dem ersten Test am 21. Oktober und der Sperre am 4. November liegen zwei Wochen, zwischen der gezielten Ausnutzung und der Entdeckung fast acht Tage. In dieser Zeit gab es Testkonten, Extension-Nutzung und Injection-Versuche. Solche Muster müssen auffallen, bevor ein Token abfließt – nicht erst, wenn „ungewöhnliches Verhalten“ nicht mehr zu übersehen ist. - 4.
Die Lieferkette deiner Agentur oder deines Hosters mitdenken.
Für Endkunden einer Agentur kann ein Vorfall beim Hoster unsichtbar bleiben – oder genau deren Website, Datenbank und gespeicherte Zugangsdaten betreffen. Klärt vertraglich, wie schnell ihr informiert werdet, welche Logs ihr bekommt und wer im Ernstfall Endkunden und Aufsicht informiert. TBA Berlin, selbst Mittwald-Kunde, hat öffentlich gemacht, dass es den MCP-Server nie genutzt hat. Diese Trennung – betroffen oder nicht – musst du im eigenen Bestand nachvollziehen können. - 5.
Einen Vorfallskanal haben, der nicht auf der kompromittierten Website liegt.
Mittwald konnte auf der Statusseite weiter informieren, als mittwald.de offline ging. Ohne einen solchen zweiten Kanal bleibt nur die Gerüchtelage. Das gilt auch für dich: Statusseite, signierte Mails, eine vorbereitete Kundeninformation. - 6.
Die zweite Welle einplanen.
Ein Angreifer, der acht Tage unentdeckt blieb, kann wiederkommen. Härte die Systeme, die du gerade erst wieder öffnest, und nimm eine erneute, vorsorgliche Abschaltung als Szenario in den Notfallplan auf – inklusive der Frage, wie deine Kunden weiterarbeiten, wenn die Verwaltungsoberfläche zum zweiten Mal zu ist.
Wenn du prüfen willst, wo in deiner IT KI-Schnittstellen, langlebige Tokens oder unzureichend überwachte Verwaltungs-APIs ein vergleichbares Einfallstor bilden, kannst du dafür ein Security-Audit von Wasa Consult nutzen. Der Fall Mittwald zeigt vor allem eines: Die gefährliche Schnittstelle ist oft genau die, die du als Komfort gerade erst eingeschaltet hast.
Häufige Fragen
Quellen
- Mittwald: Statusseite, Vorfall „Ergriffene Vorsichtsmaßnahmen“. Laufend aktualisierte offizielle Darstellung; ausgewertet bis zum Eintrag vom 12.11.2026, 16:05 Uhr.
- The Record (Recorded Future News), Alexander Martin: Alleged AI-aided cyberattack exploits assistant interface to breach German web host, 9.11.2026. Gestützt auf Mittwalds Blogbeitrag vom 7.11.2026 und ein Gesprächsangebot an das Unternehmen.
- heise online, Dr. Christopher Kunz: Angriff über MCP-Server: Webhoster Mittwald im Krisenmodus, 12.11.2026.
- blured.de: Mittwald: Angriff über MCP-Server, Sitzungstokens ausgelesen, 9.11.2026. Gestützt auf Blog, FAQ und Statusseite von Mittwald.
- TBA Berlin, Carl D. Erling: Sicherheitsvorfall bei Mittwald, 8.11.2026.
- Mittwald: Blogbeitrag „Sicherheitsvorfall am MCP-Server“ und FAQ, veröffentlicht am 6./7.11.2026. Beide URLs antworteten am 12.11.2026 mit HTTP 404, nachdem die Unternehmenswebsite kompromittiert und vom Netz genommen wurde. Inhaltlich ausgewertet über The Record, die Statusseite und die zeitnahen Berichte oben.
