MCP-Tools brauchen Autorisierung auf Aktionsebene

Am 17. Mai 2026 veröffentlichte die NVD CVE-2026-8719 für AI Engine 3.4.9, ein WordPress-Plugin, das AI- und MCP-Funktionen für WordPress-Websites bereitstellt.¹³

Dieser Fehlermodus sollte jeden Entwickler von MCP beunruhigen. Wordfence beschrieb eine fehlende WordPress-Berechtigungsprüfung im Autorisierungspfad für MCP-OAuth-Bearer Tokens: Jedes gültige OAuth Token konnte auf MCP-Tools mit Administrationsrechten zugreifen, ohne dass Administratorrechte geprüft wurden.² Wordfence bewertete das Problem mit 8,8 als High und kennzeichnete Version 3.5.0 als gepatchte Version.² Laut Änderungsprotokoll des Plugins behebt Version 3.5.0 die MCP-OAuth-Autorisierung und Tokenvalidierung, indem Administratorberechtigungen erforderlich sind.³

MCP-Autorisierung scheitert, wenn ein Server den Besitz eines Bearer Tokens als Erlaubnis behandelt, jedes Tool zu verwenden. OAuth kann belegen, dass ein Token über einen Autorisierungsablauf gekommen ist. Der MCP-Server muss trotzdem entscheiden, ob dieses Subjekt dieses Tool, auf dieser Ressource und mit diesem Schadensradius ausführen darf.

Kurzfassung

Die HTTP-Autorisierungsspezifikation von MCP liefert Entwicklern eine notwendige Grundlage: Metadaten geschützter Ressourcen, OAuth-2.1-Abläufe, Umgang mit Bearer Tokens, Tokenvalidierung, Zielgruppenprüfungen und ausdrückliche 403 Forbidden-Antworten bei unzureichenden Scopes oder Berechtigungen.⁴ Das MCP-Sicherheitstutorial beschreibt Autorisierung als Schutzschicht für sensible Ressourcen und Operationen, die MCP-Server freigeben.⁵ Diese Mechanik ersetzt aber nicht die Autorisierungsentscheidung auf Anwendungsebene. Ein Server muss das Token weiterhin einem Benutzer, einer Rolle, einem Mandanten, einem Tool, einer Ressource, einer Aktion und einer Richtlinie zuordnen.

CVE-2026-8719 macht diese Unterscheidung zu einem konkreten Fehler. AI Engine ergänzte am 12. Mai in Version 3.4.9 OAuth 2.1 und Dynamic Client Registration für seinen MCP-Server und patchte am 16. Mai in Version 3.5.0 die MCP-OAuth-Autorisierung und Tokenvalidierung, indem Administratorberechtigungen verlangt wurden.³ Die Lehre reicht über WordPress hinaus: Jeder MCP-Server, der Daten verändern, Inhalte veröffentlichen, Einstellungen ändern, private Datensätze lesen, Geld ausgeben oder privilegierte APIs aufrufen kann, braucht Autorisierung auf Aktionsebene unterhalb des Modells und unterhalb des Clients.

Die Verteilung von Tools erhöht das Risiko. Eine im Mai 2026 veröffentlichte Studie zum Klonen von Tools untersuchte 8.861 MCP- und Skills-Repositories mit 100.011 Tool-Einträgen und fand in Bereichen mit hoher Ähnlichkeit hohe bestätigte Klonraten.⁶ Wiederverwendete Vorlagen können gute Muster verbreiten. Sie können aber ebenso fehlende Prüfungen verbreiten.

Zentrale Erkenntnisse

Für Entwickler von MCP-Servern: - Validieren Sie Tokens und autorisieren Sie danach die konkrete Aktion. Behandeln Sie beides als getrennte Prüfgrenzen. - Geben Sie 401 für ungültige oder fehlende Tokens zurück und 403 für gültige Tokens ohne ausreichenden Scope oder ausreichende Berechtigung. - Testen Sie Tokens mit niedrigen Berechtigungen gegen jedes Administrations-, Schreib-, Veröffentlichungs-, Lösch-, Export- und Konfigurationstool.

