Wichtige Erkenntnisse
Am 28. Juli 2026 wird das Model Context Protocol (MCP) offiziell zu einer zustandslosen Architektur übergehen.
Durch den Wechsel zu einem zustandslosen Modell und die Einführung umfangreicher UI-Anwendungen und asynchroner Aufgaben sorgt das Protokoll dafür, dass die Verantwortung für den Aufbau kritischer Sicherheitsgrenzen jetzt ganz bei Entwicklern liegt.
Durch das Update werden wichtige bisherige Sicherheitsrisiken beseitigt, darunter Sitzungsübernahme auf Protokollebene, unerwünschte Server-Prompts und schwache Authentifizierungsmethoden.
Doch die Einführung eines anwendungsverwalteten Zustands, umfangreicher interaktiver KI-Oberflächen und lange andauernder asynchroner Aufgaben schafft auch neue Möglichkeiten für Missbrauch.
Wenn diese neuen Funktionen nicht ordnungsgemäß geschützt werden, könnten sie unbefugten Zugriff auf Kundendaten, nutzergerichtetes Phishing über vertrauenswürdige KI-Erlebnisse, die Umgehung von Sicherheitskontrollen in Unternehmen sowie Serviceunterbrechungen durch Ausnutzung von Hintergrund-Verarbeitungsworkflows ermöglichen.
Die bevorstehende MCP-Spezifikation 2026-07-28 ist die bedeutendste Architektur-Weiterentwicklung des Model Context Protocol (MCP) seit dessen Beginn. Was als ein lokales KI-Integrationstool mit nur einem Nutzer begann, entwickelt sich jetzt zu einer Plattform, die native Cloud-Bereitstellungen auf Enterprise-Niveau unterstützt.
Nachdem am 21. Mai 2026 ein Release-Kandidat veröffentlicht wurde, soll am 28. Juli 2026 die endgültige Spezifikation veröffentlicht werden – mit einem offiziellen 12-Monats-Zeitfenster für die Einstellung ausgewählter veralteter Funktionen.
Weiterentwicklung der Angriffsfläche
Um diese unternehmensfähige Grundlage zu erreichen, verändert das Update die Art und Weise, wie das Protokoll Daten und Ausführung verarbeitet. Es führt eine zustandslose Architektur ein, die von Anfragen mit mehreren Paketumläufen, neuen standardisierten HTTP-Headern und einem universellen _meta-Objekt für kontextbezogenes Messaging unterstützt wird. Darüber hinaus formalisiert die Spezifikation MCP-Anwendungen und asynchrone Aufgaben und wertet gleichzeitig die OAuth-Integration zu einem First-Class-Objekt auf.
Während sich ein Großteil der Diskussion über diese Funktionen auf Skalierbarkeit und Interoperabilität konzentriert, sind ihre strukturellen Auswirkungen auf die Angriffsfläche des Protokolls ebenso wichtig. Die Veränderung des Sicherheitsmodells mindert oder beseitigt einige langjährige Risiken auf Protokollebene, schafft jedoch auch neue Verantwortlichkeiten für MCP-Anwendungsentwickler (Abbildung 1). Letztlich gilt: Während diese Veränderungen die Grundlage verbessern, ist die allgemeine Sicherheit jetzt von den Implementierungsentscheidungen abhängig.
Abb. 1: Entwicklung der MCP-Angriffsfläche in der neuen Spezifikation
Geminderte oder beseitigte Angriffsflächen
Frühere MCP-Versionen waren durch protokollverwaltete Sitzungen, serverinitialisierte Kommunikation und unausgereifte Authentifizierungsanforderungen verschiedenen Sicherheitsrisiken ausgesetzt. Durch die neue Spezifikation werden mehrere dieser Mechanismen umgestaltet oder entfernt, wodurch die Angriffsfläche auf Protokollebene reduziert wird. Zu diesen Mechanismen gehören:
Sitzungsübernahme auf Protokollebene
Unerwünschte Server-Prompts
Schwache Authentifizierungsmethoden
Sitzungsübernahme auf Protokollebene
Frühere MCP-Versionen nutzten einen zustandsbehafteten Initialisierungsprozess, der eine langlebige Sitzung mit dem Header Mcp-Session-Id erstellt hat. Diese Sitzungs-IDs sind in der Regel hochwertige Ziele, da Angreifer, die sie in die Finger bekommen, authentifizierte Nutzer imitieren können.
Die neue Spezifikation entfernt diese protokollverwalteten Sitzungen vollständig, wodurch dieser spezielle Angriffsvektor beseitigt wird. Doch nun müssen Entwickler ihre eigenen sicheren Mechanismen zur Zustandsverwaltung erstellen (die wir später in diesem Blogbeitrag untersuchen werden).
Unerwünschte Server-Prompts
Mit früheren MCP-Versionen konnten Server zu beliebigen Zeitpunkten unerwünschte Anfragen oder Prompts über Server-Sent Events an Clients senden.
Die neuen Regeln beschränken dieses Verhalten strikt und verhindern, dass kompromittierte Server Nutzer mit unerwünschten schädlichen Interaktionen stören.
Schwache Authentifizierungsmethoden
Das Update erzwingt eine Umstellung auf strenge OAuth 2.1-Anforderungen, was Authentifizierungsrisiken drastisch reduziert. Durch die Abschaffung veralteter Passwörter und impliziter Berechtigungen sowie die Vorgabe moderner Schutzmaßnahmen wie Proof Key for Code Exchange (PKCE) schränkt das Protokoll die Möglichkeiten, Anmeldedaten und Token offenzulegen und zu missbrauchen, erheblich ein.
Insgesamt minimieren diese Änderungen nicht nur die Angriffsfläche im Zusammenhang mit der Authentifizierung, sondern auch den Auswirkungsradius von Sitzungen, die in früheren MCP-Implementierungen bestanden.
Neue Angriffsflächen durch die neue Spezifikation
Auch wenn das Protokoll mehrere Schwachstellen entfernt, führt es auch neue Bereiche ein, in denen die Sicherheit stark von der Implementierungsqualität abhängt, darunter:
Agentenübergreifende Workflow-Übernahme
Clientgesteuerte Metadaten-Manipulation
Abweichende Header-Interpretation sowie Datenoffenlegung über Header
MCP-Anwendungen und Stored Cross-Site Scripting
Exploit-Risiken in lange laufenden Hintergrundaufgaben
Agentenübergreifende Workflow-Übernahme
Der Wechsel zur Zustandslosigkeit bringt subtile Sicherheitsherausforderungen mit sich. In Unternehmensumgebungen sind KI-Interaktionen nicht immer einfache Dialoge mit nur einer einzigen Anfrage: Oft erfordern sie eine Abfolge von Ereignissen. Beispiele:
Um Klärung bitten: Ein Tool kann mitten in einer Aufgabe pausieren, um den Nutzer nach fehlenden Details zu fragen.
Fortschritt überprüfen: Bei einer langwierigen Aufgabe muss das System möglicherweise regelmäßig Updates anfordern.
Workflows unterbrechen: Ein komplexer Prozess kann für eine Stunde pausieren, während er auf eine menschliche Genehmigung wartet, und dann die Ausführung genau an der Stelle fortsetzen, an der sie zuvor unterbrochen wurde.
Da das neue MCP zustandslos ist, verwendet es keine permanenten Sitzungen, um sich zu merken, wer der Nutzer ist. Stattdessen nutzt es Tracking-IDs und Zustandsobjekte, die der Server an den Client übergibt. Der Client gibt diese dann zurück, sobald er bereit ist, den Ausführungsablauf fortzusetzen, wodurch der Client praktisch die volle Kontrolle über den Zustand der Aufgabe erhält.
Das Sicherheitsrisiko liegt auf der Hand: Da diese Tracking-IDs und Zustandsobjekte direkt vom Client stammen, kann der Server ihnen nicht blind vertrauen. Abbildung 2 zeigt: Wenn ein MCP-Server vorhersehbare Tracking-IDs verwendet oder die Integrität des empfangenen Zustandsobjekts nicht streng überprüft, können Angreifer diese Werte erraten oder verändern, um Folgendes zu tun:
Den aktiven Workflow eines anderen Nutzers übernehmen
Auf Informationen eines anderen Agenten zugreifen
Nicht autorisierte, mandantenübergreifende Aktionen auslösen
Abb. 2: Veranschaulichung der Tracking-ID-Erratung und Zustandsmanipulation
Während die offizielle MCP-Spezifikation Entwickler ausdrücklich warnt und ihnen nahelegt, die Integrität dieser Objekte zu überprüfen, legt sie keinen spezifischen Standard und keine spezifische Implementierung fest. Die Verantwortung für den Aufbau dieser Sicherheitsebene liegt also ausschließlich bei individuellen Serverentwicklern.
Clientgesteuerte Metadaten-Manipulation
Die neue Spezifikation führt ein _meta-Objekt ein, mit dem Clients praktisch jeder MCP-Nachricht nutzerdefinierte Metadaten hinzufügen können. So könnte ein Angreifer selbst mit einer einzelnen einfachen Anfrage schädliche Schlüssel-Wert-Paare bereitstellen, wie beispielsweise {"tenant": "admin", "authenticated": true}.
Da diese Felder keine kryptografische Signatur aufweisen, kann eine einzige schädliche Anfrage sofort zu einer Berechtigungseskalation oder zu mandantenübergreifendem Datenzugriff führen, wenn ein Server diesen Metadaten bei Routing- oder Autorisierungsentscheidungen blind vertraut.
Abweichende Header-Interpretation sowie Datenoffenlegung über Header
Die Spezifikation führt MCP-spezifische HTTP-Header wie Mcp-Method und Mcp-Name ein, die es Vermittlungsstellen, Proxys, Gateways und Servern ermöglichen, MCP-Anfragen einheitlich zu interpretieren und korrekt weiterzuleiten.
Allerdings bringen diese Header auch zwei neue Sicherheitsrisiken mit sich:
Abweichende Protokollinterpretation (Desync-Angriffe): Angreifer können widersprüchliche Werte zwischen den HTTP-Headern und dem JSON-RPC-Anfrageinhalt senden, um eine Abweichung zwischen den beiden Kommunikationsprotokollen – HTTP und JSON-RPC – auszunutzen und so die Backend-Infrastruktur zu desynchronisieren. Diese fehlende Synchronisierung kann dazu führen, dass Proxys und Backend-Server dieselbe Anfrage auf unterschiedliche Weise interpretieren, wodurch Angreifer Sicherheitskontrollen umgehen, der Überwachung entgehen oder schädliche Aktionen verschleiern können.
Datenlecks über x-mcp-header: Mit dieser neuen Anweisung können Entwickler bestimmte Toolargumente direkt dem HTTP-Header zuordnen. Das hilft Proxys dabei, den Traffic schneller weiterzuleiten, ohne den gesamten Anfrageinhalt parsen zu müssen. Wenn Entwickler jedoch versehentlich sensible Eingaben wie API-Schlüssel, Token oder personenbezogene Daten zuordnen, werden diese vertraulichen Informationen direkt in die Header übertragen. Dort werden sie für jeden Load Balancer, jeden Proxy und jedes Protokollierungssystem entlang des Weges sichtbar.
MCP-Anwendungen und Stored Cross-Site Scripting
Eine der spannendsten Entwicklungen beim MCP ist die Umwandlung von MCP-Anwendungen in eine First-Class-Protokollerweiterung. MCP-Anwendungen sind die interaktiven visuellen Bereiche, die Sie in KI-Anwendungen wie Claude Desktop sehen (z. B. interaktive Formulare und Dashboards, Dokumenten-Viewer oder Bildschirme zur Workflow- und Aufgabenverfolgung).
Diese umfangreichen Nutzeroberflächen verbessern zwar das Nutzererlebnis erheblich, bringen aber auch klassische Webbrowser-Risiken wie Stored Cross-Site Scripting (XSS) in das KI-Ökosystem ein. Beispielsweise könnte ein Angreifer über ein MCP-Tool schädlichen HTML- oder JavaScript-Code speichern. Wenn ein anderer Nutzer (oder ein KI-Agent) diesen Inhalt aufruft, wird das schädliche Skript automatisch innerhalb der Nutzeroberfläche der Anwendung ausgeführt.
Zwar schreibt die MCP-Spezifikation vor, dass die Agenten diese Skripte in einer <iframe>-Sandbox ausführen müssen, um zu verhindern, dass Cyberkriminelle den KI-Agenten vollständig übernehmen, doch für Nutzer besteht weiterhin ein Risiko. Ein Angreifer kann den kompromittierten Bereich weiterhin nutzen, um irreführende Inhalte anzuzeigen, Phishing-Kampagnen zum Diebstahl sensibler Informationen mit gefälschten Prompts durchzuführen, alle derzeit in diesem spezifischen Bereich sichtbaren Nutzerdaten zu stehlen und diese gestohlenen Informationen an seine eigenen Server zurückzusenden (Abbildung 3).
Abb. 3: Veranschaulichung der Ausnutzung von MCP-Anwendungen über Stored XSS
Exploit-Risiken in lange laufenden Hintergrundaufgaben
Die Einführung lange laufender Aufgaben schafft einen massiven DoS-Vektor (Denial of Service), der auf einseitigen Interaktionen beruht. Da das Erstellen von Aufgaben für den Client kostengünstig ist, aber den Server viele Ressourcen kostet, kann ein Angreifer eine einzige Anfrage senden, um einen ressourcenintensiven Vorgang (mit hohem CPU-, Speicher- oder Datenbankspeicherverbrauch) auszulösen, und anschließend sofort die Verbindung trennen.
Diese einseitige, asynchrone Ausnutzungsmethode zwingt den Server dazu, auch nach dem Abmelden des Clients große Workloads zu verarbeiten, wodurch der Angreifer die Serverressourcen schnell erschöpfen kann.
Fazit
Die MCP-Spezifikation 2026-07-28 markiert den Übergang des Protokolls von der lokalen Nutzung zum Einsatz im Unternehmensmaßstab. Was die Sicherheit angeht, handelt es sich bei den Änderungen nicht nur um schrittweise Verbesserungen. Sie verteilen die Verantwortung für Sicherheit gänzlich um: Sicherheitsentscheidungen, die zuvor durch das Protokoll erzwungen wurden, werden zunehmend an MCP-Serverentwickler und Plattformbetreiber delegiert.
Da sich die Einführung von MCP in Cloud-Umgebungen beschleunigt, ist die wichtigste Sicherheitsfrage nicht mehr, ob das Protokoll selbst sicher ist. Stattdessen müssen Sicherheitsteams bestimmen, ob die Anwendungen, die darauf aufbauen, die neuen Vertrauensgrenzen, Zustandsmanagement-Mechanismen und Ausführungsmodelle, die durch die Spezifikation eingeführt wurden, korrekt implementieren.
Um diese neuen Angriffsflächen angemessen zu schützen, müssen Sicherheitsteams alle vom Client bereitgestellten Zustands- und Metadaten als nicht vertrauenswürdige Eingaben behandeln, indem sie strenge kryptografische Verifizierung, Ausgabecodierung für KI-generierte visuelle Bereiche und zuverlässige Ressourcenkontingente für asynchrone Aufgaben durchsetzen.
Um den aktuellen Wandel zu bewältigen, ist eine proaktive Verteidigungsarchitektur erforderlich, die Exploits blockiert, bevor sie Ihre Backend-Infrastruktur erreichen.
Handeln Sie jetzt
Akamai ermöglicht es Unternehmen, sofort zu handeln. Indem wir auf unserer bestehenden Plattform für Edge-, API- und Anwendungssicherheit aufbauen und sie um MCP-bezogene Informationen erweitern, können Sicherheitsteams erkennen, wo MCP eingesetzt wird, können während der Experimentierphase praktische Sicherheitsvorkehrungen treffen und können zunehmende Risiken managen.
Dieser Ansatz ermöglicht es Unternehmen, MCP bereits heute einzuführen und mithilfe von Akamai Schutz, Transparenz und Kontrolle auszubauen, während sich die MCP-Nutzung weiterentwickelt.
Tags
