German web host Mittwald says an attacker abused a flaw in its AI assistant interface, harvested customer session tokens and reached 56 hosted projects before anyone noticed. The eight-day gap between exploitation and detection is the part every UK SOC and hosting provider should study.
What happened
Mittwald CM Service, a hosting company in North Rhine-Westphalia that serves web agencies, published its account of the incident on 7 November 2026. Its founder and managing director, Robert Meyer, said the way in was the company’s Model Context Protocol (MCP) server. This service let customers connect AI assistants to mStudio, Mittwald’s control panel for websites, containers and hosting.
Mittwald’s timeline puts the first probe of the MCP weakness on 21 October, an evening when defenders everywhere were preoccupied with PHP2Shell patching. From 23 October the intruder used the platform like an ordinary customer: opening test accounts, trying extensions and making basic injection attempts. On 27 October they registered one more account at 14:58 and exploited the MCP flaw at 15:03.
Mittwald noticed unusual behaviour on the morning of 4 November and locked the attacker’s first account at 11:11. Over the next two days it shut down the MCP server and quarantined projects that showed traces of the intruder. It also suspended mStudio logins, SSH access, its extensions, new sign-ups and orders, and brought in external forensic specialists. By 6 November it had examined 56 compromised projects and found no further ones in repeat scans. mStudio and SSH came back on 7 November, now with passkey support. The quarantined websites stayed blocked and the MCP server remains offline until further notice. The company says it has informed the relevant authorities, and on 7 November it promised a fuller write-up the following week.
The technical picture
Mittwald has not said what kind of flaw it was. The Record notes it is not yet known whether the bug lives in Mittwald-written code or in the underlying open-source MCP libraries. What is clear from the company’s FAQ is the impact. The attacker read session tokens belonging to customers who had used the MCP server. No passwords were taken. Each token carried its owner’s rights in mStudio, so a single stolen token opened every project that customer could reach.
That is the core problem with an MCP bridge on a management platform. It is a long-lived, privileged integration point that holds credentials on behalf of many users, and it often gets less scrutiny than the main login page. Compromise the bridge and you inherit the trust of everyone who connected to it, with no failed logins to trip an alert.
Meyer says the logs show the attacker moving very fast, sometimes only seconds between steps that would take a person far longer, and the company reads this as a sign of AI tooling. That is Mittwald’s interpretation. The Record pointed out that conventional scripts also outpace a human operator, and Mittwald has offered no other evidence of AI use. The intruder also laid decoys that initially distracted its analysts, the firm says.
Mittwald now treats all MCP server use from 27 October as potentially compromised. It has revoked every token, blocked API keys as a precaution and is emailing affected customers individually. It says its separate Kundencenter platform was untouched and no customer data has surfaced online.
Why it matters for UK organisations
UK hosts, managed service providers and SaaS vendors are rushing out MCP endpoints so customers can drive their platforms from AI assistants. Mittwald’s experience shows what that can mean in practice: a new, internet-facing, credential-holding component, bolted onto the control plane, that may not have gone through the threat modelling and monitoring the main product gets.
The downstream effect matters too. Mittwald serves agencies, and the agencies serve their own clients. A UK digital agency hosting client sites on a platform like this would face the same questions. That includes whether personal data in those projects was accessed and whether the 72-hour ICO reporting clock under UK GDPR has started. The Cyber Security and Resilience Bill will bring many managed service providers into regulatory scope, so expect incident timelines like this one to come under more formal scrutiny.
Then there is the dwell time. Eight days is short by historical standards, but the attacker spent about a week rehearsing in plain sight as a registered user before striking. Behaviour that looks like a curious new customer will rarely trip a rule-based alert.
Expert view
When we test platforms with new integration layers, the AI connector is increasingly where the interesting findings are. It is often built quickly by a product team, handles tokens in ways nobody has fully mapped, and may not log to the SIEM at all. I would not be surprised if Mittwald’s eventual write-up shows the MCP service had weaker logging and fewer controls than mStudio itself. That pattern is common.
The reconnaissance phase is the lesson I would underline for SOC teams. Test accounts registered in quick succession, unusual extension use and low-grade injection attempts from new tenants are all observable signals. Alone they look like noise; correlated by source, fingerprint or payment details, they tell a story. Most hosting SOCs I have seen alert well on things breaking, but far less well on new customers behaving oddly.
I would treat the AI attribution with care. Fast, scripted intrusion is not new, and calling it AI does not change the defensive response. What counts in Mittwald’s favour is fast, timestamped public communication and a clear line on what to treat as compromised. In my experience customers value that above a polished root cause.
What to do now
- Inventory every MCP or AI connector you expose or consume. Include vendor-hosted ones your staff have connected to corporate accounts. Treat each as a privileged integration (Cyber Essentials: secure configuration, user access control).
- Cut token lifetime and scope. MCP-issued tokens should be short-lived, scoped to the minimum actions needed and bound to the client where possible.
- Log token use, not just logins. Alert when one token is used from a new IP range or ASN, touches projects its owner rarely uses, or moves through actions at inhuman speed.
- Watch new tenants. Correlate rapid account creation, extension abuse and injection attempts across accounts that share infrastructure or payment details.
- Get connector logs into the SIEM. If the MCP service writes logs nobody reads, it is a blind spot.
- Patch and test the connector like an external service (Cyber Essentials: security update management). Put it in scope for your next penetration test.
- If you are a Mittwald customer, follow its advice. Change your mStudio password, turn on two-factor authentication or a passkey, review API keys, project tokens, SSH keys and SSH users, and rotate database, mail and third-party API credentials stored in affected projects.
Bottom line
Mittwald’s breach is small by numbers but an early, well-documented example of an AI integration layer becoming the way into a hosting control plane. Any UK organisation that has shipped or connected an MCP server in the past year should assume it is now on attackers’ target lists. Check that it is monitored as closely as the front door.
One thought on “Mittwald MCP server breach went unseen for eight days: IR lessons”
Comments are closed.