TL;DR. Auf WordPress Multisite ist die bekannte Einstellung „Jeder kann sich registrieren“ wirkungslos. Maßgeblich ist eine Netzwerk-Option, die viele Sicherheitswerkzeuge gar nicht lesen. Sie melden dann „Registrierung geschlossen“ auf einem Netzwerk, bei dem sich jeder anmelden kann.
| Das Problem | Multisite ignoriert die Site-Option users_can_register. Die Registrierung steuert die Netzwerk-Option registration mit 4 Werten: none, user, blog, all. |
| Die Folge | Ein Werkzeug, das nur die Site-Option liest, bescheinigt einem offenen Netzwerk eine geschlossene Registrierung. Der Befund ist grün und falsch. |
| Selbst prüfen | Netzwerkverwaltung, Einstellungen, „Neue Websites erlauben“. Oder per WP-CLI: wp site option get registration. |
| Unser Plugin | Der kostenlose Security Check Report hatte genau diesen Fehler bis Version 2.3.0. Wir haben ihn behoben und beschreiben ihn hier offen. |
Veröffentlicht: 06.09.2026 · Letzte Aktualisierung: 06.09.2026
Stellen Sie sich ein WordPress-Netzwerk mit 30 Subsites vor. Der Sicherheitsreport meldet: „Registrierung geschlossen, alles in Ordnung.“ Gleichzeitig kann jeder Besucher unter wp-signup.php ein Benutzerkonto anlegen, denn der Netzwerkadministrator hat die Anmeldung vor Jahren für ein Projekt geöffnet und nie wieder geschlossen. Beides ist gleichzeitig wahr, weil das Prüfwerkzeug und WordPress an 2 verschiedenen Stellen nachsehen.
Dieses Missverständnis ist kein Einzelfall eines Herstellers. Es folgt aus einer Eigenheit von WordPress Multisite, die selbst erfahrene Entwickler überrascht: Die Registrierungseinstellung, die jeder kennt, ist im Netzwerkbetrieb schlicht ohne Funktion.
Zwei Optionen mit demselben Thema, aber nur eine zählt
In einer normalen WordPress-Installation steuert die Option users_can_register die Registrierung. Sie entspricht der Checkbox „Jeder kann sich registrieren“ unter Einstellungen, Allgemein. Ruft jemand wp-login.php mit der Aktion register auf, prüft WordPress genau diese Option und zeigt das Formular oder eben nicht.
Auf Multisite läuft derselbe Aufruf völlig anders. WordPress prüft zuerst, ob es sich um ein Netzwerk handelt, und leitet dann sofort auf wp-signup.php weiter, ohne users_can_register auch nur anzusehen. Der Code in wp-login.php ist eindeutig: bei is_multisite() folgt unmittelbar die Weiterleitung. Und wp-signup.php trifft seine Entscheidung anhand einer ganz anderen Einstellung:
$active_signup = get_site_option( 'registration', 'none' );get_site_option() liest eine Netzwerk-Option, keine Site-Option. Die Option heißt registration, wird in der Netzwerkverwaltung unter Einstellungen gepflegt und kennt 4 Werte:
- none: Registrierung geschlossen. Der Standardwert.
- user: Jeder Besucher kann ein Benutzerkonto anlegen.
- blog: Bestehende Benutzer können neue Sites im Netzwerk anlegen.
- all: Jeder Besucher kann Konto und Site anlegen.
Die Checkbox der einzelnen Subsite kann dabei zeigen, was sie will. Steht die Netzwerk-Option auf user oder all, ist die Anmeldung offen. Steht sie auf none, ist sie zu. Die Site-Option users_can_register existiert in der Datenbank jeder Subsite weiter, sie wird für den Anmeldevorgang nur nie befragt.
Warum Prüfwerkzeuge hier systematisch danebengreifen
Die Prüfung „Ist die Registrierung offen?“ gehört zum Standardrepertoire jedes WordPress-Sicherheitswerkzeugs, denn eine offene Registrierung ist ein beliebter Ausgangspunkt für Spam-Konten und, in Kombination mit einer unglücklich gewählten Standardrolle, für echte Rechteausweitung. Die naheliegende Implementierung ist eine Zeile: get_option( 'users_can_register' ) lesen, fertig.
Auf einer Einzelinstallation ist das korrekt. Auf Multisite liefert dieselbe Zeile eine Antwort auf eine Frage, die WordPress dort gar nicht stellt. Das Ergebnis ist der gefährlichste Typ von Fehlbefund: ein falsches Grün. Ein Fehlalarm fällt irgendwann auf, weil jemand der Meldung nachgeht und nichts findet. Ein falsches Grün fällt nicht auf, denn niemand geht einem bestandenen Test nach. Das offene Netzwerk bleibt offen, mit Prüfsiegel.
Multisite ist dabei kein exotischer Sonderfall. Universitäten, Hochschulen, Filialbetriebe, Agenturen mit Kundennetzwerken und große Publisher betreiben ihre WordPress-Landschaften als Netzwerk. Gerade dort, wo eine Installation Dutzende oder Hunderte Sites trägt, wiegt ein unbemerkt offenes Anmeldeformular schwerer als auf einem einzelnen Blog.
Dieser Fehler steckte in unserem eigenen Plugin
Wir schreiben das nicht als Beobachtung über andere. Unser kostenloses Audit-Plugin Security Check Report hatte bis einschließlich Version 2.2.2 exakt diesen Fehler: Die Registrierungsprüfung las die Site-Option, auch im Netzwerkbetrieb. Ein Multisite-Netzwerk mit offener Anmeldung bekam die Meldung „Registrierung geschlossen“.
Mit Version 2.3.0 haben wir das behoben. Der Eintrag steht so im Changelog, und der Quelltext auf GitHub zeigt die Korrektur: Auf Multisite liest die Prüfung jetzt die Netzwerk-Option registration und benennt bei user, blog und all konkret, was das Netzwerk gerade erlaubt. Zusätzlich fließt die Standardrolle für neue Konten in die Bewertung ein, denn eine offene Registrierung mit der Rolle Abonnent ist ein anderes Risiko als eine mit erweiterten Rechten.
Die Fehlersuche hat noch 2 verwandte Multisite-Probleme zutage gefördert, beide ebenfalls in 2.3.0 behoben. Erstens fehlten Netzwerkadministratoren in den Konten-Prüfungen: Sie besitzen auf jeder Site sämtliche Rechte unabhängig von ihrer dort eingetragenen Rolle, eine reine Rollenabfrage findet sie deshalb nicht. Zweitens verglich die Tabellenpräfix-Prüfung das Präfix der Subsite, wodurch jede Subsite wie eine Installation mit individuellem Präfix aussah. Seitdem läuft unsere Testsuite vor jedem Release verpflichtend auch gegen eine Multisite-Umgebung, damit diese Klasse von Fehlern nicht zurückkommt.
Warum wir das so offen aufschreiben: Ein Audit-Werkzeug lebt davon, dass seine Befunde stimmen. Dazu gehört, Fehler zu benennen, wenn sie gefunden werden, und zu zeigen, was sich strukturell geändert hat, damit sie nicht wieder passieren. Ein Changelog, in dem nie etwas repariert wird, ist kein Qualitätsmerkmal, sondern ein Schweigegelübde.
So prüfen Sie Ihr Netzwerk selbst
Sie brauchen dafür kein Werkzeug, 3 Wege führen zum Ergebnis:
- Netzwerkverwaltung: Melden Sie sich als Netzwerkadministrator an und öffnen Sie Meine Websites, Netzwerkverwaltung, Einstellungen. Der Abschnitt zur Registrierung zeigt die 4 Optionen als Radiobuttons. Alles außer „Registrierung ist deaktiviert“ bedeutet: Es ist etwas offen.
- WP-CLI: Der Befehl
wp site option get registrationliefert den aktiven Wert direkt aus der Datenbank. Kommt none zurück, ist die Anmeldung geschlossen. - Von außen: Rufen Sie wp-signup.php Ihrer Hauptdomain im Privatmodus des Browsers auf. Sehen Sie ein Anmeldeformular, ist die Registrierung offen, unabhängig davon, was irgendein Report behauptet.
Wenn die Registrierung bewusst offen sein soll, etwa für ein Community-Projekt, prüfen Sie 2 flankierende Punkte: die Standardrolle für neue Benutzer (Einstellungen, Allgemein auf der jeweiligen Site) und einen Spam-Schutz für das Anmeldeformular. Offen und kontrolliert ist ein legitimer Zustand. Offen und vergessen ist das Problem.
Was das über Prüfwerkzeuge im Allgemeinen sagt
Die Registrierungsprüfung ist nur das deutlichste Beispiel für ein Muster: Multisite ist kein Einzelblog mit mehr Tabellen, sondern verschiebt die Autorität über zentrale Einstellungen von der Site auf das Netzwerk. Ein Werkzeug, das für Einzelinstallationen entwickelt und auf Multisite nur „auch installierbar“ ist, prüft dort unter Umständen die falsche Ebene, und zwar bei bestandenen wie bei durchgefallenen Tests.
Wenn Sie ein Netzwerk betreiben, lohnt sich deshalb eine Frage an jedes Audit-Werkzeug: Wird Multisite explizit unterstützt und getestet, oder läuft es dort nur zufällig? Ein Blick ins Changelog hilft. Werkzeuge, die Multisite ernst nehmen, erwähnen es, weil es Arbeit macht.
Häufige Fragen
Ich habe die Checkbox „Jeder kann sich registrieren“ auf einer Subsite deaktiviert. Reicht das nicht?
Nein. Auf Multisite hat diese Checkbox keine Wirkung auf den Anmeldevorgang. WordPress leitet Registrierungsversuche auf wp-signup.php um und entscheidet dort ausschließlich anhand der Netzwerk-Option registration. Geschlossen ist die Anmeldung nur, wenn diese Option auf none steht.
Gilt der Unterschied auch für einzelne Subsites, oder nur für die Hauptseite?
Die Option registration gilt für das gesamte Netzwerk. Es gibt in WordPress selbst keine Möglichkeit, die Registrierung nur für einzelne Subsites zu öffnen oder zu schließen. Wer das braucht, muss es über eigene Entwicklung oder Plugins lösen, die in den Anmeldeprozess eingreifen.
Woher weiß ich, ob mein Sicherheits-Plugin die richtige Option prüft?
Der verlässlichste Test ist der von außen: Öffnen Sie wp-signup.php im Privatmodus und vergleichen Sie das, was Sie sehen, mit dem, was der Report behauptet. Bei quelloffenen Werkzeugen können Sie zusätzlich im Code nach get_site_option( ‚registration‘ ) suchen. Taucht dort nur users_can_register auf, prüft das Werkzeug auf Multisite die falsche Ebene.
Prüft Security Check Report noch mehr Multisite-Besonderheiten?
Ja. Seit Version 2.3.0 berücksichtigt das Plugin Netzwerkadministratoren in den Konten-, Zwei-Faktor- und Application-Password-Prüfungen und wertet das Tabellenpräfix auf Netzwerkebene aus. Die Testsuite läuft vor jedem Release auch gegen Multisite. Das Plugin ist kostenlos, rein lesend, ohne Telemetrie und liegt quelloffen im WordPress-Verzeichnis und auf GitHub.
Weiterführend
Wie ein Konfigurations-Audit in eine umfassende Sicherheitsstrategie passt und welche Maßnahmen wir für betreute WordPress-Sites standardmäßig umsetzen, lesen Sie auf unserer Seite zur WordPress-Sicherheit. Wenn über eine offene Registrierung bereits fremde Konten oder Schadcode auf Ihre Site gelangt sind, hilft unsere Soforthilfe bei gehackten WordPress-Websites.