WordPress-Multisite-Sicherheit: Leitfaden zur Absicherung des Netzwerks

Die Sicherheit von WordPress-Multisite-Installationen weist andere Schwachstellen auf als die von Einzelseiten: Eine gemeinsame Codebasis, eine Datenbank und eine globale Benutzertabelle bedeuten, dass bereits eine einzige anfällige Unterseite einem Angreifer Zugriff auf das gesamte Netzwerk verschaffen kann. Dieser Leitfaden behandelt das Multisite-Bedrohungsmodell, eine 10-Punkte-Checkliste zur Absicherung sowie die Gründe, warum eine netzwerkweite Sperrung die Lücke schließt, die Sicherheitswerkzeuge auf Einzelseitenebene offen lassen.

Warum sich die Absicherung eines Multisite-Netzwerks von der einer einzelnen Website unterscheidet

Ein WordPress-Multisite-Netzwerk sieht aus wie eine Vielzahl von Websites, ist jedoch strukturell gesehen eine einzige Installation. Fünf Merkmale bestimmen sein Bedrohungsmodell:

Ein einziger Code-Bestand. Jede Unterseite nutzt denselben WordPress-Kern, dieselben Plugin-Dateien und dieselben Theme-Dateien aus einem einzigen Verzeichnis. Eine Sicherheitslücke in einem einzelnen Plugin kann auf jeder Unterseite ausgenutzt werden, auf der dieses Plugin aktiv ist.
Eine Datenbank. Die Unterseiten verfügen über eigene Tabellensätze, es besteht jedoch keine Berechtigungsgrenze zwischen ihnen. Eine SQL Injection auf einer beliebigen Unterseite betrifft alle Tabellen in der Datenbank, einschließlich der Netzwerktabellen.
Globale Benutzer. Die Benutzertabelle wird netzwerkweit gemeinsam genutzt. Ein auf einer Unterseite registriertes Konto ist überall vorhanden, und Zugangsdaten, die auf der unwichtigsten Unterseite gestohlen wurden, können auch auf der wichtigsten Unterseite missbraucht werden.
Ein PHP-Prozess. Alle Unterseiten werden vom selben Anwendungsserver mit denselben Dateiberechtigungen bereitgestellt. Die Ausführung von Code auf einer Unterseite entspricht der Ausführung von Code im gesamten Netzwerk.
Die Rolle des Super-Admins. Super-Admins bestehen jede Berechtigungsprüfung auf jeder Unterseite. Ein Super-Admin-Konto kann nicht teilweise kompromittiert werden – wird eines davon durch Phishing kompromittiert, ist das gesamte Netzwerk verloren.

Die praktische Konsequenz: Das Sicherheitsniveau eines Multisite-Netzwerks entspricht dem Sicherheitsniveau seiner schwächsten Unterseite. Eine vergessene Testseite mit einem veralteten Plugin ist kein geringes Risiko am Rande – sie ist ein Einfallstor für alles.

Welche Teile eines Multisite-Netzwerks untersuchen Angreifer als Erstes?

Zwischen Mai und Juli 2026 verzeichnete das ReportedIP-Community Network 1,69 Millionen Angriffe auf WordPress-Websites, wobei Login-Endpoints das vorherrschende Ziel darstellten. Bei Multisite-Installationen vervielfachen sich einige dieser Angriffsflächen mit der Anzahl der Unterseiten:

