WordPress-Benutzerrollen: wer was darf

WordPress vergibt Rechte über Rollen. Jede Rolle ist ein Bündel von Fähigkeiten (Capabilities) wie publish_posts oder install_plugins, und jeder Benutzer hat eine Rolle. Auf einer einzelnen Seite gibt es fünf (Roles and Capabilities), in einem Multisite-Netzwerk kommt der Super-Admin dazu.

Die Zahlen dahinter habe ich an einer frischen Installation von WordPress 7.1.2 mit wp cap list gezählt, ohne die alten level_-Einträge: Der Administrator hat 50 Fähigkeiten, der Redakteur 26, der Autor 7, der Mitarbeiter 3, der Abonnent eine (read). 24 der 50 hat ausschließlich der Administrator.

Administrator heißt nicht „darf alles im Backend“, sondern „darf Code auf dem Server ausführen“. Wer install_plugins hat, kann ein Plugin hochladen, und ein Plugin ist PHP, das mit den Rechten der Seite läuft. Wer promote_users und create_users hat, kann weitere Administratoren anlegen. Ein übernommenes Administratorkonto ist deshalb eine übernommene Website, egal, wie sorgfältig der Rest gepflegt ist.

Was nur der Administrator darf#

Lieber prüfen lassen? Der Sicherheits-Check für 290 € sieht Konten, Rollen und Anmeldewege einmal von außen und innen durch und liefert einen Bericht nach Dringlichkeit.

Die Liste aus der Zählung, gruppiert:

• Code und Dateien: install_plugins, activate_plugins, edit_plugins, delete_plugins, install_themes, switch_themes, edit_themes, delete_themes, edit_files, update_core, update_plugins, update_themes
• Benutzer: list_users, create_users, edit_users, promote_users, remove_users, delete_users
• Einstellungen und Daten: manage_options, edit_theme_options, edit_dashboard, import, export, unfiltered_upload

unfiltered_upload steht zwar in der Rolle, wirkt aber erst, wenn in der wp-config.php die Konstante ALLOW_UNFILTERED_UPLOADS gesetzt ist. Die Dokumentation nennt das einen Sonderfall.

Der Redakteur darf mehr, als man denkt#

Dem Redakteur fehlen alle Rechte an Code und Benutzern. Eines hat er aber mit dem Administrator gemeinsam: unfiltered_html. Die Fähigkeit erlaubt laut Dokumentation, „HTML markup or even JavaScript code“ in Beiträge, Seiten, Kommentare und Widgets zu schreiben, mit dem Hinweis, dass das für nicht vertrauenswürdige Benutzer zu bösartigem Code führen kann. Auf einer Einzelseite haben Administrator und Redakteur sie, in Multisite nur der Super-Admin.

Was das praktisch heißt: Ein übernommenes Redakteurskonto kann ein Skript in eine Seite setzen, das im Browser jedes Besuchers läuft, auch im Browser des Administrators, wenn er die Seite aufruft. Wer keine Skripte und Einbettungscodes in Beiträgen braucht, nimmt die Fähigkeit allen weg:

// wp-config.php
define( 'DISALLOW_UNFILTERED_HTML', true );

Die Konstante wertet map_meta_cap() vor jeder Rollenprüfung aus (Quellcode-Referenz). In der Testinstallation lieferte user_can( 1, 'unfiltered_html' ) danach auch für den Administrator false. Ein Einbettungs-Block mit einer YouTube-Adresse blieb beim Speichern erhalten; aus einem Block „Individuelles HTML“ entfernte WordPress <script> und <iframe>. Wer Einbettungscodes von Hand in Beiträge kopiert, braucht dann einen anderen Weg.

Rollen prüfen, in fünf Minuten#

Die Befehle laufen im Verzeichnis der Installation, geprüft am 05.10.2026 mit WP-CLI 2.12 an WordPress 7.1.2.

1. Wer ist Administrator?

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Jede Zeile muss einer Person gehören, die du kennst. Ein Konto, das niemand angelegt hat, führt WordPress.org als Anzeichen eines Angriffs („creation of new users“, FAQ My site was hacked). Dann nicht hier weitermachen, sondern bei WordPress gehackt: was tun.

2. Wer hat welche Rolle? wp user list --fields=user_login,roles listet alle. Rollen, die nicht in der Tabelle oben stehen, kommen von Plugins; wp role list zeigt sie, wp cap list <rolle> ihren Inhalt (wp role, wp cap).

3. Registrierung und Standardrolle.

wp option get users_can_register   # 0 = niemand kann sich selbst registrieren
wp option get default_role         # subscriber

