AI and security briefsSecurity

Was Mittwald breached by an AI-aided attack through its MCP server, and what should I do?

By Brandon Da Costa, founder of Digiton Dynamics

Published 9 November 2026Updated 9 November 2026Editorial policy

Mittwald, a German web host, says an attacker used a flaw in its MCP server to read customer session tokens on 27 October 2026, and that 56 projects were compromised. The company thinks the attacker used AI tools because of how fast the steps came. It offered no other evidence, so treat the AI claim as alleged.

Who should act: Mittwald customers who ever connected an AI assistant to mStudio, and any team that exposes an MCP server or tool-calling assistant to customers.

What happened

Mittwald's managing director Robert Meyer wrote on 7 November that the attacker first tested a weakness in the MCP server on the evening of 21 October, while the industry was busy with PHP2Shell. From 23 October he acted as a normal user, registering test accounts and trying simple injections. On 27 October at 14:58 he registered another account, and at 15:03 he used the gap. Mittwald treats all data from that date as compromised (Mittwald blog, 7 November).

The MCP server let customers connect AI assistants to mStudio, Mittwald's hosting control panel. According to Mittwald's FAQ, the attacker read session tokens, not passwords, and those tokens gave the user's own rights over every project the user could reach. The company noticed on 4 November, blocked the first attacker account at 11:11, shut the MCP server and revoked the tokens. It then closed mStudio login and SSH on 5 November, and reopened them on 7 November. Some sites stay blocked. Mittwald says it informed the relevant authorities and uses external forensic experts.

On AI, Meyer says the logs show "only seconds" between steps that would take a human longer. The Record (9 November) notes Mittwald gave no other evidence and did not say how it tells AI tooling from fast scripts. It also says it is unclear whether the flaw is in Mittwald's code or an open-source MCP library, while the FAQ says the gap lay in its own MCP server. The Record's "eight days" matches 27 October to 4 November. Mittwald's own timeline starts probing six days earlier. I found no statement from an authority. Mittwald promises a fuller account next week.

Who is affected

• Customers who set up the MCP server. Mittwald says each of them gets a personal email, and any use after 27 October counts as potentially compromised.
• Customers who never used it. Mittwald says they are not affected on current information, but they were still locked out of SSH and mStudio for a while as a precaution.
• Agencies, because one stolen token reached every project that user managed. Mittwald says the customer centre and the sites it manages were never touched.
• Anyone else shipping an assistant interface. The reported flaw sits in the MCP server, not in an AI model.

What to do now

1. If you used Mittwald's MCP server, follow its list: change your mStudio password, switch on two-factor authentication, review API keys, project tokens and SSH keys and delete unknown ones, then renew every third-party credential stored in your projects, such as databases, mail and external APIs.
2. Look for what Mittwald names as warning signs: SSH users you did not create, unknown files and API keys nobody on your team made.

   find . -type f -newermt '2026-10-27' -not -path './.git/*' | head -50
   cat ~/.ssh/authorized_keys

3. On your own assistant interfaces, list every MCP server and tool endpoint, who can reach it and which token it uses.
4. Issue short-lived tokens limited to one project and one action set, and never let a session token double as a tool credential. See the MCP security guide.
5. Log each tool call with user, token and timing, and alert on odd sequences, such as a new account chaining many calls in seconds.
6. Build a switch that turns off the assistant interface alone and a runbook that revokes every issued token. Test the interface with the tools listed in AI red teaming tools before customers do.

What should have been in place

• Token scoping and expiry, so one stolen token does not open every project.
• Monitoring tuned to machine-speed behaviour from newly registered accounts.
• An MCP server treated like any public API, with input validation and its own review.
• A kill switch for the assistant interface that leaves the rest of the platform running.
• Fast patching, since the first probe came the evening of a global PHP2Shell patch scramble.

Questions people ask

Digiton's production review traces which tokens and keys each integration holds and what a stolen one could reach, and the checks it runs are on the vibe coded app audit page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

1. Mittwald blog by Robert Meyer, security incident at the MCP server, 7 November 2026, read 9 November 2026. https://www.mittwald.de/blog/mittwald/sicherheitsvorfall-am-mcp-server
2. Mittwald MCP incident FAQ, read 9 November 2026. https://www.mittwald.de/lp/mcp-faq
3. The Record, report on the alleged AI-aided attack on a German web host, 9 November 2026, read 9 November 2026. https://therecord.media/cyberattack-germany-ai-mittwald
4. Mittwald status page, read 9 November 2026. https://status.mittwald.de/

More briefs

How these briefs are sourced and corrected. All AI and security briefs