Angriffsfläche	Warum dies bei Multisite-Installationen eine größere Rolle spielt	Erste Gegenmaßnahme
`wp-signup.php`	Durch die offene Registrierung können Bots im gesamten Netzwerk Konten oder ganze Unterseiten erstellen.	Stellen Sie die Registrierung in den Netzwerkeinstellungen auf „deaktiviert“ oder „nur Benutzerkonten“ ein.
Login-Seiten	Jede Unterseite verfügt über ein eigenes Formular für den Login, und alle führen die Authentifizierung anhand derselben gemeinsamen Benutzertabelle durch.	Netzwerkweite Überwachung der Login-Versuche mit gemeinsamen Versuchszählern.
`xmlrpc.php`	Es gibt jeweils eine Instanz pro Unterseite; jede Instanz akzeptiert Authentifizierungsversuche und erweiterte Multicall-Anfragen.	Deaktivieren Sie diese Funktion netzwerkweit oder begrenzen Sie die Datenübertragungsrate zentral mit Rate Limit.
User Enumeration für REST-Benutzer	Über den Benutzer-Endpoint lassen sich globale Benutzernamen ermitteln – eine einzige Abfrage bildet die Konten des gesamten Netzwerks ab.	Verhindern Sie die User Enumeration bei nicht authentifizierten Anfragen.
Veraltete Unterseiten	Auf den aufgegebenen Unterseiten wird zwar weiterhin der gesamte Quellcode ausgeführt, doch niemand liest deren Protokolle.	Löschen oder archivieren Sie Unterseiten, die nicht mehr gepflegt werden.
Zugeordnete Domänen	Eine zugeordnete Domäne ohne gültiges TLS macht die gemeinsam genutzten Authentifizierungs-Cookies des Netzwerks angreifbar.	Stellen Sie für jede Unterseite und jede zugeordnete Domain ein gültiges Zertifikat bereit.

Eine 10-Punkte-Checkliste zur Absicherung von WordPress-Multisite-Installationen

Gehen Sie diese Punkte der Reihe nach durch. Die Punkte 1–3 beseitigen die Risiken mit den größten Auswirkungen; die Punkte 4–9 verringern die Angriffsfläche; Punkt 10 befasst sich mit der Erkennung.

Schließen Sie die Registrierung oder schränken Sie sie ein. Die Einstellung „Registrierung“ in der Netzwerkverwaltung legt fest, ob Fremde Konten oder Unterwebsites erstellen können. Falls die Registrierung offen bleiben muss, richten Sie Disposable-Email Blocking sowie einen Registrierungs-Honeypot ein, damit Bot-Anmeldungen fehlschlagen, bevor sie eine Belastung verursachen.
Halten Sie die Liste der Super-Administratoren so kurz wie möglich. Jedes Super-Administrator-Konto stellt eine vollständige Gefährdung des Netzwerks dar, wenn es Opfer eines Phishing-Angriffs wird. Zwei oder drei namentlich benannte Personen reichen aus; Dienstkonten und Agenturen sollten stattdessen die Rolle eines Sub-Site-Administrators erhalten.
Setzen Sie die Zwei-Faktor-Authentifizierung für privilegierte Rollen durch. An erster Stelle stehen Super-Administratoren, an zweiter Stelle die Administratoren von Unterseiten. Phishing-resistente Methoden wie Passkeys und Hardware Security Keys schützen die Konten, deren Verlust die höchsten Kosten verursacht.
Verwalten Sie Plugins und Themes zentral. WordPress verhindert bereits, dass Administratoren von Unterseiten Plugins installieren – behalten Sie diese Vorgehensweise bei. Überprüfen Sie, welche Plugins netzwerkweit und welche selektiv aktiviert sind, und entfernen Sie alle, die von keiner Unterseite mehr verwendet werden: Deaktivierte Plugin-Dateien stellen weiterhin zugänglichen Code dar.
Deaktivieren Sie die Dateibearbeitung im Dashboard. Legen Sie DISALLOW_FILE_EDIT in der Konfigurationsdatei so fest, dass eine gekaperte Admin-Sitzung den Theme-Editor nicht in eine PHP-Shell verwandeln kann. In verwalteten Netzwerken mit einer Bereitstellungspipeline blockiert DISALLOW_FILE_MODS zudem Installationen und Updates über den Browser vollständig.
Uploads einschränken. Über die Netzwerkeinstellungen werden die zulässigen Dateitypen für Uploads sowie ein speicherspezifisches Kontingent pro Website geregelt. Kürzere Allowlists bedeuten weniger Möglichkeiten, ausführbare Inhalte in den Upload-Baum einzuschleusen.
Entfernen Sie veraltete Unterseiten. Jede Unterseite ist eine Seite für den Login, ein XML-RPC-Endpoint und ein REST API-Namensraum. Wenn eine Unterseite nicht mehr gepflegt wird, archivieren oder löschen Sie sie – damit verschwindet auch die Angriffsfläche.
Verwenden Sie überall gültiges TLS. Für Installationen auf Subdomains ist ein Wildcard-Zertifikat erforderlich; jede zugeordnete benutzerdefinierte Domain muss ebenfalls abgedeckt sein. Eine einzelne Unterseite, die über einfaches HTTP bereitgestellt wird, macht Sitzungs-Cookies zugänglich, die im gesamten Netzwerk gültig sind.
Aktualisieren Sie über die Netzwerkverwaltung – und zwar vollständig. Es ist nicht möglich, „nur die wichtigen Unterseiten“ zu aktualisieren – auf allen werden dieselben Dateien ausgeführt. Ein Plugin, das veraltet bleibt, weil eine Unterseite von der alten Version abhängt, sorgt dafür, dass der anfällige Code für alle Nutzer weiterhin geladen wird.
Zentralisieren Sie die Erkennung und Blockierung. Verteilte Angriffe sind in den Protokollen der einzelnen Websites nicht erkennbar. Eine einheitliche Übersicht über Versuche, Blockierungen und Sensorereignisse über alle Unterseiten hinweg macht den Unterschied zwischen der Erkennung einer Kampagne und der Wahrnehmung von dreißig voneinander unabhängigen Störfaktoren aus.

