Artificial Intelligence
What the Mittwald Breach Shows About MCP Server Security
In late October 2026, an attacker reached 56 customer projects, by Mittwald’s own count, at Mittwald, a German web host, through a flaw in a server Mittwald had built itself. The server was an MCP server, the piece that let customers connect an AI assistant to their hosting console. The attacker did not break the console. The attacker broke the connector standing in front of it, and the keys to the console passed through that connector.
That is the whole shape of the incident, and most of what MCP server security means, so it is worth sitting with before the detail. The credential that mattered was not taken from the system the customer logs into. It was read out of the adapter a team had added so an AI assistant could act on the customer’s behalf. One bug in that adapter was enough, because the session tokens it handled carried each connected customer’s full console rights. Whether the attacker read those tokens from storage or caught them as they passed through, Mittwald has not said.
This is a reconstruction of what happened, written from Mittwald’s own account and from the Model Context Protocol specification. It covers what the flaw was and was not, what Mittwald did right in the response, what would have made the same bug much smaller, and how to build an MCP server so that one flaw in it cannot reach all of your users. The vulnerability class has not been published. Where something is unknown, it stays unknown. And the incident is not over: on 12 November, Mittwald reported that the attackers had come back.
What an MCP server holds, and why that matters
The Model Context Protocol is a way for an AI assistant to call tools that live somewhere else. An MCP server exposes those tools. A client, which is the assistant, connects to the server, discovers the tools, and invokes them. When the tools do something real, the server has to call some other system to do it.
That other system is the part people skip. Mittwald’s MCP server was, in their own words, “eine Schnittstelle, über die Kunden ihr mStudio mit KI-Assistenten verbinden konnten” — an interface customers used to connect their mStudio hosting console to an AI assistant. The assistant does not talk to mStudio. The MCP server does, and to do that it needs a credential mStudio will accept.
So an MCP server that fronts an existing product ends up holding two kinds of credential, and the difference between them is the whole security question.
The first is the credential the assistant presents to the MCP server, proving it is allowed to call the server at all. The second is the credential the MCP server presents to the upstream system, proving it is allowed to act as a particular customer. In Mittwald’s case the second one was a session token for mStudio, and their FAQ states what it was worth: “Das Token erlaubte Zugriff auf dein mStudio mit deinen Rechten.” The token granted access to your mStudio with your rights. Not a reduced set of rights. Yours.
Hold that. A session token carries whatever the user can do. If the user can create accounts, change DNS, read databases and delete sites, the token can too. An MCP server that stores or relays those tokens has concentrated every connected customer’s full console access into one process. The blast radius of a bug in that process is not one request. It is every token the process can read.
The protocol specification has a position on this, and it is not ambiguous. The authorization security considerations for the current revision, dated 2026-07-28, say that if an MCP server calls upstream APIs it may act as an OAuth client to them, and that the token it uses upstream is a separate token, issued by the upstream authorization server. Then the requirement: “The MCP server MUST NOT pass through the token it received from the MCP client.” Two tokens, two issuers, two audiences. The assistant’s token is good only at the MCP server. The upstream token is good only at the upstream system, and the assistant never sees it.
The same page says clients and servers “MUST implement secure token storage,” and that authorization servers “SHOULD issue short-lived access tokens to reduce the impact of leaked tokens.” It also names the failure directly: “Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with requests that appear legitimate to resource servers.” A stolen token does not look like an attack. It looks like the customer.
None of that tells us what Mittwald’s server actually stored or how, because Mittwald has not published those internals. What they have published is the outcome, and the outcome is exactly the one that page describes.
What happened
Mittwald’s account comes from a post its founder and managing director, Robert Meyer, published on 7 November 2026, and from the company’s FAQ and status updates, read here as they stood on 12 November at 16:05. The two agree on the shape and differ in emphasis, and both are quoted here rather than blended. As of 13 November, Meyer’s post, like the rest of Mittwald’s blog, returns the company’s 404 page; on 12 November Mittwald reported that attackers had compromised its website. The quotations from the post here were taken before it went offline.
The week before, the PHP world was busy with something else. On 20 October two flaws in the PHP engine were disclosed. Mittwald’s Katharina Hoffmann wrote them up as PHP2Shell: remote code execution through faulty handling of out-of-memory conditions, and remote code execution through a stale reference to already-freed memory, tracked as CVE-2026-109618 and CVE-2026-109619. Her post scores both 9.2 under CVSS 4.0. This matters only because Meyer says the first probe of the MCP server happened the next evening, “im Schatten von PHP2Shell,” in PHP2Shell’s shadow. The two are separate bugs. The PHP flaws are memory corruption in the language runtime. The MCP flaw is something else entirely, and nobody outside Mittwald knows what.
On the evening of 21 October, Meyer writes, the attacker tested a weakness in the MCP server for the first time. From 23 October the attacker moved through the platform as an ordinary user, registering test accounts, using extensions, and making what Meyer calls “einfache Injection-Versuche,” simple injection attempts. Read that carefully. It describes what the attacker tried while pretending to be a normal customer. It is not a statement that the flaw they eventually used was an injection bug. No source, including Mittwald, has named the bug class. There is no CVE. The FAQ says only that the gap was in their MCP server.
On 27 October at 14:58 the attacker registered another account. At 15:03, Meyer writes, the attacker deliberately exploited the flaw found in the MCP server. Mittwald’s conclusion from the timing was to treat everything from 27 October onward as compromised. Meyer: “Wir behandeln alle Daten ab dem 27.10. als kompromittiert.”
Then eight days of quiet. The attacker was not idle during them, and Mittwald has explained why the activity did not stand out. The FAQ says the attacker deliberately disguised the preparations, using actions that looked like completely normal user behavior. That is a useful thing to publish, because it explains why detection took as long as it did, and the explanation is an uncomfortable one: the malicious activity was shaped to resemble the legitimate activity the system exists to allow.
On the morning of 4 November, Mittwald found it. Not because a customer reported something wrong. The FAQ is specific: “Am 04.11.2026 haben wir durch eigene Analysen festgestellt, dass es am 27.10.2026 einen unbefugten Zugriff auf unseren MCP-Server gab.” They established it through their own analysis. Meyer puts the first concrete action at 11:11 that morning, when they locked the attacker’s first account. By 12:53 they had a sense of the scope and set the status page to “investigation.” They took parts of their systems offline as a precaution, identified the MCP server as the entry point, and switched it off.
What the attacker got is stated plainly in the FAQ. No passwords were read. Session tokens were. “Es wurden keine Passwörter ausgelesen, sondern Sitzungs-Tokens.” And those tokens belonged to users of that one interface: “Dabei wurden Zugangsdaten (Tokens) von Nutzern dieser Schnittstelle ausgelesen.” Access credentials, tokens, of the users of this interface were read out. The FAQ also states the limit this implies. Only customers who had used the MCP server were affected, and Mittwald committed to emailing each of them personally. Everyone else, “nach aktuellem Stand,” as things currently stand, was outside the incident.
Meyer’s post gives the number the FAQ does not. “Wir haben 56 kompromittierte Projekte und den MCP-Server forensisch ausgewertet.” Fifty-six compromised projects, plus the MCP server itself, reviewed forensically. The Record, reporting on 9 November, carried that figure and added a caveat of its own: it is unclear whether the flaw sat in Mittwald’s code or in an open-source MCP library, and that uncertainty is The Record’s observation, not something Mittwald has said either way. Mittwald has simply not addressed it.
One claim needs to stay attributed, because it is an inference and Meyer marks it as one. He writes that the logs show the attacker moving through the system extremely fast, with only seconds between steps that would take a human considerably longer. “Das deutet auf die Verwendung von KI-Tools hin.” That indicates the use of AI tools. The verb is “deutet,” suggests, points toward. The Record’s headline, “Alleged AI-aided,” tracks that caution, and The Record notes that Mittwald has not explained how the timing was distinguished from ordinary scripts, which move just as fast. Speed in a log is evidence of automation. It is not, on its own, evidence of which kind.
By 12 November Mittwald’s wording had hardened. Its status update that morning described the attackers as “offensichtlich um professionelle Akteure …, die automatisierte KI-Systeme nutzen,” obviously professional actors who use automated AI systems. That is Mittwald’s own characterization, dated five days after Meyer’s “deutet,” and it still does not say how the timing was told apart from a script.
It came with bad news. “Nach den Vorfällen in der letzten Woche haben die Angreifer ihre Attacken auf unsere Infrastruktur wieder aufgenommen”: after last week’s incidents, the attackers had resumed their attacks on Mittwald’s infrastructure. “Bislang ist es den Angreifern gelungen, eine Sicherheitslücke auszunutzen und unsere Unternehmenswebseite zu kompromittieren.” So far they had exploited a security gap and compromised the company website. Overnight Mittwald had restricted SSH again, temporarily disabled registration of new mStudio users, and disabled login to mStudio and the customer center for some hours. That morning it switched off the customer center, mStudio and SSH as a precaution, and said it had found no access to its internal systems so far. Hosted websites and email stayed up. At 16:05 it expected to switch the customer center and mStudio back on by 11:00 the next day. The MCP server had stayed switched off since the first incident, and Mittwald has not said what the new gap was.
What Mittwald got right
The response deserves more space than the breach, because most of it was done well and done in public.
They found it themselves. Eight days is not a short dwell time, and Mittwald does not pretend it was. But the detection came from internal analysis rather than from a customer noticing a defacement or a leak, and that distinction decides what kind of incident you are running. An attacker discovered by the victim’s own monitoring is an attacker who has not yet had to make a mistake visible to the outside. Mittwald got there before that point.
They named the entry point the same day and removed it. Meyer writes that once they could identify the MCP server as the way in, they switched it off. The FAQ goes further and makes it a standing decision rather than a temporary one: “Der MCP-Server ist abgeschaltet und bleibt bis auf Weiteres offline.” The server is switched off and stays offline until further notice. Whether and in what form they offer the interface again, they say, will be decided after the investigation is finished. The command-line interface stays available as the alternative. Switching off a feature customers use, and declining to promise when it returns, is the correct call when you cannot yet say how the feature was broken.
They revoked the tokens, and they said so precisely. The FAQ states that no passwords were read, only session tokens, and that all of those tokens were revoked and are no longer valid. That is the remediation that matches what was taken. A session token is not a password, and changing the password does nothing to a token already issued. Then they asked for the rest. The FAQ’s list for affected customers says to change the mStudio password, turn on two-factor authentication, check the API keys, project tokens and SSH keys in their projects and delete unknown entries, and renew the credentials for third-party services stored in those projects, such as databases, mail and external APIs. Revoking the stolen credential and rotating everything it could have reached are two different jobs, and Mittwald asked for both.
They contained far more than the one server. Their status page shows them disabling mStudio login, ending SSH sessions and turning off extensions on 5 November, and orders and plan changes in the customer center were unavailable on 6 November. They also locked API keys as a precaution, which the FAQ states separately: “Im Zuge der ersten Gegenmaßnahmen haben wir vorsorglich API-Keys gesperrt.” The word “vorsorglich,” as a precaution, is doing real work. They did not have evidence the API keys were compromised. They locked them anyway, because the cost of locking a key is small and the cost of leaving a second credential type untouched while you are still learning the scope is not. That is the right ratio: close a door that is cheap to close, without waiting for proof that someone walked through it.
They drew a hard boundary around what was affected, and published it. Both the post and the FAQ say the customer center and the websites managed in it were never part of the incident. The FAQ adds that only customers who had used the MCP server were affected and that each of them gets a personal email. A customer who received no email and never set up the server is, “nach aktuellem Stand,” as things stand, not affected. And it sets the window plainly for anyone who did use it: “Der Server war ab dem 27.10. übernommen. Jede Nutzung danach gilt als potenziell kompromittiert.” The server was taken over from 27 October, and any use after that counts as potentially compromised. Defining the unaffected population is as important as describing the affected one. It is what lets every other customer stop wondering, and Mittwald did it early rather than letting everyone assume they were hit.
They brought in outside forensics and told the authorities. Meyer, in one sentence: “Externe IT-Forensiker unterstützen uns fortlaufend bei der Analyse. Die zuständigen Behörden haben wir informiert.” External forensic specialists were supporting the analysis on an ongoing basis, and the relevant authorities had been informed. He names neither the firm nor the authority, which is his prerogative. The decision to say that both happened is the part that counts.
They restored project by project, and they refused to restore blindly. The FAQ says each project is switched back on individually, once its security scan is complete, and that projects showing traces of the attacker stay offline. It also says something more. If Mittwald restores a project from backup, they will discuss with the customer which changes made since 27 October should be kept. Nothing happens without that conversation. A restore that silently discards two weeks of a customer’s work would have been the second incident, and they committed in writing not to cause it.
They looked for leaked data and reported the result without overclaiming it. A check of the usual platforms found no published data, the FAQ says, and they are still checking. “Wir prüfen das weiterhin.” We are still checking. That trailing clause is the difference between a finding and a reassurance. They published the finding and kept the investigation open in the same breath.
And they published a detailed account on the Saturday after detection, signed by the founder, with dates and times, while promising a fuller reconstruction once the analysis and the recovery were complete. As of 13 November that second account had not appeared, and the promise is outstanding. It is fair to weigh it against how much they had already put on the record within four days of detection.
Set all of that against what they were dealing with. A flaw whose class they have still not disclosed, an attacker who spent a week looking like a normal customer, and a credential type, the session token, that grants full console rights by design. The response did not make the breach small. Once tokens carrying full console rights were reachable through the connector, it was never going to be small. What the response did was stop the use of the stolen tokens, make the incident legible to customers, and avoid a second wave of damage of its own making, such as restores that silently discard a customer’s work. It did not end the attack. A week after detection the attackers were back, this time at the company website, and Mittwald was shutting its consoles again. Judged on the MCP incident it set out to contain, the response was a good one. Whether the containment held is a question the second wave reopened, and as of 13 November Mittwald had not answered it.
What would have made the same bug smaller
Nothing in the public record says the flaw was avoidable, because nothing in the public record says what the flaw was. So this section is not about preventing the bug. It is about the size of the bug. The question a designer can actually answer in advance is how much a flaw in the MCP server should be able to reach.
Start with what was taken. Session tokens, for an interface whose whole purpose was to act as the customer. A session token is a poor credential to hand to a server that exists to be called by third-party software. It lives a long time, it carries the user’s full rights, and it is generally not bound to the client that presents it. Anyone who reads it out of the server, whether from storage or in transit, can replay it and look exactly like the customer. The specification’s own security considerations describe that outcome in so many words. Mittwald has not said which of the two happened, and for the design question it does not matter: a server that never receives the console token cannot leak it either way.
The specification also describes the arrangement that avoids it, and the requirement has been in the document since the 2025-06-18 revision. The MCP server calls the upstream system as its own OAuth client, with a token issued to it by the upstream authorization server, for the upstream system as its audience. The token the assistant presents is a different token, issued for the MCP server and for no one else, and the server must not accept or forward any token that was not issued for it. The assistant never possesses the upstream credential. The upstream system never accepts the assistant’s token.
Applied to a hosting console, that arrangement has a specific shape.
The console session token stays in the console. It does not move to the MCP server, and it certainly does not move to the assistant, to a tool argument, or to a tool result. What the MCP server holds instead is a credential issued to the MCP server itself, scoped to the one customer and to the operations the assistant is actually meant to perform, with a short lifetime. OAuth 2.1 recommends short-lived bearer tokens because they “can reduce the impact of them being leaked.” The MCP specification adopts that as a should, and it states no number, so there is no mandated lifetime to hide behind. The principle is the point. A token that dies in minutes turns a theft into a race.
Audience binding does the next piece of work. A token whose audience is the MCP server is worthless at the console, and a token whose audience is the console is worthless anywhere else. The specification makes the check mandatory in both directions: clients must say which resource they want a token for, and servers must reject tokens that were not issued for them. A token that is good everywhere is a token that rewards the attacker for finding the weakest holder of it.
Sender binding does the last piece. A bearer token is replayable by anyone who holds it, which is why reading one, from a database or off the wire, is enough. A token bound to a key the caller must prove it holds, whether by mutual TLS or by DPoP as RFC 9700 recommends, is not replayable by someone who only copied the string. That recommendation is a should, not a must, and it is worth saying so. It is also the control that most directly answers a stolen bearer token, where possession of the string is the whole attack.
None of this is a claim about what Mittwald built. They have not published the internals, and The Record is right that it is not even established whether the flaw was in their code or in a library. The point is narrower and more useful. The protocol specification, as it stood months before this incident, already required the separation that would have kept a customer’s console session token out of the MCP server entirely. A server built to that requirement, and to the shoulds beside it, can still be broken. A flaw in it reaches the short-lived, narrow, audience-bound credentials the server holds for the users it holds them for. It does not reach every customer’s full console session, because the server never had those.
There is a second requirement that bears on a server sitting in front of an existing logged-in product, and it is the confused deputy rule. An MCP server that connects assistants to a third-party system while acting as one OAuth client to that system, with a single static client identity, can be tricked into authorizing an attacker’s client on the back of a consent the user already gave. The specification’s answer is mandatory: a proxy server using a static client ID must obtain the user’s consent for each dynamically registered client before it forwards anything to the upstream authorization server, and it must not record that consent until the user has actually approved it. A prior login to the console must not skip that second consent. Whether this played any role at Mittwald is unknown. It is the other door in the same wall, and a server that fronts an existing product has both doors.
How to build the server so one flaw cannot reach everyone
The controls below are the ones the specification and the OAuth standards actually state. Each one says how strong the requirement is, because a should and a must are different promises, and an article that flattens them is lying to the engineer reading it.
Keep the upstream credential out of the server’s hands where you can, and never store the user’s real session. When the server calls an upstream system it acts as its own OAuth client, and the token it uses there is a separate token issued by that system’s authorization server. The specification states this as a prohibition: the server must not pass through the token it received from the client. The user’s console session stays with the console.
Where the server must hold a credential, hold one you issued for the purpose. OAuth token exchange, RFC 8693, exists so a caller can ask for a token usable at one specific service rather than reusing the token it already has, and it warns that delegating one party’s rights to another is exactly where abuse creeps in. The mitigation it points to is scope plus a short lifetime. Be honest about the provenance, though. The MCP specification does not cite RFC 8693 for this step. It is the applicable standard for the upstream leg, and it is an engineer’s mapping, not a line in the protocol. Treat it as guidance, not as compliance.
Make every token short-lived. OAuth 2.1 says authorization servers should issue short-lived bearer tokens, and names leaked tokens as the reason. The MCP specification repeats it as a should. No document states a number of minutes. Pick a lifetime short enough that a token stolen at noon is dead before anyone finishes triaging the alert, and accept the operational cost of refresh.
Bind every token to its audience, and reject anything else. Clients must name the resource they want a token for. Servers must validate that a presented token was issued for them and reject it otherwise. Both are musts in the current specification. A token accepted by more than one service means a compromise of the weakest service is a compromise of all of them.
Constrain the sender where you can. RFC 9700 recommends sender-constrained tokens, through mutual TLS or DPoP, so that copying the token string is not enough to use it. This is a should. It is also the control that turns a database read into a dead end instead of a breach.
Scope each credential to one user and the minimum that user needs. RFC 9700 says the privileges on a token should be restricted to the minimum the case requires, because that limits the damage when a token leaks. The MCP security best practices page is blunter about the failure mode. It describes an attacker who obtains, through log leakage, memory scraping or local interception, a token carrying every scope, granted up front because the server advertised every scope and the client requested all of them. Its prescribed shape is a small initial scope with narrow, explicit elevation when a task needs more, and it names wildcard scopes as a mistake. The same family’s local-server guidance says to issue each server its own token with the smallest scope that works, so a leak is contained and revocable, and never to reuse one broad token across servers.
Do not use one shared credential for everyone. A static credential is the organization’s credential, not a person’s. Anthropic’s own connector documentation makes the point for server authors: every member’s requests carry the same key, so the key cannot tell you which user is calling, and a tool that must act as an individual user has to use per-user OAuth instead. A shared credential makes the blast radius equal to everyone the credential can reach, and no per-request check recovers that once the credential itself is what leaked. Where the server sits matters for the same reason: put the MCP server behind your API gateway, so its traffic is throttled, metered and logged like every other consumer’s.
Treat revocation as necessary and insufficient. RFC 7009 requires support for revoking refresh tokens and recommends support for revoking access tokens, and it says the quiet part in its security considerations: the specification does not intend to provide countermeasures against token theft and abuse. Revocation helps after someone notices and acts, it propagates with some delay, and a self-contained token validated by signature keeps working until it expires no matter what the authorization server has revoked. The short lifetime is what caps the damage in the window revocation cannot close. This is precisely why Mittwald’s revocation worked as damage control and would not have worked as design. They revoked every token, and they could, and that stopped further use. The tokens had already been read.
Bind server-side state to the authenticated user. The current specification dropped protocol-level session identifiers and replaced that guidance with a rule about state handles: a server must not treat possession of a handle as authentication. Key stored state to the user identity you derived from a verified token, not to anything the caller presents.
Take your own consent, and do not inherit it. If your server fronts another system’s API with a static client identity, the specification requires you to obtain the user’s consent for each registered client before forwarding to that system’s authorization server, and to record that consent only after the user approves it. The upstream system’s memory of a prior login is not your consent decision. Skipping this is the confused deputy, and the specification has required the fix since June 2025.
Anthropic’s own engineering account of how it contains Claude, published in May 2026, is a useful picture of the same ideas carried through. Credentials stay in the host keychain. The sandboxed environment gets a per-session token that is scoped down and can be revoked on its own, independently of the user’s real credentials. And the stated reason is the one that survives every other argument: if the credentials never enter the environment that runs the agent’s code, they cannot be exfiltrated, regardless of whether the cause is the user, the model finding an inventive path, or an attacker. That is a vendor describing its own product, not a neutral standard, and it belongs in that frame. It is also the cleanest statement available of the design goal. The credential an attacker most wants should be the one your server never holds.
The other way tokens leave
Everything above is about a flaw in a server. There is a second path that needs no flaw in anything, and conflating the two produces bad advice.
In the second half of 2026, infostealer malware was reported collecting the credential files that AI coding tools keep on disk. SpyCloud reported on 30 October that it had seen more than 130,000 WardenStealer infections since August 2026, and that Claude Code’s OAuth credential file in recovered logs held access and refresh tokens plus tokens for connected MCP servers. Symantec’s threat hunters reported on 15 October that a stealer called Aoki, which they detect as Infostealer.Aoki, had added AI tooling to its target list and was taking credential, token and session files for Claude, Codex, GitHub Copilot, Cursor, Google Gemini, JetBrains AI Assistant and Kiro. Aoki does not exploit a vulnerability. It reads files off a machine that is already compromised, and it has no backdoor command list. It collects and it leaves.
Two limits belong next to those numbers, because both sources state them. SpyCloud counts infections found in recaptured logs, not confirmed compromised accounts, and it says outright that it cannot confirm all of the material being sold came from infostealer malware. Symantec’s report does not mention MCP at all. The connection between stolen local files and MCP tokens specifically is SpyCloud’s finding, and it should travel with SpyCloud’s name on it.
The reason to include this at all is the contrast. No amount of care in your MCP server protects a token that a customer’s assistant stores in a file on the customer’s laptop, and no flaw in your server is required for that token to leave. The protocol’s own local-server guidance draws the line cleanly. The protocol threat model and the machine threat model are different, and the second one is governed by how the process runs, not by the specification: per-server credentials instead of one broad token exported into the environment, and the operating system’s secret store instead of a predictable file on disk. A token that is short-lived, audience-bound and sender-constrained limits the damage here too, which is the one control that earns its place in both threat models. Theft of one machine should yield one user’s credentials for a few minutes, not a reusable session for everything that user can touch.
What this asks of a team running AI tools
The tempting conclusion is that MCP servers are dangerous and a team should avoid them. That is the wrong conclusion, and it is the one that produces the worst outcome, which is engineers connecting assistants to production systems through whatever ad hoc path is handy because the sanctioned path got shut down.
Mittwald’s connector existed because customers wanted their AI assistants to reach the hosting console. That demand is not going away, and a team that refuses to build the connector does not eliminate it. The access moves somewhere less visible, into personal access tokens pasted into config files and scripts nobody reviewed. The safer position is to build the connector and to treat it as what it is: a new privileged component, sitting between an assistant and a production system, holding credentials that grant real rights.
That framing changes what the review looks like. The questions worth asking about an MCP server are not whether the model is good. They are which credentials the server holds, how long they live, whose they are, what a bug in the server could read, and how fast a revocation actually takes effect at the system those credentials open. They are the same questions an IT team already asks about any service account, and the specification gives unusually direct answers to them. The review belongs with the people who already govern service accounts, and it belongs before the server is turned on, not after the first incident.
This is the part of AI work that does not show up in a demo. Taking an assistant from a prototype to something that runs against real systems means naming, up front, what it can reach, what credential it uses to get there, and what happens when that credential leaks. The teams that do this well are not the ones with the cleverest integration. They are the ones that decided the blast radius before anyone asked them to.
If that decision is the one sitting in front of your team, we do this work with the security, the support and the running cost named before the build starts, and we do it alongside an IT team that already has a roadmap. The same gap, between software that works and software that is safe to run, is the subject of an earlier piece on AI-built applications. The connector is one more place it shows up.
Sources
Everything quoted above comes from one of these. Dates are the publication dates, except where a page is cited as it stood on a given date.
- Robert Meyer, “Sicherheitsvorfall am MCP-Server,” Mittwald blog, 7 November 2026. Offline as of 13 November 2026, after Mittwald’s website was attacked on 12 November; no archived copy was found, so it is not linked.
- “MCP-Server: Was du jetzt wissen musst,” Mittwald FAQ and status updates, as they stood on 12 November 2026, 16:05. mittwald.de/lp/mcp-faq
- Katharina Hoffmann, “PHP2Shell erklärt,” Mittwald blog, 22 October 2026, for CVE-2026-109618 and CVE-2026-109619. Offline as of 13 November 2026, after Mittwald’s website was attacked on 12 November; no archived copy was found, so it is not linked.
- Alexander Martin, “Alleged AI-aided cyberattack exploits assistant interface to breach German web host,” The Record, 9 November 2026. therecord.media/cyberattack-germany-ai-mittwald
- “Authorization,” Model Context Protocol specification, revision 2026-07-28. modelcontextprotocol.io
- “Authorization Security Considerations,” Model Context Protocol specification, revision 2026-07-28. The token-passthrough prohibition, the secure-storage requirement, and the short-lived-token guidance are on this page. modelcontextprotocol.io
- “Security Best Practices,” Model Context Protocol, revision 2026-07-28. The scope-minimization failure mode and the confused-deputy rule are here. modelcontextprotocol.io
- “Authorization” and “Security Best Practices,” Model Context Protocol specification, revision 2025-06-18, for when the token-passthrough prohibition and the confused-deputy consent rule entered the specification. Authorization, Security Best Practices
- “The OAuth 2.1 Authorization Framework,” draft-ietf-oauth-v2-1-13, May 2025. Section 7.1.3.5 covers short-lived bearer tokens. datatracker.ietf.org
- RFC 9700, “Best Current Practice for OAuth 2.0 Security,” January 2025. Section 2.2.1 covers sender-constrained tokens and section 2.3 covers least privilege. rfc-editor.org/rfc/rfc9700
- RFC 8693, “OAuth 2.0 Token Exchange,” January 2020. The MCP specification does not cite this for the upstream leg, and the article says so. rfc-editor.org/rfc/rfc8693
- RFC 7009, “OAuth 2.0 Token Revocation,” August 2013. Section 5 states that revocation is not a countermeasure against token theft. rfc-editor.org/rfc/rfc7009
- “How we contain Claude across products,” Anthropic Engineering, 25 May 2026. anthropic.com/research/how-we-contain-claude
- “Authentication for connectors,” Anthropic. claude.com/docs/connectors/building/authentication
- Trevor Hilligoss, “Infostealers Now Target AI Tokens and API Keys,” SpyCloud, 30 October 2026. spycloud.com
- “Aoki infostealer targets AI coding assistant credentials,” Symantec Threat Hunter Team, 15 October 2026. security.com
Newsletter
Subscribe to newsletter
Subscribe to receive the latest blog posts to your inbox every week.
