wp-secure-mcp

Einfach ausgedrückt: Dies ermöglicht einem KI-Agenten, eine WordPress-Website über ein echtes WordPress-Anwendungspasswort zu lesen und in begrenztem Umfang zu beschreiben — denselben Anmeldedatentyp, den wp-admin bereits ausstellt — und nichts anderes. Es gibt hier kein Registrierungsformular, keine OAuth-Client-Registrierung, keinen Token-Endpunkt jeglicher Art. Ein Plugin in diesem Bereich hat genau das ausgeliefert, und so ist ein nicht authentifizierter Angreifer mit vollem Administratorzugriff davongekommen.

Ein WordPress-Plugin, das einen MCP-Server über die REST-API bereitstellt, wobei das Sicherheitsmodell der Kern ist, nicht ein Feature-Aufzählungspunkt.

Die Umgehung, die es zu schließen gilt

CVE-2026-15015, CVSS 9.8: Der MountDev AI MCP Connector für WordPress hat einen öffentlich zugänglichen OAuth-2.1-Dynamic-Client-Registration-Endpunkt zusammen mit einem Autorisierungsendpunkt bereitgestellt, der ebenfalls nicht überprüfte, wer fragte. Ein Angreifer registriert seinen eigenen OAuth-Client — keine Anmeldedaten erforderlich, der Endpunkt ist per Design nicht authentifiziert, das bedeutet „dynamische Client-Registrierung" — führt ihn unbeaufsichtigt durch den Autorisierungsendpunkt und erhält ein Bearer-Token, das an ein Administratorkonto gebunden ist. Volle Kontrolle über die Website: Inhalte, Benutzer, Einstellungen. Nichts war falsch konfiguriert; der Ablauf funktionierte genau so, wie OAuth-Client-Registrierung funktionieren soll. Er hätte nur niemals erreichbar sein dürfen, ohne dass bereits ein Administrator anwesend ist, um ihn zu genehmigen.

Die Verallgemeinerung der Lösung ist nicht „OAuth sorgfältiger implementieren". Es ist, diese Angriffsfläche gar nicht erst zu haben. Dieses Plugin registriert keinen Client-Registrierungsendpunkt, keinen Autorisierungsendpunkt und keinen Token-Ausstellungsendpunkt jeglicher Art. Es gibt nichts, wogegen ein Angreifer sich registrieren könnte, weil es hier nichts gibt, das Anmeldedaten ausgibt. Die Authentifizierung erfolgt über ein WordPress-Anwendungspasswort, das ein Administrator bereits für einen bestimmten Benutzer über wp-admin erstellt hat — ein Anmeldedatensatz, der nur existiert, weil ein Mensch mit manage_options sich entschieden hat, ihn im Voraus und außerhalb dieses Plugins zu erstellen.

Zwei unabhängige Schichten

Keine allein ist neu; beide absichtlich, unabhängig voneinander laufen zu lassen, ist das, was einen Fehler in einer der beiden ausschließt:

1. Nur Anwendungspasswort — niemals eine Cookie-Sitzung. WordPress' eigenes is_user_logged_in() ist auch für einen Browser-Tab wahr, der ein gültiges Cookie und Nonce hält. Auth::permission_callback() lehnt diesen Pfad bewusst ab: Es lauscht auf die Aktion application_password_did_authenticate, die der WordPress-Kern speziell dann auslöst, wenn die Basic-Auth-Anwendungspasswort-Authentifizierung erfolgreich ist, und verlangt dieses Flag, nicht nur „irgendein Benutzer ist angemeldet". Ein MCP-Client ist kein Browser-Tab mit einem Nonce; Cookie-Auth hier zu akzeptieren würde einen CSRF-förmigen Pfad in eine Tool-Oberfläche öffnen, der man auf Englisch sagen kann, sie solle Inhalte ändern — ohne Nutzen gegenüber der einen Tür, die dieses Plugin tatsächlich braucht.