Die offizielle Dokumentation zur WordPress-Sicherheitsoptimierung behandelt die Grundlagen zu Dateiberechtigungen und Konfiguration, die für jede Installation gelten; die oben genannten Punkte stellen die zusätzlichen Aspekte dar, die bei einer Multisite-Installation hinzukommen.

So führen Sie mit fünf Befehlen eine Überprüfung eines bestehenden Netzwerks durch

Bevor Sie Änderungen vornehmen, sollten Sie den aktuellen Zustand erfassen. Auf einem Server mit WP-CLI beantworten fünf Befehle die Fragen, mit denen jede Sicherheitsüberprüfung einer WordPress-Multisite-Installation beginnt:

wp site list --fields=blog_id,url,last_updated — jede Unterseite mit dem Datum der letzten Inhaltsänderung. Unterseiten, die seit einem Jahr nicht mehr aktualisiert wurden, kommen für Punkt 7 der Checkliste in Frage.
wp super-admin list — die Konten, mit denen Sie überall alles erledigen können. Falls Sie diese Liste überrascht, sollten Sie das noch heute ändern.
wp plugin list --fields=name,status,update — Netzwerkaktivierte Plugins, selektiv aktive Plugins und ausstehende Updates auf einen Blick. Alles, was als inaktiv aufgeführt ist, befindet sich weiterhin als Code auf der Festplatte.
wp user list --role=administrator --url=SUBSITE-URL — pro Unterwebsite, wer die Administratorrolle innehat. Führen Sie dies für jede Unterwebsite durch und vergleichen Sie die Ergebnisse mit den Personen, die dort tatsächlich tätig sind.
wp core verify-checksums — vergleicht jede Kern-Datei mit den offiziellen WordPress-Prüfsummen und meldet Dateien, die hinzugefügt oder geändert wurden. Ein einwandfreies Ergebnis schließt die häufigste Methode zur Persistenz nach einer Kompromittierung aus.

Führen Sie die Prüfung nach jeder strukturellen Änderung am Netzwerk erneut durch – sei es eine neue Unterseite, eine neue Stelle mit Administratorrechten oder eine neu zugeordnete Domain. Die Liste der Super-Administratoren und die Liste der veralteten Unterseiten sind die beiden Punkte, die sich zwischen den Prüfungen am häufigsten ändern.

Warum Sicherheits-Plugins, die auf einzelne Websites ausgerichtet sind, in einem Netzwerk versagen

Die meisten WordPress-Sicherheits-Plugins wurden für einzelne Websites entwickelt. Werden sie in einem Multisite-Netzwerk installiert, speichern sie ihre Versuchs-Zähler, Sperrlisten und Protokolle in der Regel in website-spezifischen Datenbanktabellen – jede Unterwebsite schützt sich somit eigenständig.

