MCP server flaw lets attacker hijack 56 customer projects at German host Mittwald

What's going on

Mittwald CM Service, based in Espelkamp in northwestern Germany, offers hosting mainly for agencies. On November 7, 2026, it published a blog post titled "Security incident on the MCP server." It says an attacker gained access to customer accounts through a vulnerability in Mittwald's MCP server. MCP stands for Model Context Protocol, an open standard that lets AI assistants such as chatbots talk to other services and take actions there. Mittwald offered this kind of interface so customers could connect their mStudio to an AI assistant. mStudio is the control panel for web projects.

A total of 56 customer projects are considered compromised. Going by Mittwald's own timestamps, the attack went unnoticed for almost eight days. The Record, the news site run by Recorded Future, reported on November 9 and speaks of "eight days." Analyst Parminder Kumar Sharma has taken the incident apart in detail on his site pk-sharma.com. He compared the blog post, the FAQ, the status page and a template for agencies side by side and recounted every time span. The overview below is based on his analysis.

The timeline: a week of prep, five minutes to break in

Mittwald's own account starts on the evening of October 21. At that point, the host says, "the whole IT world was busy with PHP2Shell," a double vulnerability in the core of the PHP programming language. That's exactly when the attacker is said to have probed the MCP server flaw for the first time. Mittwald doesn't claim the two are technically connected, though. The status page only shows that the team was busy with the PHP incident at the time.

From October 23 on, the attacker moved around the platform like any ordinary user. He created test accounts, tried out extensions and attempted simple injection attacks. In these attacks, you sneak commands into input fields in the hope that the system will execute them. On October 27 at 2:58 p.m., he registered another account, and five minutes later, at 3:03 p.m., he exploited the flaw. Mittwald doesn't say whether an account was even needed for the attack. It's also unclear whether registration required payment or verification. All we know is that it was open enough to be shut down on November 5.

The attack was only spotted on the morning of November 4, when Mittwald says it noticed "unusual behavior in one of our systems." At 11:11 a.m., the attacker's first account was blocked. By 12:53 p.m., Mittwald had a first sense of the scale. After that, parts of the systems were taken offline as a precaution and the MCP server was switched off. Shortly after midnight, Mittwald locked the affected projects and disabled new registrations. Over the course of November 5, it blocked mStudio logins and SSH access. Outside forensic experts helped with the investigation, and Mittwald says "the relevant authorities" were notified. On Saturday, November 7, mStudio and SSH were reachable again.

What the attacker got

The blog post itself doesn't say what the attacker took. That only appears in the FAQ, which says credentials, specifically tokens, belonging to users of the MCP interface were read out. Tokens are digital IDs that keep you logged in after you sign in, so you don't have to enter your password every time. Mittwald says no passwords were stolen, and all tokens have since been revoked. But a single token was enough to get into mStudio with that user's full permissions, and from there into every project the user had access to.

The template Mittwald published for agencies and their clients spells out what that can mean in practice. In principle, the attacker could reach the website's files and code, the database, credentials for other services stored in the project, and mailboxes managed through it. According to the template, access to credentials for third-party services was technically possible, but there's no sign of it so far. Mittwald also says its own review found no indication that data was published anywhere. None of this has been independently confirmed.

Sharma highlights a notable point. The MCP server was marketed as a convenience feature that lets an AI assistant operate your hosting account. In reality, it was part of the platform's control plane, because it could issue or pass along keys with full user permissions. A friendly name doesn't change what permissions a component has.

How solid is the AI theory?

The "AI attack" headline hangs on a single sentence. Mittwald says the logs show the attacker worked through the system "extremely quickly," which "suggests" AI tools were used. Some steps were only seconds apart, and a human would have needed much longer. The Record puts it plainly:

Mittwald did not provide further evidence of AI involvement.

Asked how AI tools could be distinguished from conventional scripts, Mittwald did not initially respond, according to The Record. Sharma considers the timing a weak clue. Ordinary scripts, scanners and automation frameworks also produce gaps of a few seconds, no language model required. At best, the logs prove the attack was automated. Whether AI was behind it is Mittwald's guess. On top of that, the post doesn't name a single concrete step, quote a single log line, or say how many steps happened that fast.

At the end of the post, Mittwald predicts: "AI attacks will become more common in the future." That's the company's forecast. It's worth noting that Mittwald itself sells AI hosting. And for the 56 projects and the stolen tokens, it makes no difference whether AI was involved.

Contradictions and open questions

Mittwald's accounts don't always match up. The blog post says the MCP server was identified as the entry point as early as November 4. But it only shows up on the status page on November 5 at 5:02 p.m. Before that, the page talked about a "restriction" and a "routine security check" after which "only very few customers" would need to take action. Then, on November 5 at 12:11 p.m., it said unauthorized access could not be ruled out as still possible. According to the blog, mStudio was usable again overnight into November 6; according to the status page, not until November 7 at 10:56 a.m. There are also two readings of the scope. The blog treats all data from October 27 on as compromised. The FAQ, by contrast, says that anyone who never used the MCP server is not affected based on current knowledge.

A lot remains unanswered. Mittwald hasn't disclosed the type of vulnerability or a CVE number, the official identifier for security flaws. The Record notes it's also unclear whether the bug was in Mittwald's own code or in an open-source library. Other open questions: how many customers are behind the 56 projects, which authorities were notified, and why nobody noticed the attack for eight days. Mittwald promised a detailed report for the following week. As of November 9, it hadn't been published.

What affected customers should do now

If you have a Mittwald account, start by reading the FAQ and the status page and watch for emails from Mittwald, since affected customers are being contacted individually. If you used the MCP server, the FAQ says you should:

• change your mStudio password and turn on two-factor authentication,
• review API keys, project tokens and SSH keys and delete anything you don't recognize,
• renew credentials for databases, mail and external services stored in the project,
• look for traces: SSH users you didn't create, unfamiliar files in the project directory and unknown API keys.

Agencies can use Mittwald's template to inform their own clients and should check with each end customer whether they need to notify the data protection authority. The template mentions a 72-hour deadline for this and, where the EU's NIS2 directive applies, an initial report to Germany's federal cybersecurity agency BSI within 24 hours. What counts, though, is the law, not the template. If you never used the MCP server, the FAQ says you don't need to do anything, though two-factor authentication or the new passkeys are still recommended.

The big picture

This is one of the first publicly documented breaches through an MCP server at a major German host. It exposes a risk many providers are currently underestimating: if you connect AI assistants to admin panels, you create a new internet-facing interface that operates with users' full permissions. Sharma therefore recommends issuing tokens for such tool servers with short lifetimes and minimal permissions. Alarms should also go off when a freshly registered account makes suspicious calls within minutes.

Mittwald has communicated relatively openly and quickly, including an FAQ and a template for agencies. That deserves credit. Still, key technical details are missing, and the "AI attack" label hasn't been backed up so far. It also distracts from the real question: why didn't monitoring catch a week of test accounts, injection attempts and a break-in five minutes after a registration? Whether the promised final report will answer that remains to be seen.