Für Sicherheitsteams: - Prüfen Sie MCP-Server wie Anwendungsendpunkte, nicht wie Chat-Plugins. - Fragen Sie, welchem Benutzer, welcher Rolle, welchem Mandanten, welcher Ressource und welcher Aktion jeder Tool-Aufruf zugeordnet wird. - Verlangen Sie Protokolle, die Token-Subjekt, Tool-Name, Ressource, Autorisierungsentscheidung und Ablehnungsgrund zeigen.

Für Agentenplattform-Teams: - Marketplace-Zahlen beweisen keine unabhängigen Implementierungen. - Ähnlichkeits- und Herkunftsprüfungen sind wichtig, weil geklonte Tools verwundbare Autorisierungslogik übernehmen können. - Behandeln Sie Servervorlagen als sicherheitskritische Infrastruktur.

Für Betreiber: - Aktualisieren Sie AI Engine auf 3.5.0 oder neuer, wenn Sie das betroffene WordPress-Plugin einsetzen.²³ - Deaktivieren Sie die MCP-Freigabe, bis klar ist, welche WordPress-Rollen welche Tools erreichen können. - Starten Sie jede neue MCP-Verbindung im Nur-Lese-Modus und erweitern Sie die Berechtigungen erst, wenn Tests die Ablehnungspfade nachgewiesen haben.

Was in AI Engine kaputt war

AI Engine positioniert MCP als Möglichkeit, Claude Code, Claude, ChatGPT, OpenClaw und andere Clients über eine URL, einen Anmeldeablauf und einen Zustimmungsschritt mit einer WordPress-Website zu verbinden.³ Version 3.4.9 ergänzte OAuth 2.1 mit Dynamic Client Registration für den MCP-Server, damit browsergesteuerte Clients ohne gemeinsam genutztes Bearer Token eine Verbindung herstellen konnten.³

Diese Produktrichtung ist sinnvoll. Gemeinsame statische Tokens passen schlecht zu benutzerorientierten MCP-Integrationen. OAuth-Abläufe können einen Client, einen Benutzer und einen Server sauberer miteinander verbinden als kopierte Geheimnisse.

Der Fehler lag eine Ebene tiefer. Laut NVD und Wordfence akzeptierte der verwundbare Pfad jedes gültige OAuth Token für den MCP-Zugriff, ohne vor dem Zugriff auf MCP-Tools mit Administrationsrechten Administratorrechte zu prüfen.¹² Diese Unterscheidung ist entscheidend:

Die Patchbeschreibung auf der WordPress-Plugin-Seite verwendet die richtige Sprache: MCP-OAuth-Autorisierung und Tokenvalidierung erfordern nun Administratorberechtigungen und verhindern damit Rechteausweitung durch Nicht-Administratoren.³ Dieser Satz benennt die fehlende Schicht. Ein Token ersetzt keine Berechtigungsprüfung.

OAuth ist notwendig, aber nicht ausreichend

Die Autorisierungsspezifikation von MCP behandelt den Ablauf auf Transportebene für HTTP-basierte Transporte. Laut Spezifikation stellen MCP-Clients im Namen von Ressourceninhabern Anfragen an eingeschränkte MCP-Server; der Ablauf stützt sich auf OAuth 2.1, Metadaten geschützter Ressourcen, Metadaten von Autorisierungsservern, Dynamic Client Registration und die Verwendung von Bearer Tokens.⁴

Diese Bausteine lösen echte Probleme:

Die MCP-Spezifikation warnt außerdem vor Confused-Deputy- und Token-Passthrough-Risiken. MCP-Server müssen validieren, dass vorgelegte Tokens auf den MCP-Server zielen, und dürfen ein vom MCP-Client erhaltenes Token nicht an vorgelagerte APIs weiterreichen.⁴ Diese Vorgaben schützen die Grenze zwischen Diensten.

Autorisierung auf Aktionsebene schützt die Grenze innerhalb des MCP-Servers.