Dieses Modell versagt bereits bei dem kostengünstigsten Angriff. Ein Brute-Force-Angreifer, der vier Logins auf jeweils zehn Unterseiten verteilt, bleibt unterhalb des Schwellenwerts von fünf pro Seite und führt gleichzeitig vierzig Versuche auf dieselbe gemeinsame Benutzertabelle durch. Keine einzelne Unterseite verzeichnet jemals genügend Aktivität, um zu reagieren, sodass nirgendwo eine Sperre verhängt wird.

Der zweite Mangel ist betrieblicher Natur: Dreißig Unterseiten bedeuten dreißig separate Protokollanzeigen. In der Praxis liest diese niemand, weshalb kompromittierte Unterseiten in großen Netzwerken so oft von Außenstehenden und nicht vom Betreiber entdeckt werden.

Wie ReportedIP Hive einen gemeinsamen Bedrohungsstatus für das gesamte Netzwerk bereitstellt

ReportedIP Hive – mit 16 Attack Sensors, vier 2FA-Methoden, progressiver Blockierung und opt-in-basierter Threat Intelligence aus der Community – ist seit Version 2.0 vollständig Multisite-kompatibel; die aktuelle Version ist 2.1.37. Bei Multisite-Installationen wird das Plugin ausschließlich netzwerkweit aktiviert; die Aktivierung auf Einzelseiten-Ebene wird von WordPress ausgeblendet.

Alle Plugin-Tabellen befinden sich auf Netzwerkebene über $wpdb->base_prefix, wobei eine Spalte blog_id festhält, wo das jeweilige Ereignis stattgefunden hat. Das Ergebnis ist ein gemeinsamer Bedrohungsstatus: Login-Fehler von derselben IP-Adresse über verschiedene Unterseiten hinweg werden in einem zentralen Versuchszähler zusammengefasst, und ein Eintrag in der Sperrtabelle sperrt die IP-Adresse sofort für alle Unterseiten. Der verteilte Angreifer aus dem obigen Beispiel überschreitet die Schwelle beim vierten Versuch insgesamt – statt nie.

Die gleiche Aggregation gilt auch für die anderen Sensoren: XML-RPC-Missbrauch, REST-Rate Limiting, Schutz vor User Enumeration, Erkennung von 404-Scannern und die anfragenüberprüfende Web Application Firewall – alle werden pro IP-Adresse und Netzwerk gezählt, nicht pro Unterseite. Blockierte Antworten sind cachesicher, sodass ein Caching-Plugin kein gespeichertes HTML an eine blockierte Adresse auf geschützten Pfaden ausliefern kann.

Netzwerke, die im Community-Modus betrieben werden, überprüfen Besucher zusätzlich anhand gemeinsamer Informationen: Seit Juli 2026 umfasst die „ReportedIP“-Blacklist mehr als 20.000 IP-Adressen mit hoher Einstufung als Bedrohung; somit kann eine Adresse, die andere Community-Websites angegriffen hat, bereits vor dem ersten Passwortversuch abgelehnt werden. Netzwerke, die vollständig offline bleiben müssen, verwenden den „Local Shield“-Modus und behalten alle hier beschriebenen Mechanismen bei, mit Ausnahme der gemeinsam genutzten Reputationsdaten.

Welche Zugriffsrechte Super-Administratoren und Website-Administratoren jeweils haben

Super-Administratoren verwalten die Netzwerkeinstellungen und werden bedingungslos zur Einrichtung der 2FA verpflichtet – der Schalter reportedip_hive_2fa_enforce_super_admins ist standardmäßig aktiviert. Site-Administratoren einer Unterseite erhalten eine schreibgeschützte Ansicht für „Status“ und „Protokolle“ sowie eine bearbeitbare Einstellungsseite mit genau zwei Übersteuerungsmöglichkeiten: dem site-spezifischen Frontend-2FA-Slug und zusätzlichen Durchsetzungsrollen. Ein Seitenadministrator kann eine Rolle zur 2FA-Durchsetzung hinzufügen, darf jedoch keine Rolle entfernen, die vom Netzwerk vorgeschrieben ist – die Flexibilität auf der Unterseite kann die Richtlinie verschärfen, jedoch niemals lockern.

