Mittwald says an MCP flaw compromised 56 projects, first block came 7 days 20 hours later; AI is its inference

7 days 20 hours from the exploit to the first block, on Mittwald's own printed times

Mittwald CM Service, a web hosting provider for agencies in Espelkamp, Germany, published a post on 7 November 2026 headed Sicherheitsvorfall am MCP-Server, a security incident at its MCP server. It says the attacker registered an account at 14:58 on 27 October and used it at 15:03 to exploit a flaw in that server, and that Mittwald blocked the attacker's first account at 11:11 on 4 November. That is 7 days 20 hours 8 minutes (derived, counted by script from the two printed times, which carry no time zone in the post). The Record, a news site, calls it eight days. That matches the calendar count from 27 October to 4 November, which is 8 days (derived), and Mittwald's own FAQ asks why the attack was only noticed after a week.

That interval does not establish when the attacker last acted, when any customer project was first reached, or how the attacker was finally noticed. It runs from an exploit to a block, so it bounds the time to discovery from above: the post says the unusual behaviour was found on the morning of 4 November, before the block. It also does not establish that artificial intelligence was involved. The post says the log timing "points to" AI tools; The Record says Mittwald gave no other evidence. Everything here is as read from 18:29 UTC on Monday 9 November 2026: the post, Mittwald's FAQ page (stamped 7 November 2026, 10:56), Mittwald's status page entries, an agency template Mittwald published, and The Record's report of 9 November 2026 (14:17 UTC by its page data), which is a secondary.

A note on interest, once: Mittwald sells hosting, including AI hosting (its page header lists "Container- und AI-Hosting"), and this account of its own incident is its own. The post is in German. Every English rendering of German in this article is this site's own translation and is marked. English quoted from The Record is The Record's wording. Times are as printed. Mittwald's status page labels its times CET (CEST in October), and its 12:53 entry on 4 November matches the post's 12:53, so this site reads the post's times as local German time (an inference).

What Mittwald says happened, in the order it gives

The post opens with the attacker, before the discovery. "Am Abend des 21.10. war die ganze IT-Welt mit PHP2Shell beschäftigt." (this site's translation: on the evening of 21 October the whole IT world was busy with PHP2Shell). It continues that at that moment the attacker tested a weakness in Mittwald's MCP server for the first time, and from 23 October moved around the platform as a regular user, registering test accounts, using extensions and making simple injection attempts. Then the two printed times: a further account at 14:58 on 27 October, and at 15:03 the flaw "found in the MCP server" was exploited, five minutes later (derived). Mittwald does not say whether the flaw needed a registered account, only that the attacker registered one first.

The PHP link. Mittwald says the attacker began testing while everyone was busy with PHP2Shell. It does not say the two are related. Mittwald's own status page does show that its team was in a PHP incident at the time: an entry opened at 14:16 on 21 October (CEST) and resolved at 00:28 on 22 October (derived 10 hours 12 minutes, matching the page's own count), so the evening of 21 October falls inside it. That entry also says Mittwald's internal checks had found no sign the PHP exploit was used on its infrastructure. This site covered the PHP flaws in one briefing and another; neither concerns Mittwald, and no source read ties the MCP flaw to them.

