KI-Agenten, die Inhalte veröffentlichen, WooCommerce-Bestellungen bearbeiten, Plugins aktualisieren oder komplette Workflows über n8n und MCP-Server ausführen – das ist längst keine Zukunftsmusik mehr.
In immer mehr WordPress-Installationen gehören solche Automatisierungen bereits zum Alltag. Doch mit jeder zusätzlichen Fähigkeit eines Agenten stellt sich auch eine wichtige Frage: Was passiert eigentlich, wenn dieser Agent zu viele Rechte bekommt?
WordPress wird zur Agentenplattform
Mit WordPress 7.0, das im Mai 2026 erschienen ist, hat das CMS eine native KI-Infrastruktur bekommen – den WP AI Client. Entwickler können damit KI-Agenten direkt in WordPress integrieren, die über APIs Inhalte erstellen, Medien verwalten, Metadaten ändern oder Benutzerkonten bearbeiten.
Gleichzeitig verbinden Plugins wie AI Engine oder der MountDev AI MCP Connector externe Sprachmodelle wie Claude oder ChatGPT mit WordPress. So können Agenten über das Model Context Protocol (MCP) oder REST-Endpunkte selbstständig Aktionen ausführen.
In der Praxis heißt das: Ein KI-Agent kann Blogartikel schreiben und direkt veröffentlichen, Produktbeschreibungen im WooCommerce-Shop aktualisieren, Kundendaten auslesen, Plugin-Einstellungen ändern oder automatisierte Workflows über n8n starten – alles ohne manuellen Eingriff. Wer repetitive Aufgaben automatisieren möchte, spart damit enorm viel Zeit. Aus Sicht der IT-Sicherheit verändert sich dadurch allerdings einiges.
Das eigentliche Problem: Zu viele Rechte, zu wenig Kontrolle
Technisch gesehen ist ein KI-Agent zunächst einmal ein API-Client mit bestimmten Berechtigungen. Und genau da wird es interessant: Welche Rechte hat dieser Client eigentlich – und wer behält den Überblick darüber?
Wie real die Bedrohung für WordPress-Installationen ist, zeigt die aktuelle Lage. Das BSI hat im Juli 2026 eine Cybersicherheitswarnung für WordPress herausgegeben, nachdem zwei Schwachstellen im WordPress-Kern eine Codeausführung ohne Anmeldung über die REST-API ermöglichten – also genau über eine der Schnittstellen, über die auch KI-Agenten mit WordPress kommunizieren. Der zugehörige CVSS-Score lag bei 9,8.
Schon wenige Tage nach Veröffentlichung des Patches waren funktionsfähige Exploit-Codes auf GitHub verfügbar. Laut dem Patchstack Security Report 2026 wurden im Vorjahr 11.334 neue Schwachstellen im WordPress-Ökosystem entdeckt – 91 Prozent davon in Plugins. Im Durchschnitt vergingen von der Veröffentlichung einer kritischen Schwachstelle bis zur massenhaften Ausnutzung gerade einmal fünf Stunden.
In so einem Umfeld einen KI-Agenten mit weitreichenden Rechten an WordPress anzubinden, erhöht das Risiko deutlich. Ein konkretes Beispiel ist die Schwachstelle CVE-2025-11749 im Plugin AI Engine, von der mehr als 100.000 Websites betroffen waren.
Das Plugin machte Bearer Tokens, die zur Authentifizierung von KI-Agenten dienten, über die öffentlich zugängliche REST-API sichtbar. Angreifer konnten diese Tokens auslesen und sich damit administrativen Zugriff auf die komplette WordPress-Installation verschaffen – von der Benutzerverwaltung über Inhaltsänderungen bis hin zur Plugin-Steuerung.
Ein weiteres Beispiel aus dem Jahr 2026 ist CVE-2026-15015 im MountDev AI MCP Connector. Die Schwachstelle ermöglichte eine unautorisierte Rechteausweitung und erreichte ebenfalls einen CVSS-Score von 9,8 – also nahezu die höchste Kritikalitätsstufe. Die wichtigste Erkenntnis daraus: Ein KI-Plugin mit Agentenfunktion ist nicht einfach nur ein weiteres Content-Plugin. Es ist privilegierte Infrastruktur und sollte entsprechend behandelt werden.
Was Sie konkret tun sollten
Wenn Sie KI-Agenten in WordPress einsetzen – egal ob über MCP-Server, REST-Anbindungen oder Automatisierungstools wie n8n –, sollten ein paar grundlegende Sicherheitsmaßnahmen dazugehören.
Prinzip der minimalen Rechte. Ein Agent, der Blogbeiträge veröffentlichen soll, muss weder Benutzerkonten verwalten noch Plugin-Einstellungen ändern können. Geben Sie jedem Agenten wirklich nur die Rechte, die er für seine konkrete Aufgabe benötigt. WordPress ermöglicht über benutzerdefinierte Rollen und Capabilities eine recht genaue Vergabe von Berechtigungen – diese Möglichkeit sollten Sie nutzen.
API-Endpunkte absichern. MCP-Server, Webhook-Endpunkte und REST-APIs, über die Ihre Agenten kommunizieren, sollten möglichst nicht frei aus dem Internet erreichbar sein. Im besten Fall sind diese Endpunkte nur aus dem internen Netzwerk oder über eine IP-Whitelist zugänglich.
Müssen Agenten von extern darauf zugreifen – beispielsweise aus einer Entwicklungsumgebung oder von einem separaten Automatisierungsserver –, kann ein VPN die Verbindung verschlüsseln und den Zugriff auf interne Endpunkte zusätzlich absichern. Eine Authentifizierung auf Anwendungsebene ersetzt das natürlich nicht, aber es schafft eine weitere Netzwerkschicht, die unautorisierte Zugriffe schwieriger macht.
Tokens und Zugangsdaten rotieren. Bearer Tokens, API Keys und Webhook-Secrets sollten regelmäßig erneuert werden. Bei klassischen Benutzerkonten ist das Thema Zugangssicherheit längst angekommen, bei Agenten gerät es dagegen schnell aus dem Blick – schließlich laufen sie einfach irgendwo im Hintergrund weiter. Ein Token, das seit sechs Monaten unverändert verwendet wird, könnte theoretisch auch seit sechs Monaten kompromittiert sein.
Agenten-Aktivitäten protokollieren. Halten Sie fest, was Ihre Agenten tatsächlich tun. Egal ob ein Beitrag veröffentlicht, ein Produkt geändert oder ein Workflow gestartet wird: Solche Aktionen gehören in ein Audit-Log. Plugins wie WP Activity Log oder Simple History können dabei helfen. Ohne eine vernünftige Protokollierung lässt sich im Ernstfall kaum nachvollziehen, was ein kompromittierter Agent eigentlich alles gemacht hat.
Staging vor Produktion. Neue Agenten-Integrationen sollten zuerst in einer Staging-Umgebung getestet werden und nicht direkt auf der Live-Website. Dort können Sie in Ruhe prüfen, welche Endpunkte der Agent aufruft, welche Daten er liest oder verändert und ob seine Berechtigungen tatsächlich auf das notwendige Minimum beschränkt sind.
WordPress-Sicherheit wird Agenten-Sicherheit
Die klassischen Regeln für WordPress-Sicherheit – Updates einspielen, starke Passwörter verwenden und Zwei-Faktor-Authentifizierung aktivieren – bleiben natürlich wichtig. Sobald KI-Agenten ins Spiel kommen, reichen sie allein aber nicht mehr aus. Ein Agent, der über MCP oder REST mit WordPress kommuniziert, ist letztlich ein eigenständiger Akteur im System. Entsprechend sollte er auch sicherheitstechnisch behandelt werden.
Die entscheidende Frage ist deshalb weniger „Was kann mein Agent?“, sondern vielmehr: „Was könnte ein Angreifer tun, wenn er die Kontrolle über meinen Agenten übernimmt?“ Diese Frage sollten Sie beantworten, bevor der Agent in Produktion geht – und nicht erst dann, wenn etwas passiert ist.
Die Sicherheitsarchitektur, die Sie heute aufsetzen, entscheidet am Ende darüber, ob KI-Agenten in Ihrer WordPress-Umgebung praktische Helfer bleiben oder selbst zum Sicherheitsrisiko werden.