Das Cookie für Trusted Devices ist auf den Netzwerk-Cookie-Pfad beschränkt, sodass eine einmalige Bestätigung „Dieses Gerät vertrauen“ für alle Unterseiten gilt, anstatt auf jeder einzelnen Seite erneut abgefragt zu werden. Geplante Aufgaben werden ausschließlich auf der Hauptseite ausgeführt und durch is_main_site() abgesichert, wodurch doppelte Cron-Durchläufe pro Unterseite vermieden werden.

Umstellung einer bestehenden Einzel-Website auf ein geschütztes Netzwerk

Eine Hive-Installation auf einer einzelnen Website, die Teil eines Netzwerks wird, wird beim ersten Besuch eines Administrators automatisch migriert. Die einzige Schemaänderung besteht in einer hinzugefügten Spalte blog_id mit dem Standardwert 1 – es werden keine Daten verschoben oder neu geschrieben. Spezielle Serviceklassen für Schema, Migration und Optionsweiterleitung vermitteln jeden für den Multisite-Betrieb relevanten Zugriff, und sowohl das Ein-Standort- als auch das Multisite-Verhalten werden durch PHPUnit-Suiten abgedeckt, die bei jedem Commit ausgeführt werden.

Was kostet ein netzwerkweiter Schutz?

Der Erkennungskern ist in jedem Tarif kostenlos enthalten: Sensoren, Firewall-Baseline, progressive Blockierung und die zentralen 2FA-Methoden funktionieren netzwerkweit ohne zusätzliche Kosten. Die kostenpflichtigen Tarife bieten zusätzlich verwaltete Relays und den Komfort eines Multi-Domain-Dashboards – 3 Domains im Professional-Tarif, 15 im Business-Tarif und ein individuelles Limit im Enterprise-Tarif. Einzelheiten zu den Tarifen finden Sie auf der Produktseite des Plugins.

Häufig gestellte Fragen

Wird durch eine gehackte Unterseite das gesamte WordPress-Netzwerk gefährdet?

In der Praxis ja. Alle Unterwebsites nutzen dieselbe Codebasis, dieselbe Datenbank und dieselbe Benutzertabelle und werden im selben PHP-Prozess ausgeführt. Die Ausführung von Code oder eine SQL Injection auf einer beliebigen Unterwebsite greift auf Netzwerkdaten zu; aus diesem Grund werden bei der Multisite-Absicherung alle Unterwebsites als Teil eines einzigen Sicherheitsperimeters behandelt.

Sollten Sicherheits-Plugins in einem Multisite-Netzwerk netzwerkweit aktiviert werden?

Ja – ein Schutzmechanismus, den einzelne Seitenadministratoren deaktivieren können, stellt keine Netzwerkrichtlinie dar. ReportedIP Hive setzt dies konzeptionell durch: In einer Multisite-Umgebung kann die Funktion nur auf Netzwerkebene aktiviert werden, sodass keine Unterseite die Überwachung oder Blockierung deaktivieren kann.

Wie viele Super-Administratoren sollte ein Multisite-Netzwerk haben?

So wenige, wie es der Betrieb zulässt – in der Regel zwei oder drei namentlich benannte Personen. Jeder Super-Admin durchläuft alle Berechtigungsprüfungen auf jeder Unterseite, sodass jedes zusätzliche Konto das Phishing-Risiko für das gesamte Netzwerk vervielfacht. Alle sollten eine phishing-resistente Zwei-Faktor-Authentifizierung verwenden.

Gilt eine IP-Sperre für alle Unterseiten?

Bei Tabellen auf Netzwerkebene ist dies der Fall. In ReportedIP Hive sperrt eine einzige Zeile in der Blockiert-Tabelle die IP-Adresse gleichzeitig für alle Unterseiten, und Zugriffe auf verschiedene Unterseiten werden in einem Zähler zusammengefasst – ein Botnetz, das zwischen den Unterseiten wechselt, wird als eine einzige Kampagne gezählt.

Sicherheit bei WordPress Multisite: Ein Leitfaden zur Absicherung des Netzwerks