MCP-SDK: Update allein reicht nicht

Wer einen eigenen MCP-Server in TypeScript betreibt, sollte sich diese Woche eine Stunde dafür nehmen. Am 20.10.2026 hat das Projekt fünf Sicherheitshinweise zum offiziellen TypeScript-SDK veröffentlicht. Gepatchte Versionen gibt es. Bei drei der fünf Lücken ändert das Update allein aber nichts, ihr müsst zusätzlich euren eigenen Code anfassen.

Betroffen sind Server, die über HTTP erreichbar sind, und eine der Lücken trifft Anwendungen, die als Client einen Server über HTTP ansprechen. Reine stdio-Server, wie sie die meisten lokal in Claude Code oder Cursor einbinden, sind laut den Advisories nicht betroffen.

Die fünf Lücken im Überblick

Die Paketnamen sind abgekürzt: sdk ist @modelcontextprotocol/sdk (die 1.x-Linie), server und client sind die 2.x-Pakete unter demselben Scope. Inzwischen ist bereits Version 2.4.0 erschienen (23.10.).

Antworten an den falschen Client

Die schwerste Lücke ist auch die, an der am meisten Code hängt. MCP ordnet Antworten über die JSON-RPC-ID der Anfrage zu. Die SDK-Clients zählen diese IDs bei 0 beginnend hoch. Zwei Clients schicken also ganz normal beide eine Anfrage mit ID 0, 1, 2 und so weiter. Teilen sie sich auf dem Server eine Transport- oder McpServer-Instanz, konnte das SDK die Antwort für Client A an Client B ausliefern. Je nachdem, was eure Tools zurückgeben, sind das Kundendaten, interne Dokumente oder Ergebnisse, die nur einer sehen soll.

Betroffen seid ihr laut Advisory, wenn mehr als ein Client euren HTTP-Endpunkt erreicht und euer Code den Transport oder den Server einmal beim Start anlegt statt pro Anfrage oder pro Session. Ausgerechnet dieses Muster stand bis zum Fix in den README-Beispielen der offiziellen Middleware-Pakete für hono, express, fastify und node. Wer sich daran orientiert hat, hat die Lücke wahrscheinlich übernommen. Die READMEs sind inzwischen korrigiert, das Beispiel legt jetzt pro Anfrage einen eigenen Server samt Transport an.

Nach dem Update auf 2.3.0 verweigert das SDK das Teilen. Ein zweites connect() schlägt mit ALREADY_CONNECTED fehl, ein zustandsloser Transport lehnt die zweite Anfrage ab. Ein betroffener Server funktioniert nach dem Update also erst einmal nicht mehr. Das ist gewollt, aber ihr solltet es vor dem Deployment wissen. Drei Umbauten bietet das Advisory an:

• createMcpHandler() mit einer Factory, die bei jedem Aufruf einen neuen McpServer baut
• pro Anfrage einen neuen McpServer und einen neuen Transport im Request-Handler anlegen
• pro Session einen sessionIdGenerator setzen und je Session genau einen Server und einen Transport halten

Der Umbau schließt die Lücke auch auf den alten Versionen. Nicht betroffen sind stdio-Server und die 1.x-Linie ab Version 1.26.0.

Tokens für den falschen Empfänger

Bei der zweiten Lücke geht es um OAuth. Stellt euer Autorisierungsserver Tokens für mehrere Dienste aus, hat das SDK bisher nicht geprüft, ob ein Token wirklich für euren MCP-Server bestimmt war. Ein gültiges Token für irgendeinen anderen Dienst in eurer Landschaft kam also auch durch.

Hier hilft das Update erst, wenn ihr die neue Prüfung einschaltet. Sie ist standardmäßig aus. Laut Advisory braucht es zwei Änderungen zusammen: expectedResource an requireBearerAuth() übergeben und in verifyAccessToken() die Audience des Tokens als AuthInfo.resource zurückgeben. Wer nur die erste Hälfte umsetzt, bekommt für jede Anfrage einen 401. Bis zum Update reicht es, in verifyAccessToken() jedes Token abzulehnen, dessen aud euren Server nicht enthält. Wie man einen MCP-Server grundsätzlich mit OAuth absichert, zeigen wir am Beispiel Spring AI in MCP-Server absichern: OAuth mit Spring AI.

Eine Anfrage, die den Server umwirft

Die dritte Lücke braucht keine Zugangsdaten. Das SDK hat nicht begrenzt, wie viele Array-Elemente und Objektschlüssel es in einer Anfrage validiert. Eine einzige Anfrage innerhalb des Standardlimits von 4 MiB reichte, damit der Prozess mit JavaScript heap out of memory abbricht. Am meisten gefährdet sind Tools, deren Eingabe ein Array oder ein Record enthält.

Auch hier ist die neue Option maxToolInputElements standardmäßig aus. Setzt sie knapp über die größte Eingabe, die eure Tools brauchen, und senkt außerdem die maximale Größe des Request-Bodys auf das, was ihr wirklich braucht. Wer den Body selbst parst, etwa mit express.json(), setzt das Limit dort.

Die beiden anderen

Die Client-Lücke trifft Anwendungen, die selbst MCP-Server über HTTP ansprechen. Bei einer Umleitung auf eine fremde Domain schickte das SDK eigene Header wie einen X-API-Key und die Session-ID mit, bei Statuscode 307 oder 308 sogar den Body, und damit auch OAuth-Anfragen mit refresh_token und client_secret. Das Update reicht, Umleitungen folgen jetzt nur noch innerhalb derselben Origin. Wer nicht ausschließen kann, dass eine Umleitung bei einem fremden Host gelandet ist, rotiert die betroffenen Schlüssel.

Die Task-Lücke betrifft nur Server, die das experimentelle taskStore nutzen. Ein grep -ri taskstore --exclude-dir=node_modules . zeigt, ob das bei euch der Fall ist. Das Feature ist ohnehin veraltet, seit die Spezifikation vom 28.07.2026 es durch eine neue Erweiterung ersetzt hat.

Was ihr jetzt tun solltet

1. Versionen prüfen. npm ls @modelcontextprotocol/sdk @modelcontextprotocol/server @modelcontextprotocol/client zeigt, was in euren Projekten steckt, auch als transitive Abhängigkeit.
2. Server-Instanzen prüfen. Wird McpServer oder der Transport einmal beim Start angelegt und dann für alle Anfragen genutzt? Dann umbauen, unabhängig von der Version.
3. Updaten und die neuen Optionen setzen. expectedResource für OAuth, maxToolInputElements und ein Body-Limit gegen Speicherangriffe.
4. Vor dem Deployment testen. Nach dem Update schlagen geteilte Instanzen absichtlich fehl.

Für remote erreichbare MCP-Server ist das nicht die erste Warnung in diesem Jahr. Im April hat OX Security eine systemische Lücke im Protokollumfeld offengelegt, und erst vor wenigen Tagen haben gefälschte MCP-Server über npm Agenten umgeleitet. Die Grundlagen zu MCP stehen in MCP: Wie KI-Tools miteinander reden.