2. Pro-Tool-Berechtigung, plus ein Schreib-Gate, das die Berechtigung allein nicht öffnen kann. ToolRegistry::call() prüft user_can($user_id, $capability) bei jedem Aufruf frisch — edit_posts für Beiträge, manage_woocommerce für Bestellungen. Separat verlangt das einzige Schreib-Tool, create_draft_post, zusätzlich, dass ein Administrator über Einstellungen → WP Secure MCP zugestimmt hat, standardmäßig deaktiviert. Ein Anwendungspasswort, das zufällig edit_posts trägt, kann trotzdem nichts schreiben, bis ein Mensch diesen Schalter umgelegt hat — eine Berechtigungsprüfung und ein websiteweites Gate sind zwei verschiedene Schlösser, und die Tests beweisen, dass keines das andere in irgendeine Richtung ersetzt.

Wogegen es nicht schützt

• Einen Website-Besitzer, der ein Anwendungspasswort für einen Benutzer mit mehr Berechtigungen ausstellt, als die Aufgabe erfordert. Dieses Plugin erzwingt das Berechtigungsmodell, das WordPress bereits hat; es hinterfragt nicht, wem ein Administrator entschieden hat zu vertrauen.
• Ressourcenerschöpfung innerhalb der Limits. Zeilenobergrenzen (limit, 1–20) begrenzen, wie viel ein einzelner Aufruf zurückgeben kann; ein legitim teurer WP_Query- oder wc_get_orders-Aufruf kostet trotzdem, was er kostet.
• Was der Agent mit den Daten macht, sobald er sie hat. Dies ist ein Zugriffsgate an der WordPress-Grenze, kein Data-Loss-Prevention-Tool.
• Eine Schwachstelle in WordPress, WooCommerce oder PHP selbst. Die beiden obigen Schichten sind der eigene Beitrag dieses Plugins; sie sitzen auf dem Berechtigungssystem und der Anwendungspasswort-Implementierung von WordPress auf und erben, was auch immer eines von beiden falsch macht.

Tools

Tool	Berechtigung	Nur lesend	Hinweise
search_posts	edit_posts	Ja	Stichwortsuche. Fest auf post_status=publish verdrahtet — gibt niemals Entwürfe oder private Beiträge zurück, selbst an einen Aufrufer, der sie in wp-admin sehen könnte.
get_post	edit_posts	Ja	Abruf per ID. Verweigert einen echten Beitrag an einer echten ID, wenn sein Status nicht publish ist — eine ID ist keine Umgehung derselben Regel, die search_posts erzwingt.
list_recent_orders	manage_woocommerce	Ja	Nur Status, Gesamtbetrag, Währung, Datum. Niemals Kundenname, E-Mail oder Adresse — Bestellsichtbarkeit erfordert nicht, einem Agenten die PII eines Kunden auszuhändigen, Berechtigungsprüfung hin oder her.
create_draft_post	edit_posts	Nein	post_status ist ein literales 'draft' in der Quelle, kein Argument. Dieses Tool kann unter keiner Eingabe veröffentlichen, selbst mit aktivierten Schreibvorgängen. Websiteweit aus, bis ein Administrator zustimmt.

Der tools/list-Eintrag jedes Tools trägt readOnlyHint- / destructiveHint-Annotationen, sodass ein Client entscheiden kann, ob er einen Menschen fragen soll, bevor er eines aufruft, ohne bereits wissen zu müssen, was es tut.

Installation

composer install --no-dev

Kopiere (oder verlinke) das Plugin-Verzeichnis nach wp-content/plugins/, aktiviere es über wp-admin und erstelle dann ein Anwendungspasswort für das Konto, als das ein Agent handeln soll: Benutzer → dein Profil → Anwendungspasswörter.

Konfiguration

Schreibvorgänge sind standardmäßig aus. Um create_draft_post zu erlauben: Einstellungen → WP Secure MCP → Schreib-Tools. Die Pro-Tool-Berechtigungsprüfung gilt weiterhin zusätzlich — das Umlegen des websiteweiten Schalters gewährt niemandem eine Berechtigung, die er nicht bereits hatte.

Tests

55 Tests, alle rein — keine WordPress-Installation, keine Datenbank, kein Docker. tests/bootstrap.php stubbt die WordPress-Funktionen, die src/ aufruft (current_user_can, get_post, wp_insert_post, ...), so wie ein WordPress-Plugin konventionell unittestet wird, ohne WordPress selbst zu laden.