Ein MCP-Server kann 10 oder 100 Tools freigeben. Manche Tools lesen öffentliche Metadaten. Andere lesen private Datensätze. Manche entwerfen Änderungen. Manche verändern Produktionszustand. Manche verwalten Benutzer, Plugins, Zahlungen, Jobs, Nachrichten oder Infrastruktur. Ein gültiges Token sollte nicht automatisch jedes Tool erreichen, nur weil der Server die Sitzung akzeptiert hat.

Die richtige Kette sieht so aus:

1. Token-Aussteller, Signatur, Ablaufzeit, Zielgruppe und Transportregeln validieren.
2. Das Token einem lokalen Subjekt zuordnen: Benutzer, Dienstkonto, Organisation, Mandant oder Automatisierung.
3. Rolle, Scopes, Freigaben, Budgets und Richtlinie dieses Subjekts laden.
4. Das angeforderte MCP-Tool nach Aktionstyp und Risiko klassifizieren.
5. Die Zielressource prüfen, nicht nur den Tool-Namen.
6. 403 zurückgeben, wenn das Token gültig ist, die Aktion aber die Befugnis überschreitet.
7. Die Entscheidung mit genügend Details für spätere Prüfung protokollieren.

OAuth bringt die Anfrage bis zum Entscheidungspunkt. Autorisierung entscheidet, ob die Aktion dazugehört.

Tool-Aufrufe brauchen eine Berechtigungsmatrix

Agenten-Tools machen alte Endpunktgewohnheiten gefährlicher. Eine normale Webroute hat oft einen schmalen UI-Pfad um sich herum. Ein modellorientiertes Tool sitzt in einem Planer. Der Agent kann erneut versuchen, Aufrufe verketten, Tool-Beschreibungen auswerten, Leseergebnisse mit Schreibaktionen kombinieren und Anweisungen aus nicht vertrauenswürdigen Inhalten in spätere Schritte übernehmen.

Dieses Verhalten verändert das minimale Berechtigungsmodell. Ein Server sollte nicht nur fragen: „Kann dieser Benutzer auf MCP zugreifen?“ Er sollte fragen: „Darf dieser Benutzer diese Aktion über dieses Tool gegen diese Ressource genau jetzt ausführen?“

Verwenden Sie eine Matrix:

Diese Matrix passt zu dem Muster aus Agentenschlüssel brauchen Risikobudgets. Zugangsdaten sollten sich nicht wie universelle Bearer Strings verhalten. Sie sollten wie begrenzte Autoritätsobjekte mit serverseitigen Limits, Aktivitätsprotokollen, Widerruf und konservativen Standardeinstellungen funktionieren.

Sie passt auch zum Verantwortungsrahmen aus Eigentümerschaft von AI-Agenten ist das Vertrauensprimitiv. Jeder privilegierte Tool-Aufruf sollte einem verantwortlichen Konto, einer Sitzung, einem Autoritätsbündel, einem Prüfpfad und einem Stopppfad zugeordnet sein.

Geklonte Tools können dieselbe fehlende Prüfung übernehmen

Der AI-Engine-Fehler wäre auch dann relevant, wenn jeder MCP-Server aus einer sorgfältigen unabhängigen Implementierung stammte. Das Tool-Ökosystem sieht aber nicht so sauber aus.

Kim, Jiang, Hu, Jia und Gong veröffentlichten am 10. Mai 2026 eine Studie zum Klonen von Tools in agentischen AI-Ökosystemen. Ihr Datensatz umfasste 7.508 MCP-Repositories mit 87.564 extrahierten Tools und 1.353 Skills-Repositories mit 12.447 Tools, insgesamt also 8.861 Repositories und 100.011 Tool-Einträge.⁶ Die Autoren verwendeten Jaccard-Ähnlichkeit auf Token-Ebene und ssdeep für unscharfe strukturelle Ähnlichkeit und verifizierten anschließend Stichprobenpaare aus verschiedenen Ähnlichkeitsbereichen manuell.⁶

