MCP-Server-Angriff beim Webhoster: Wenn der Notbetrieb zum Normalfall wird

Was tatsächlich passiert ist

Laut heise online (12.11.2026) hatte Mittwald am 5. November den Zugriff auf den MCP-Server, das Verwaltungsportal mStudio, SSH-Verbindungen, die „mittwald Extensions" und das Bestellsystem eingeschränkt und bis zum 7. November schrittweise wieder freigegeben. In der Nacht des 12. November folgte der Rückschlag: SSH, mStudio und das Kundencenter waren erneut nicht erreichbar.

Die Unternehmenswebsite ist derzeit im Notbetrieb, weite Teile liefern nur noch 404-Fehler. Ein Hinweisgeber sprach gegenüber heise von einem Defacement, also vom Austausch der Inhalte durch die Angreifer. Dem widerspricht Mittwald ausdrücklich: Man habe die Seite vorsorglich selbst vom Netz genommen und eine Statusseite vorgeschaltet. Den Kunden teilt das Unternehmen mit, die bei ihm gehosteten Websites seien von der Abschaltung nicht betroffen und durchgehend erreichbar. Nach eigener Darstellung hatte man es mit KI-unterstützten professionellen Angreifern zu tun; Details zu den Gegenmaßnahmen will Mittwald nach Abschluss mitteilen. Vorher hatte der Hoster im Zusammenhang mit der „php2shell"-Lücke bereits alle Kundenprojekte vorsorglich abgeschaltet.

Dazu passt eine Warnung, die zwei Tage älter ist: Das CERT-EU beobachtet laut heise (11.11.2026) eine rapide Zunahme von Angriffen mit Agenten-Frameworks wie Artex. Das Werkzeug war ursprünglich für Penetrationstests gedacht, der ursprüngliche Autor hat das Repository im Oktober 2026 entfernt, unabhängige Forks kursieren weiter. Der Effekt ist nicht, dass die KI etwas völlig Neues tut — sie tut es häufiger, schneller und parallel, mit höherer Erfolgsquote. Microsoft meldete Artex-Kampagnen gegen Finanzorganisationen.

Meine Einordnung

Die naheliegende Lesart lautet: „Kundenwebsites waren erreichbar, also ist ja nichts passiert." Das halte ich für den gefährlichsten Satz in dieser Geschichte. Erreichbarkeit ist eine Aussage über einen Webserver, nicht über die Integrität eines Systems. Wenn die Verwaltungsebene eines Hosters kompromittiert war, dann ist die spannende Frage nicht, ob die Startseite 200 zurückgibt, sondern ob Deployments, DNS-Einträge, Mailrouting oder Backups in dieser Zeit angefasst wurden. Ein HTTP-Status beantwortet das nicht.

Der zweite Punkt ist unangenehmer: Die Admin-Ebene eines Dienstleisters ist eine gemeinsame Angriffsfläche aller seiner Kunden. Ein Handwerksbetrieb, eine Kanzlei, ein Steuerbüro mit Website beim selben Anbieter teilt sich ein Risiko, das er weder sieht noch selbst absichern kann. In Mandaten frage ich inzwischen standardmäßig: Wer außer Ihnen hat noch Adminzugang zu dieser Website, zu diesem DNS, zu diesem Repository? Die Antwort ist oft erstaunlich lang — die alte Agentur, ein Freelancer von 2021, ein Tool, das niemand mehr kennt.

Und dann ist da der MCP-Server selbst. Das Model Context Protocol ist eine Schnittstelle, über die KI-Assistenten Werkzeuge aufrufen: Dateien lesen, Befehle ausführen, Deployments anstoßen. Das ist praktisch, ich nutze es selbst. Wer aber einem Agenten ein Token mit Schreibrechten gibt, weil es bequem ist, hat einen neuen Mitarbeiter eingestellt, der rund um die Uhr arbeitet, nie krank wird und keine Fragen stellt. Ein Angreifer, der an diesen Zugang kommt, muss kein Passwort knacken — er erbt die Rechte, die man dem Agenten gegeben hat. In Projekten sehe ich genau das: Agenten mit Admin-Token, weil die Einrichtung mit eingeschränkten Rechten zwei Stunden länger gedauert hätte.

Dass Mittwald die eigene Website abschaltet, statt sie online zu lassen, ist übrigens kein Zeichen von Schwäche. Es ist das, was ich im Ernstfall erwarte: lieber eine Statusseite und 404 als eine Seite, deren Inhalt man nicht mehr kontrolliert. Ob es ein Defacement gab, lässt sich von außen nicht beurteilen — dazu sagt die Quelle nichts Belastbares.

Was Sie jetzt konkret tun können

1. Zugriffsliste anlegen. Wer hat Admin-, SSH-, DNS- und Deploy-Rechte? Menschen, Agenturen, Tools, KI-Agenten. Jeden Eintrag, den Sie nicht erklären können, streichen.

2. Ausfallplan auf einen Zettel schreiben. Was tun Sie, wenn das Kundencenter drei Tage nicht erreichbar ist? Wen rufen Sie an, welche Nummer, welche Statusseite, wer informiert Ihre Kunden?

3. Backup außerhalb des Hosters. Ein Backup, das beim selben Anbieter liegt, ist im Ernstfall kein Backup. Einmal die Wiederherstellung üben, nicht nur den Job einrichten.

4. Agenten und Schnittstellen entprivilegieren. Eigene Dienstkonten, minimale Rechte, Protokollierung. Ein MCP-Server mit Schreibzugriff auf Produktivsysteme gehört hinter VPN und Freigabe.

5. Änderungen beobachten. Alarm auf DNS-Änderungen und Deployments, Statusseite des Hosters abonnieren. Wer merkt, wenn nachts ein Zertifikat getauscht wird, hat gewonnen.

Wenn Sie bei Punkt 1 und 3 ehrlich „weiß nicht" antworten, ist das kein Grund zur Panik, aber ein guter Zeitpunkt für einen Blick auf die eigene Infrastruktur. Genau dafür ist IT-Security da, und die technische Seite steht unter IT-Infrastruktur. Für ein kurzes Gespräch reicht ein Kontakt.

Quellen

• heise online, „Angriff über MCP-Server: Webhoster Mittwald im Krisenmodus", 12.11.2026 — Link
• heise online, „CERT-EU warnt: Rapide Zunahme der Angriffe mit Agenten-Frameworks wie Artex", 11.11.2026 — Link