Im Backend unter „Einstellungen → Allgemein“: „Jeder kann sich registrieren“ und „Standardrolle eines neuen Benutzers“ (Settings General Screen). Wer beide Werte ändern kann, kann sich danach selbst als Administrator registrieren. Steht dort etwas anderes als 0 und subscriber, ohne dass es jemand so eingestellt hat, ist das ein Befund.

4. Herabstufen oder löschen.

wp user set-role agentur editor
wp user delete altkonto --reassign=1

set-role ersetzt die bisherige Rolle, in der Testinstallation wurde aus dem Administrator ein reiner Redakteur. --reassign überträgt die Beiträge des gelöschten Kontos auf das Konto mit der angegebenen ID; ohne die Option fragt WP-CLI nach und löscht sie mit (wp user delete).

5. Sitzungen beenden, wenn ein Konto verdächtig ist. Ein Rollenwechsel wirkt beim nächsten Seitenaufruf, eine bestehende Anmeldung bleibt aber bestehen. Wer vermutet, dass jemand anderes das Konto benutzt, vergibt ein neues Passwort und beendet alle Sitzungen: wp user session destroy agentur --all (wp user session destroy). Anwendungspasswörter gehören zum Konto; ob eines existiert, zeigt wp user application-password list agentur.

Hat ein Plugin die Standardrollen verändert, setzt wp role reset editor author contributor sie auf die Fähigkeiten zurück, mit denen WordPress sie ausliefert.

Wer welche Rolle bekommt#

Die Brute-Force-Dokumentation von WordPress sagt es in einem Satz: „Limit administrator count; use least‑privilege roles for day‑to‑day work“ (Brute Force Attacks). Für einen kleinen Betrieb heißt das:

• Inhaber oder IT: ein persönliches Administratorkonto mit Zwei-Faktor-Anmeldung. Für das Schreiben von Beiträgen ein zweites Konto als Redakteur ist kein Luxus.
• Agentur oder Webdesigner: ein eigenes, benanntes Administratorkonto für die Dauer des Auftrags, danach herabstufen oder löschen. Kein geteiltes Konto.
• Redaktion, Marketing: Redakteur. Wer nur eigene Texte schreibt: Autor.
• Gastbeiträge: Mitarbeiter. Veröffentlichen tut jemand mit mehr Rechten.
• Shop: WooCommerce bringt die Rollen „Kunde“ und „Shop-Manager“ mit. Der Shop-Manager verwaltet Produkte, Bestellungen und Gutscheine, kann aber keine Plugins installieren (WooCommerce, Roles & Capabilities). Für die Person, die Bestellungen abwickelt, ist das die richtige Rolle, nicht Administrator.

Ein Konto je Person ist dabei keine Formalie. Nur so lässt sich einem Konto ein zweiter Faktor zuordnen, nur so lässt es sich einzeln sperren, wenn jemand geht.

Was nicht hilft#

Den Benutzer admin umbenennen und sonst nichts. Die Dokumentation rät, admin nicht zu verwenden, aber ein umbenanntes Konto mit derselben Rolle und ohne zweiten Faktor ist genauso viel wert wie vorher.

Ein gemeinsames Büro-Konto. Das Passwort kennen alle, die je im Büro waren, und wer etwas geändert hat, steht nirgends.

Einem Redakteur per Rollen-Plugin „nur mal kurz“ install_plugins geben. Damit ist er Administrator mit anderem Namen, und das bleibt so, bis jemand die Rolle wieder prüft.

Die Werkzeugleiste für Abonnenten ausblenden. Das ändert die Anzeige, nicht die Rechte.

Zuerst die Liste, dann alles andere#

Die Liste der Administratoren ist der kürzeste Sicherheits-Check, den WordPress hat: ein Befehl, eine Minute, und jede Zeile, die niemand erklären kann, ist ein Befund. Sie ist auch Punkt 4 in WordPress-Sicherheit prüfen. Bevor du Konten löschst, lohnt eine frische Sicherung, denn Beiträge ohne --reassign kommen sonst nicht zurück. Jedes Konto, das danach Administrator bleibt, bekommt einen zweiten Faktor; wie, steht in WordPress 2FA einrichten. Taucht in der Liste ein Konto auf, das niemand angelegt hat, ist das ein Fall für den WordPress Malware-Scan und nicht nur fürs Löschen. Wer das nicht selbst im Kalender haben will: Die laufende Durchsicht der Konten ist Teil der WordPress-Wartung für 49 € im Monat.

Stand 13.10.2026. Rollen und Fähigkeiten am 05.10.2026 an einer frischen Installation gezählt (WordPress 7.1.2 de_DE, WP-CLI 2.12.0), die Befehle dort ausgeführt; deutsche Bezeichnungen aus der offiziellen Übersetzung. Dokumentation von WordPress.org und WooCommerce am selben Tag gelesen.