Im Abstract berichten sie, dass 60 % der Kandidaten mit hoher Jaccard-Ähnlichkeit und 85 % der Kandidaten mit hoher ssdeep-Ähnlichkeit im MCP-Ökosystem manuell als Klone bestätigt wurden.⁶ Die Studie argumentiert, dass versteckte Duplikation Benchmark-Splits verunreinigen, verwundbare Implementierungen verbreiten, Messungen zur Generalisierung von Tool-Nutzung verzerren und Herkunfts-, Zuschreibungs- und Lizenzfragen aufwerfen kann.⁶

Dieser Befund verändert, wie Teams das Wachstum von MCP-Marktplätzen lesen sollten. Mehr Tools bedeuten nicht automatisch mehr unabhängige Sicherheitsprüfung. Ein wiederholtes Servergerüst kann dem Ökosystem Konsistenz geben. Dieselbe Wiederholung kann aber auch dasselbe schwache Authentifizierungsmuster über viele Pakete kopieren.

Die Sicherheitsprüfung sollte deshalb die Herkunft einbeziehen:

Agenten-Skills brauchen Paketmanager argumentierte für paketartige Verteilung, Herkunftsnachweise und Richtlinien rund um Skills. MCP-Server brauchen dieselbe Disziplin, plus Autorisierungstests zur Laufzeit.

Die minimale Testsuite für MCP-Autorisierung

Jeder MCP-Server, der private oder veränderbare Daten berührt, sollte eine Autorisierungstestsuite mitliefern. Unit-Tests, die den Erfolgsfall bestätigen, reichen nicht. Das gefährliche Verhalten steckt in den Ablehnungspfaden.

Beginnen Sie mit diesen Fällen:

Der exakte Statuscode kann der Produktrichtlinie folgen, aber die Unterscheidung sollte erhalten bleiben: Ungültige Zugangsdaten scheitern vor der Subjektauflösung, gültige Zugangsdaten mit unzureichender Befugnis scheitern an der Autorisierungsgrenze. Die MCP-Spezifikation nennt 401 für fehlende oder ungültige Autorisierung und 403 für ungültige Scopes oder unzureichende Berechtigungen.⁴

Für WordPress wird dieselbe Regel noch schärfer: MCP-Tools, die Administrationsvorgänge ausführen, sollten dieselben WordPress-Berechtigungen prüfen wie das Dashboard, die REST API oder der interne PHP-Pfad. Eine Rolle mit niedrigeren Rechten sollte keinen neuen Weg zu Administrationsverhalten erhalten, nur weil der Aufruf über ein modellorientiertes Protokoll kam.

Was Marketplace-Prüfungen verlangen sollten

MCP-Marktplätze und Plugin-Verzeichnisse sollten Autorisierungsmetadaten als Paketdaten erster Klasse behandeln. Ein Benutzer, der entscheiden muss, ob er einen Server aktiviert, braucht mehr als eine Tool-Anzahl.

Öffentliche Mindestmetadaten:

Diese Felder würden verwundbare Tools nicht beseitigen. Sie würden die Prüffläche real machen. Betreiber könnten deklarierte Autorität mit tatsächlichem Code vergleichen, und Marktplätze könnten ähnliche Implementierungen gruppieren, wenn ein Defekt auftaucht.

Das ist die fehlende Brücke zwischen der MCP-Autorisierungsspezifikation und der Studie zum Klonen von Tools. Die Spezifikation erklärt Implementierern, wie der Ablauf auf Protokollebene funktioniert. Das Ökosystem braucht Herkunftsnachweise auf Paketebene und Belege für Autorisierung auf Aktionsebene, damit wiederholte Implementierungen nicht dieselben fehlenden Prüfungen wiederholen.

Was Sie stattdessen bauen sollten

Bauen Sie MCP-Autorisierung als Pipeline:

