After the Mittwald Hack: How Nine Hosts Secure Their AI Interfaces

What this is about

More and more web hosts let AI assistants like Claude, ChatGPT or Cursor directly manage websites, domains and servers. They do it through the Model Context Protocol (MCP), an open standard that lets an AI operate external services as tools. At Mittwald, a hosting provider based in Espelkamp, Germany, this exact interface opened the door to attackers.

Our thesis: the problem is less a single bug in the code than the architecture. A central remote MCP server, meaning a service run by the provider that all customers go through, collects many customers' access keys in one place. A local MCP server, by contrast, runs on your own machine and only knows your own, tightly scoped token. Using public documentation, we compared how nine offerings are built. We checked whether they run remotely or locally, how authentication works, whether permissions can be restricted, whether there's a read-only mode, when tokens expire, and whether agent actions are logged. We did not run any attack tests of our own.

What happened at Mittwald

According to Mittwald's FAQ and a report by webhosting.today, the attack unfolded like this:

• October 21: The attacker tests the flaw in the MCP server and creates test accounts.
• October 23: They move through the platform like a normal user, try out extensions and attempt simple injection attacks designed to execute smuggled-in commands.
• October 27: They register another account, exploit the flaw five minutes later and read out MCP users' session tokens.
• November 4: Mittwald notices unusual behavior and shuts down the MCP server.
• November 5 to 7: mStudio login, SSH, extensions and orders are locked. External forensic investigators examine 56 compromised projects, after which mStudio goes back online.

So 14 days passed between the first test and detection, and the actual exploitation went unnoticed for eight days. A session token is a digital ID that's valid after login. Whoever has it needs neither the password nor a second factor. According to webhosting.today, each stolen token carried its owner's permissions, meaning it worked on every project that customer could reach. Whether the flaw was in Mittwald's own code or in an open-source MCP library is still unclear, according to The Record. CEO Robert Meyer's claim that the attacker used AI rests solely on the speed seen in the logs; he gave no other evidence.

Overnight into November 12, Mittwald was attacked again. According to its status page, the attackers compromised the company website through a security flaw. The customer center, mStudio and all SSH connections were shut down again. Mittwald says it found no access to internal systems. How the attackers got in this time hasn't been disclosed; after all, the MCP server had been offline since November 4. According to the latest status page entry, SSH and mStudio are running again, and the customer center was due to follow on November 13 around noon. Mittwald has promised a detailed report. The MCP server stays offline until further notice.

Good rules, wrong place

On paper, Mittwald's integration was well built. The developer docs describe OAuth 2.1 with PKCE: you log in in the browser, grant specific permissions, and the tool gets a token instead of your password. Access tokens expired after about an hour, while refresh tokens (longer-lived keys used to obtain a new access token) lasted for "days." The default scopes, meaning the granted permissions, were read-only: user:read customer:read project:read app:read.

The architecture behind it is the interesting part. According to the project description on Glama, the service consists of the MCP server and an OAuth bridge that share a managed Redis store for state and sessions. The MCP server executes commands via Mittwald's command-line tool mw. A proxy like this necessarily manages the sessions of every connected customer. The GitHub repo mittwald/mcp-server, which directories link to, was unreachable when we checked on November 13 (error 404).

The MCP specification is aware of these risks. It warns about the confused deputy problem: a proxy acting on behalf of many users can be tricked into passing one user's permissions to someone else. Proxy servers must therefore obtain separate consent for each client. The spec also says MCP servers must not accept tokens that weren't explicitly issued for them. This year's vulnerabilities show how fragile this pattern is in practice. The widely used FastMCP library had exactly this kind of confused deputy bug in its OAuth proxy up to version 3.2.0 (CVE-2026-27124, "high"). In the official TypeScript SDK, according to the security advisory, a malicious server could grab stored refresh tokens (CVE-2026-104850, fixed in 1.31.0).

Our assessment: short lifetimes and narrow scopes limit the damage a single token can do. But they don't help much if all the tokens sit in one place that's reachable from outside. Then a single bug decides the fate of every customer at once.

The comparison

What the table shows