Discovery and containment, 4 November. On the morning of 4 November Mittwald "discovered unusual behaviour in one of our systems" (this site's translation). It blocked the attacker's first account at 11:11, started analysis, and at 12:53 had a sense of the scope and set the status page to "Untersuchung" (investigation). It then took parts of its systems offline as a precaution, identified the MCP server as the entry point and switched it off. By the evening the mStudio, its management platform, was online again, and the web projects had been reachable throughout, the post says. The status page records a restriction on the mStudio from 12:53 to 18:27 that day (5 hours 34 minutes, derived).

Zoom

Containment, 5 to 7 November. Shortly after midnight on 5 November, the post says, Mittwald blocked projects in which traces of the attacker were found, and switched off registration of new accounts. During the day it blocked mStudio login and SSH access to customer projects, with outside forensic experts supporting it, and informed "the competent authorities" (this site's translation). On 6 November it evaluated "56 compromised projects" and the MCP server forensically, and after repeated scans found no further compromised projects and could currently prove no attacker activity. On 7 November, a Saturday, mStudio and SSH were reopened, the websites blocked as a precaution stayed blocked, and passkeys became available. The customer centre, and the websites managed in it, were never affected by the incident, Mittwald says.

What the FAQ adds: session tokens, a closed flaw and a narrower scope

The blog post says nothing about what the attacker took. Mittwald's MCP FAQ, stamped 7 November 2026, 10:56, does. It says the MCP server is "an interface through which customers could connect their mStudio to AI assistants", and that "access credentials (tokens) of users of this interface were read out" (this site's translation of both). It adds that no passwords were read, only session tokens, and that all of them were revoked. A token let the attacker reach the user's mStudio with that user's rights, and so any project the user could reach. The FAQ also says the flaw was in Mittwald's MCP server and has been closed.

This is the part of the story the post's title does not carry. The MCP server was sold as a convenience, a way to let an AI assistant drive a hosting account. Per the FAQ, what the attacker obtained from it was the keys to those accounts, at the full rights of each user. Mittwald's template for agencies, which it published for them to adapt, says the same in plain terms: the unauthorised access "was possible from 27 October 2026 until the tokens were blocked on 4 November 2026" (this site's translation). It lists what a token could in principle reach in a project: the site files and code, the database, third party credentials stored in the project, and mailboxes managed through it. Of the third party credentials it says access was technically possible and there are no indications of it so far.

Mittwald also says it scans every project reachable with a stolen token for traces of the attacker, switches off projects where it finds traces, and, per the template, restores them from a backup dated before 27 October. On whether data surfaced elsewhere it says it has no indications, and that a check of relevant platforms found no published data. That is Mittwald's check of its own incident and has not been independently verified.

What the word AI rests on

The post says Mittwald's logs show the attacker working "extremely fast" through the system, that this "points to the use of AI tools", and that in places only seconds pass between steps that would take a human attacker clearly longer (this site's translations of the German quoted in the Technical details section). The Record reports the same words as "show that he worked his way through our system extremely quickly" and then states: "Mittwald provided no other evidence of AI involvement." It adds that Mittwald did not immediately respond when asked to distinguish AI tools from conventional scripts.

Zoom

Timing is a weak discriminator. Gaps of seconds between steps are what ordinary scripts, scanners and automation frameworks produce, with or without a language model, and a person with a prepared toolkit can also be quick. That is this site's reading, not a finding in any source. The post gives no step, no count of fast steps and no log source, so a reader cannot tell which parts of the intrusion moved at machine pace or whether the preparation days, which the FAQ says looked like normal user behaviour, did. What the logs may show is automation. Whether that automation was AI is Mittwald's inference.

The post closes with an expectation: "KI-Angriffe werden in Zukunft häufiger auftreten." (this site's translation: AI attacks will occur more often in future), preceded by "first the PHP2Shell flaw, now the attack on our systems". That is a forecast by the company, offered with no evidence beyond these two events. Mittwald's own related article, listed on the same page, describes PHP2Shell as two weaknesses in the PHP core, and nothing read ties it to AI. The count of 56 compromised projects and the token theft stand or fall on Mittwald's forensics, not on whether the attacker used AI.

Friendly labels doing the work of a control

An interface for AI assistants. The FAQ's own description of the MCP server is a connector between a hosting account and an AI assistant. The label suggests a convenience layer. On the FAQ's account it was also a path that could hand out session tokens carrying a user's full rights. A connector that holds or passes that kind of credential is part of the hosting platform's control plane, whatever it is called.

A regular user and test accounts. The attacker's first steps are described as those of a regular user who registers test accounts. Mittwald disabled registration of new accounts on 5 November, which suggests registration was open. Whether registration needed payment, a verification step or an approval is not stated. A free account that can reach an exploitable tool server is a different exposure from an account only a paying customer can have.

Precaution and routine checks. The status page called the first public entries a restriction (12:53 on 4 November) and, at 14:19, a "customary security check" for unusual behaviour in the mStudio. At 14:58 it said the check was complete and that action was needed for only very few customers (this site's translations). On 5 November at 12:11 it said it could not rule out that unauthorised access to its systems was still possible, and at 17:02 named the MCP server. A precaution can be an honest control. It is not the same as a finding, and the wording moved from one to the other over 29 hours 51 minutes after the first block (derived).

What Mittwald states, and what it does not

Where the sources differ

The differences are listed, not resolved. This site follows the post and the FAQ for what Mittwald says, and notes where they or the status page disagree with each other or with The Record.

What to do, in order

Technical details

Mittwald's post, FAQ, status entries and template print no CVE number, no version string, no payload, no request or log line, and no indicators: no addresses, domains, hashes or file names. None are invented here. The post prints the flaw only as a weakness or flaw found in its MCP server. What the sources do print is times, the sequence, the token facts and the defender advice. It is reproduced below, in the original German, so a security team can check the wording behind this article's translations.

The post's account of the attacker. Copied from the Mittwald blog post. This is the full evidence for the dates, the account registration, the exploit time, the timing claim and the treatment of all data from 27 October as compromised. In this site's translation: the attacker first tests a flaw in the MCP server; from 23 October he acts as a regular user with test accounts, extensions and simple injection attempts; on 27 October at 14:58 he registers another account and at 15:03 exploits the flaw; the logs show him working extremely fast, which points to AI tools, with only seconds between steps; he disguises his access and runs diversionary moves; Mittwald treats all data from 27 October as compromised.

Genau zu dieser Zeit testet der Angreifer erstmalig eine Schwachstelle in unserem MCP-Server.
Ab dem 23.10. bewegt er sich als regulärer User auf unserer Plattform.
Er registriert Testkonten, nutzt Extensions und führt einfache Injection-Versuche durch.
Am 27.10. um 14:58 registriert er ein weiteres Konto, mit dem er um 15:03 Uhr die im MCP-Server gefundene Lücke gezielt ausnutzt.
In unseren Protokollen können wir nachvollziehen, dass er sich extrem schnell durch unser System arbeitet.
Das deutet auf die Verwendung von KI-Tools hin.
Teilweise vergehen nur Sekunden zwischen Schritten, die bei einem menschlichen Angreifer deutlich länger dauern müssten.
In unseren Protokollen können wir außerdem nachvollziehen, dass der Angreifer seine Zugriffe tarnt und verschiedene Ablenkungsmanöver durchführt, auf die wir uns zunächst konzentrieren.
Für uns war nach Analyse dieses zeitlichen Verlaufs klar: Wir behandeln alle Daten ab dem 27.10. als kompromittiert.

The FAQ on tokens and the flaw. This is what Mittwald says was read out and what it did about it. A defender with an MCP style connector can compare it with the credentials their own tool servers hold. This site's translation: the flaw was in the MCP server; tokens of its users were read out; no passwords, only session tokens, all revoked; a token gave access to the user's mStudio with the user's rights.

Die Lücke lag in unserem MCP-Server. Sobald wir davon wussten, haben wir den Server vom Netz genommen, den Vorfall vollständig analysiert und die Lücke geschlossen.
Dabei wurden Zugangsdaten (Tokens) von Nutzern dieser Schnittstelle ausgelesen.
Es wurden keine Passwörter ausgelesen, sondern Sitzungs-Tokens. Diese Tokens wurden alle widerrufen und sind nicht mehr gültig.
Das Token erlaubte Zugriff auf dein mStudio mit deinen Rechten. Der Angreifer konnte damit auf Projekte zugreifen, auf die du Zugriff hattest.
Der Angreifer hat seine Vorbereitungen gezielt getarnt. Er hat dafür Aktionen genutzt, die wie ganz normales Nutzerverhalten aussahen.

What the FAQ tells affected users to do and look for. A customer works through the steps, then checks projects for the listed traces. This site's translation: change the password, enable two factor authentication, check API keys, project tokens and SSH keys, renew stored third party credentials, inform your users; suspicious are SSH users you do not know, unknown files in the project directory and API keys you did not create.

Passwort in mStudio ändern.
Zwei-Faktor-Authentifizierung aktivieren.
API-Keys, Project Tokens und SSH-Keys in deinen Projekten prüfen und unbekannte Einträge löschen. Achte auf SSH-User, die du nicht angelegt hast.
Zugangsdaten von Drittdiensten, die du in deinen Projekten hinterlegt hast (Datenbanken, Mail, externe APIs), erneuern.
Deine Nutzer im Projekt informieren.
Verdächtig sind SSH-User, die du nicht kennst, unbekannte Dateien im Projektverzeichnis und API-Keys, die du nicht angelegt hast.

The status entry that first names the MCP server. Copied as printed on the status page, including the printed spelling ubefugten. It is dated 17:02 CET on 5 November 2026 and is the first of the saved entries to name the MCP server. A customer can use it to confirm the date Mittwald publicly tied the incident to this component.

Unsere Analysen haben einen ubefugten Zugriff auf das mStudio über unseren MCP-Server festgestellt. Wir arbeiten mit Hochdruck an der Analyse und daran, die Folgen des Vorfalls zu beheben. Zu Deinem Schutz sind vorübergehend einige Funktionen deaktiviert: MCP-Server Login ins mStudio SSH-Zugriff mittwald Extensions Bestellungen Das ist eine reine Vorsichtsmaßnahme. Sobald alles wieder läuft, geben wir Dir Bescheid.

The agency template on the access window and restoration. From the template Mittwald offers to agencies. This site's translation: the unauthorised access was possible from 27 October 2026 until the tokens were blocked on 4 November 2026; projects with traces are blocked and restored from a backup dated before 27 October. The third line is a placeholder in the template, not a statement that a data protection authority was informed.

Der unbefugte Zugriff war vom 27.10.2026 bis zur Sperrung der Token am 04.11.2026 möglich.
Findet mittwald in einem Projekt Spuren des Zugriffs, sperrt mittwald es vorsorglich und stellt es aus einer Sicherung mit Stand vor dem 27.10.2026 wieder her.
Nach eigenen Angaben hat mittwald die zuständige Datenschutzbehörde [informiert / Formulierung aus der mittwald FAQ übernehmen].

The timeline as printed. Times are as printed by each source; the status page labels them CET or CEST. Rows marked derived are this site's counts.

The question the post leaves open

Mittwald says the attacker was a regular user from 23 October, registered an account at 14:58 on 27 October, exploited the MCP server five minutes later, and was first blocked at 11:11 on 4 November, and that its own logs show the attacker moving in seconds. If those logs recorded each step at the time, what did Mittwald's monitoring do with the registration and the burst of calls in those five minutes, and what finally made someone look on the morning of 4 November? Mittwald says a detailed account will follow in the next week, after analysis and recovery. This article is a first reading of what it has published so far.

Key facts