1. Protokollgrenze: Metadaten geschützter Ressourcen, OAuth-Ablauf, Token-Platzierung, Token-Gültigkeit, Ablaufzeit, Aussteller und Zielgruppe prüfen.
2. Subjektgrenze: Das Token einem Benutzer, Dienstkonto, einer Rolle, einem Mandanten und einem Arbeitsbereich zuordnen.
3. Tool-Grenze: Jedes Tool nach Lesen, Entwerfen, Schreiben, Löschen, Veröffentlichen, Exportieren, Administrieren, Ausführen oder Bezahlen klassifizieren.
4. Ressourcengrenze: Das exakte Zielobjekt oder die Mandantengrenze autorisieren.
5. Budgetgrenze: Grenzwerte für Rate, Größe, Ausgaben, Zielgruppe und Zeit vor der Ausführung anwenden.
6. Freigabegrenze: Für Hochrisikoaktionen menschliche oder richtlinienbasierte Freigabe verlangen.
7. Audit-Grenze: Erlaubnis-, Ablehnungs- und „Prüfung erforderlich“-Entscheidungen an einer Stelle aufzeichnen, die Betreiber prüfen können.

Diese Grenzen sollten außerhalb des Modells liegen. Eine Tool-Beschreibung kann den Agenten anweisen, Administrationsaktionen zu vermeiden. Ein Prompt kann um Vorsicht bitten. Beides sollte die Grenze nicht tragen. Der Server sollte unautorisierte Aktionen auch dann zurückweisen, wenn der Agent höflich, überzeugt oder wiederholt danach fragt.

Die Sandbox Ihres Agenten ist nur ein Vorschlag macht denselben Punkt aus einer anderen Richtung: Gültige Berechtigungen können sich trotzdem zu unsicherem Verhalten zusammensetzen. MCP-Tools brauchen Autorisierung an der Aktionsgrenze, weil der Agent Aktionen schneller kombiniert, als ein Mensch sie im Kopf simulieren kann.

FAQ

Erfordert MCP OAuth?

Nein. MCP-Autorisierung ist optional, und die HTTP-Autorisierungsspezifikation gilt, wenn eine Implementierung Autorisierung über HTTP-basierte Transporte unterstützt. Dieselbe Spezifikation sagt, dass STDIO-Transporte Zugangsdaten aus der Umgebung abrufen sollten, statt dem HTTP-OAuth-Ablauf zu folgen.⁴

Löst OAuth die MCP-Autorisierung?

OAuth löst nur einen Teil des Problems. OAuth kann einen Autorisierungsablauf etablieren, Tokens ausstellen und einem geschützten MCP-Server erlauben, Bearer Tokens zu validieren. Der MCP-Server muss trotzdem entscheiden, ob das Token-Subjekt die konkrete Tool-Aktion gegen die Zielressource ausführen darf.

Was hat CVE-2026-8719 bewiesen?

CVE-2026-8719 hat bewiesen, dass ein Pfad mit gültigem Token trotzdem lokale Berechtigungsdurchsetzung vermissen lassen kann. NVD und Wordfence beschreiben AI Engine 3.4.9 so, dass jedes gültige OAuth Token für MCP-Zugriff akzeptiert wurde, ohne vor Erreichbarkeit von MCP-Tools auf Administrationsebene Administratorrechte zu prüfen.¹²

Was sollten MCP-Entwickler zuerst testen?

Testen Sie zuerst Ablehnungspfade: Token mit niedrigen Berechtigungen zu Admin-Tool, Nur-Lese-Token zu Schreib-Tool, gültiges Token zu Ressource eines anderen Mandanten, abgelaufenes Token, Token mit falscher Zielgruppe und destruktives Tool ohne Freigabe. Ein bestandener OAuth-Erfolgsfall beweist keine Autorisierung auf Aktionsebene.

Warum ist Tool-Klonen für die MCP-Sicherheit relevant?

Tool-Klonen ist relevant, weil wiederholte Implementierungen dieselbe verwundbare Middleware, dieselben Authentifizierungsabkürzungen und dieselben fehlenden Prüfungen wiederholen können. Die Tool-Cloning-Studie vom Mai 2026 fand hohe bestätigte Klonraten bei MCP-Kandidaten mit hoher Ähnlichkeit und warnte, dass versteckte Duplikation verwundbare Implementierungen verbreiten kann.⁶

Referenzen