IONOS Cloud is the cleanest. The ionoscloud-mcp server runs locally and talks to the IONOS API directly. According to the FAQ, it's read-only by default. Write tools for Compute Engine and Kubernetes are only registered once you set IONOS_MCP_TOOL_SCOPE to write or destructive. Until then, the AI can't even see them. Creating and deleting happen in two steps: first you get a preview with a one-time code that expires after five minutes. The docs recommend a dedicated token with an expiry date, ideally for a restricted sub-user. There's one catch: according to the README, the optional HTTP mode has no authentication of its own.

IONOS Hosting has handled domains, DNS, SSL, web hosting and servers via "one token" since August. According to the blog, write actions are meant to require explicit approval, be logged and be limited to the token's scope. The post doesn't say whether the service runs locally or remotely, and IONOS describes audit trails only as a goal.

The remote providers differ widely. Cloudflare lets you choose permissions during the OAuth login. According to the README, its underlying library stores tokens, codes and secrets only as hashes, meaning irreversible fingerprints. The actual credentials are encrypted with a key that only the token holder can decrypt. A stolen copy of the store is therefore of little use. That makes the central architecture far more robust. Vercel only allows approved clients and requires consent for each connection. At the same time, Vercel itself writes:

Connecting to Vercel MCP gives the AI system you're using the same access as your Vercel user account.

Since July, the service can also deploy. At Hostinger, according to the docs, an API token inherits the permissions of the user who created it, and the expiry date is optional. Netlify provides no information on scopes or lifetimes at all.

Local doesn't automatically mean secure. In the community projects, the token usually sits in plain text in the client configuration. netcup-mcp isn't affiliated with netcup and can shut down servers, delete snapshots and call any API endpoint through a generic tool. It leaves confirmations up to the AI client. Hostinger's own README warns against starting the server via npx, because a cloned repository could otherwise run its own code with your Hostinger credentials. The MCP specification devotes a separate chapter to local servers, since they run with the user's permissions. One advantage at Hetzner: the API issues tokens per project with "Read" or "Read & Write." A "Read" token can only make GET requests, meaning it can only query. That limits the damage on the provider side, no matter what the MCP server does.

Hardly anyone logs what the agent does. Apart from IONOS, no provider documents a log of agent actions. At Mittwald, that was exactly where the attack could have been caught.

The pattern isn't limited to web hosts. At AI provider Fireworks, according to Notion, chat histories containing pasted API keys were exposed in an attack. Notion revoked the affected keys on November 11. At Railway, attackers decrypted centrally stored environment variables. And this week's Microsoft 365 outage knocked out Claude's connectors for hours. Wherever lots of keys or dependencies converge, outages get bigger and the loot gets more attractive.

Checklist for agencies and shop owners

1. Take inventory: List all AI integrations, API tokens, project tokens and SSH keys, and delete anything you can't account for.
2. One token per agent and project: Never use the main account's token. Agencies shouldn't hang all client projects off a single user that the agent also works with.
3. Read-only by default: Grant write permissions only temporarily and only for the product that actually needs changing.
4. Set an expiry date: Never "unlimited." IONOS recommends around 24 hours for one-off queries.
5. Store tokens properly: Not in shared configs or repos; use your operating system's keychain instead. Launch local servers via a fixed path and keep MCP libraries up to date.
6. Keep confirmations on: Don't disable your AI client's confirmation prompt for write actions.
7. No secrets in chats: Whatever you paste into an AI chat can end up with the provider or its suppliers.
8. Have an incident plan: Check whether a token can be revoked in one step, keep backups outside your host, and prepare messages for your customers. Mittwald has published templates for this.

Our verdict

Mittwald had OAuth, short-lived tokens and read-only default permissions, a lot of what security guidelines call for. Yet a single flaw in one central place was enough to hit 56 projects. Our assessment: architecture determines how big the damage can get. For agencies and shops, a local server with a tightly scoped, time-limited token is currently the more robust choice. But it shifts responsibility onto your own machine. Remote services can be built far more securely with encrypted token storage like Cloudflare's; whether hosts actually do this usually isn't visible in their docs. What exactly went wrong at Mittwald is still unclear. Only the promised incident report will show whether the flaw was in its own code or in a library.