2026 WordPress 7.2 Multisite-Berechtigungen: Kann sudo mode Websites isolieren?

Die offizielle WordPress-Roadmap nennt für Version 7.2 Anfang Dezember 2026 als geplanten Veröffentlichungstermin; der dort beschriebene sudo mode soll bestimmte sensible Aktionen mit einer erneuten Identitätsprüfung absichern, ist aber noch keine zugesicherte Funktion der endgültigen Version (Roadmap zu WordPress 7.2). Für die Frage der WordPress-7.2-Multisite-Berechtigungen lautet die Entscheidung schon jetzt: Nein, sudo mode isoliert keine Websites. Prüfen Sie diese Woche, welche Personen, Datenbanken, Dateien und PHP-Prozesse Ihre Websites gemeinsam nutzen.

Dieser Beitrag ist für Sie gedacht, wenn Sie mehrere eigenständige WordPress-Websites verwalten und entscheiden müssen, ob sie auf einer Installation zusammengehören. Auch als technische Leitung eines grenzüberschreitenden E-Commerce-Angebots können Sie damit gemeinsam genutzte Administratorkonten und Zugänge prüfen. Wenn Sie Websites für mehrere Kunden betreuen, hilft Ihnen die Abwägung, Vertrauen, Zuständigkeiten und mögliche Ausfälle gegeneinanderzustellen.

Stand: 01.11.2026. Der Funktionsstatus und die Terminangabe wurden anhand der offiziellen WordPress-Roadmap und der Dokumentation geprüft. Da die Roadmap ausdrücklich keine endgültige Funktionszusage darstellt, sollten Sie sie vor einer konkreten Update-Entscheidung erneut kontrollieren.

Was sudo mode tatsächlich absichern soll

Eine erneute Identitätsprüfung und eine technische Trennung verfolgen unterschiedliche Sicherheitsziele. Bei einer erneuten Prüfung muss ein angemeldeter Benutzer seine Identität vor einer sensiblen Aktion nochmals bestätigen. Das kann das Risiko verringern, dass jemand eine noch offene Sitzung für eine besonders folgenreiche Änderung missbraucht. Es ändert aber nicht automatisch, auf welche Dateien oder Datenbanken der angemeldete Benutzer oder der ausführende PHP-Prozess zugreifen kann.

Die Roadmap beschreibt sudo mode als frühe Arbeit an einer erneuten Authentifizierung für bestimmte Aktionen mit hohen Berechtigungen. Gleichzeitig hält sie fest, dass die aufgeführten Vorhaben nicht zwangsläufig alle in der endgültigen Version landen (Projektseite zu WordPress 7.2). Behandeln Sie den Modus daher als geplante Richtung, nicht als bereits verfügbare Schutzschicht. Auch wenn die Funktion wie beschrieben veröffentlicht wird, wäre daraus keine Abschirmung zwischen Websites abzuleiten.

Für Ihre Entscheidung zählen zwei getrennte Fragen:

• Wer darf die Aktion ausführen? Das betrifft Anmeldung, Rollen und erneute Bestätigung.
• Welche Ressourcen kann die Aktion erreichen? Das betrifft Dateien, Datenbankzugänge, Plugins, Prozesse und Betriebssystemrechte.

Eine neue Bestätigung kann die erste Frage beeinflussen. Für die zweite brauchen Sie weiterhin eine passende Installations- und Systemarchitektur.

WordPress-7.2-Multisite-Berechtigungen nach Ebenen prüfen

„Administrator“ bedeutet nicht auf jeder Ebene dasselbe. Im WordPress-Backend gibt es Rollen für einzelne Websites. In einer Multisite-Installation kann zusätzlich ein Netzwerk-Superadministrator Verwaltungsrechte für das Netzwerk besitzen. Außerhalb von WordPress gelten wiederum Konten und Rechte des Servers, etwa für Dateiänderungen, Bereitstellungen und den Start von PHP-Prozessen.

Diese Ebenen lassen sich nicht gegenseitig ersetzen. Ein Website-Administrator ist nicht automatisch ein Serveradministrator. Umgekehrt kann ein Systemkonto, unter dem PHP läuft, Dateien verändern, auf die die WordPress-Rolle des gerade angemeldeten Benutzers keinen direkten Zugriff bietet. Wenn Ihre Bereitstellung oder ein Plugin mit weitreichenden Dateirechten arbeitet, entscheidet die technische Konfiguration darüber, welche Änderungen tatsächlich möglich sind.

Gehen Sie bei gemeinsam genutzten Konten zuerst diesen Punkten nach:

• Verwenden Mitarbeitende ein persönliches Konto oder ein gemeinsames Administratorkonto?
• Gibt es Personen, die für mehrere Websites zuständig sind, obwohl sie nur für eine zuständig sein sollten?
• Wer kann Netzwerk-Einstellungen und Plugins für eine Multisite-Installation verwalten?
• Wer kann Serverzugänge, Datenbankpasswörter oder Bereitstellungsprozesse ändern?
• Werden Zugangsdaten nach einem Team- oder Kundenwechsel entzogen und ersetzt?

Ein gemeinsames Konto macht die Nachvollziehbarkeit schwieriger: Wenn mehrere Personen mit denselben Zugangsdaten arbeiten, können Sie Änderungen nicht zuverlässig einer Person zuordnen. Zu weit gefasste Rechte erhöhen außerdem die Zahl der Stellen, an denen ein Bedienfehler oder kompromittierter Zugang mehrere Websites betreffen kann. Trennen Sie Rollen daher nach tatsächlicher Zuständigkeit und halten Sie Änderungen an Zugängen nachvollziehbar fest.

Gemeinsamer Code und Plugins als Risikogrenze

WordPress Multisite bündelt mehrere Websites in einer Installation. Das erleichtert eine zentrale Verwaltung, bedeutet aber auch, dass die Websites wichtige Teile der Anwendungsumgebung gemeinsam nutzen. Dazu gehören WordPress-Core-Dateien sowie die für die Installation verfügbaren Themes und Plugins. Eine einzelne Website kann andere Inhalte und Website-Einstellungen haben, ohne deshalb eine eigene Kopie des Codes zu erhalten.

Das ist bei Websites eines Unternehmens mit gemeinsamer Administration häufig ein sinnvoller Kompromiss. Eine zentrale Aktualisierung kann den Wartungsaufwand verringern. Umgekehrt kann eine fehlerhafte Erweiterung, eine unpassende Änderung oder ein kompromittierter Verwaltungszugang Auswirkungen auf die gemeinsame Installation haben. Die erneut bestätigte Identität vor einer Aktion macht Plugin-Code nicht ungefährlich und verhindert nicht, dass bereits autorisierter Code innerhalb seiner technischen Rechte auf gemeinsam erreichbare Ressourcen einwirkt.

Mehrere eigenständige Installationen erlauben es, Code und Aktualisierungen getrennt zu verwalten. Sie können Erweiterungen oder Änderungen für eine Website prüfen, ohne sie zwingend zeitgleich für alle anderen einzuführen. Dafür wachsen die Aufgaben: Sie müssen Aktualisierungen, Sicherheitsprüfungen, Konfigurationen und Wiederherstellung je Installation planen. Bei unterschiedlichen Teams oder Kunden ist dieser zusätzliche Aufwand oft der Preis für klarere Zuständigkeiten und kleinere gemeinsame Fehlerbereiche.

Prüfen Sie deshalb nicht nur, ob eine Erweiterung „installiert“ ist, sondern auch, wer sie ändern oder aktualisieren darf, auf welchen Installationen sie eingesetzt wird und welche Dateirechte der Webprozess besitzt. Eine Trennung auf WordPress-Ebene bringt wenig, wenn ein gemeinsames, weit berechtigtes Systemkonto weiterhin sämtliche Installationsverzeichnisse verändern kann.

Datenbank und Dateisystem als getrennte Grenzen

Die offizielle Dokumentation beschreibt Multisite als eine einzelne WordPress-Installation mit einer Datenbankinstanz (Multisite-Administration). Das ist eine konkrete Architekturangabe und keine Aussage, dass jede Website eine vollständig separate Datenbank erhält. WordPress bietet daneben auch Szenarien mit mehreren eigenständigen Installationen und getrennten Datenbanken (Dokumentation zu mehreren WordPress-Instanzen).

Mit getrennten Datenbanken und jeweils eigenen Datenbankbenutzern können Sie Zugangsdaten gezielter zuordnen. Ein Benutzer, der nur für eine Datenbank berechtigt ist, braucht nicht automatisch Zugang zu den Datenbankinhalten der anderen Installation. Das hilft bei der Verwaltung und verringert den Umfang eines Fehlers, wenn Zugangsdaten offengelegt werden. Es ersetzt aber weder eine Sicherung noch die Prüfung, welche Systemprozesse auf die Datenbank zugreifen dürfen.

Auch Dateirechte verdienen eine eigene Prüfung. Die WordPress-Dokumentation unterscheidet zwischen Eigentümerschaft und Berechtigungen für Dateien und Verzeichnisse; die passende Konfiguration hängt davon ab, wie Dateien bearbeitet und aktualisiert werden (WordPress-Dokumentation zu Dateiberechtigungen). Wenn mehrere Installationen denselben PHP-Benutzer oder ein gemeinsam genutztes Deployment-Konto verwenden, kann eine Trennung der Datenbanken allein die Dateigrenze nicht herstellen.

Bewerten Sie die Grenzen daher einzeln: WordPress-Rollen regeln den Zugriff im Anwendungsbereich, Datenbankbenutzer begrenzen Datenbankzugänge, Dateirechte steuern den Zugriff auf Dateien und Verzeichnisse, und Betriebssystemkonten bestimmen, was laufende Prozesse ausführen oder verändern können. Erst wenn diese Grenzen zur Vertrauenslage Ihrer Websites passen, können Sie von einer belastbaren Trennung sprechen.

Architekturvergleich nach Vertrauenslage

Die passende Wahl hängt nicht allein von der Zahl der Websites ab. Fragen Sie, ob dieselben Personen alle Websites administrieren, ob die Codestrategie gemeinsam ist und wie groß der Schaden wäre, wenn eine Installation oder ein Zugang kompromittiert wird.

Wählen Sie Multisite, wenn Websites tatsächlich zusammengehören: gleiche Verantwortliche, abgestimmte Aktualisierungen und ein akzeptabler gemeinsamer Fehlerbereich. Entscheiden Sie sich eher für eigenständige Installationen, wenn Kundengruppen, Teams oder Änderungen getrennt verwaltet werden müssen. Wenn eine Website einem anderen Vertrauensniveau unterliegt oder ein Vorfall nicht auf andere Installationen übergreifen darf, reicht eine Trennung innerhalb derselben WordPress-Verwaltung möglicherweise nicht aus. Prüfen Sie dann zusätzlich die Laufzeit- und Systemgrenzen.

Diese Optionen sind keine Garantie gegen Sicherheitsvorfälle. Eine getrennte Installation mit gemeinsamem, weitreichendem PHP-Konto oder breit nutzbaren Zugangsdaten kann weiterhin einen großen gemeinsamen Risikobereich haben. Umgekehrt kann Multisite für eng zusammengehörige Websites einfacher zu betreiben sein, ohne dass dadurch jede Website identische Inhalte oder Backend-Rollen erhalten muss.

Umsetzbare Prüfung vor der Entscheidung

Arbeiten Sie die folgenden Schritte ab, bevor Sie Websites zusammenführen oder eine Installation aufteilen. Halten Sie für jede Website fest, wer zuständig ist, welche Zugänge verwendet werden und welche Systeme sie gemeinsam nutzt.

1. Websites und Verantwortliche erfassen. Notieren Sie pro Website den fachlichen Eigentümer, die administrativen Personen und die Personen mit Serverzugriff. Markieren Sie Kunden- oder Teamgrenzen ausdrücklich, statt alle Websites pauschal als ein Netzwerk zu behandeln.

2. Gemeinsam genutzte Konten finden. Prüfen Sie WordPress-Benutzer, Netzwerk-Superadministratoren, Datenbankzugänge sowie Konten für SSH und Bereitstellungen. Ersetzen Sie gemeinsame persönliche Zugangsdaten durch nachvollziehbare, individuelle Konten, wo es die Arbeitsabläufe erlauben.

3. Code und Aktualisierungspfade prüfen. Erfassen Sie, welche Installationen Core, Themes und Plugins gemeinsam nutzen. Bestimmen Sie, wer Erweiterungen installieren oder ändern kann und ob eine Änderung für eine Website automatisch andere Websites betrifft.

4. Datenbankzugriffe abgleichen. Dokumentieren Sie je Installation die verwendete Datenbank und den Datenbankbenutzer. Prüfen Sie, ob die Berechtigungen auf den erforderlichen Zugriff begrenzt sind. Bewerten Sie getrennte Datenbanken als Zugangsdaten- und Verwaltungsgrenze, nicht als vollständige Systemisolation.

5. Dateieigentümer und PHP-Ausführung prüfen. Vergleichen Sie Eigentümer und Schreibrechte der Installationsverzeichnisse mit dem PHP-Benutzer und den Bereitstellungsprozessen. Die WordPress-Anleitung zu Dateiberechtigungen kann Ihnen dabei helfen, die Rechte der jeweiligen Betriebsweise zuzuordnen. Wenn ein Prozess Dateien aller Websites ändern kann, dokumentieren Sie dieses verbleibende gemeinsame Risiko.

6. Folgen eines Vorfalls durchspielen. Fragen Sie für jede gemeinsame Komponente, was bei einer kompromittierten Administratorsitzung, einem fehlerhaften Plugin oder einem offengelegten Datenbankzugang passieren könnte. Wenn der mögliche Schaden für eine andere Website nicht akzeptabel ist, planen Sie eine stärkere Trennung und testen Sie den Wiederherstellungsweg.

7. Betrieb und Wiederherstellung festlegen. Bestimmen Sie, wer Aktualisierungen freigibt, wo Sicherungen liegen und wie Sie eine einzelne Installation wiederherstellen. Prüfen Sie die Schritte regelmäßig und halten Sie fest, welche Websites von derselben Änderung oder demselben Wiederherstellungsvorgang betroffen wären.

Als konkreter Fall: Betreiben Sie mehrere Marken-Websites mit demselben Team, derselben Veröffentlichungsfreigabe und weitgehend gemeinsamem Code, kann Multisite den Alltag vereinfachen. Betreuen Sie dagegen Kunden mit getrennten Administratoren, unterschiedlichen Plugin-Freigaben und eigenen Datenzugängen, ist eine Aufteilung in eigenständige Installationen oft leichter nachvollziehbar. Wenn zusätzlich die Folgen eines Vorfalls begrenzt werden müssen, reicht die Trennung der Datenbank möglicherweise nicht; prüfen Sie dann auch PHP-Benutzer, Dateirechte und die Laufzeitumgebung.

Entscheiden Sie nach dieser Prüfung nicht auf Basis einer angekündigten Anmeldefunktion. Verwenden Sie sudo mode, falls es später wie geplant veröffentlicht wird, als mögliche zusätzliche Kontrolle für bestimmte Aktionen. Verlassen Sie sich für getrennte Websites jedoch auf die tatsächlich vorhandenen Grenzen Ihrer Architektur. Vor einem Wechsel sollten Sie außerdem die Zugangs- und Verwaltungsinformationen sowie die Hinweise zur Bereitstellung eines Servers prüfen, damit Anwendungsrechte und Serverzugriff nicht verwechselt werden.

Häufige Fragen zu sudo mode und Website-Trennung

Kann sudo mode in WordPress 7.2 verschiedene Websites voneinander abschirmen?

Nein. Die WordPress-Roadmap beschreibt sudo mode als geplante erneute Authentifizierung für bestimmte sensible Aktionen. Das bestätigt die Identität eines angemeldeten Benutzers, trennt aber weder Dateien noch Datenbanken, Plugins oder PHP-Prozesse zwischen Websites. Außerdem ist die Funktion laut Roadmap nicht garantiert Bestandteil der endgültigen Version. Planen Sie die Isolation daher anhand der tatsächlichen Installations- und Systemgrenzen.

Worin unterscheidet sich WordPress Multisite von mehreren eigenständigen Installationen?

Multisite verwaltet mehrere Websites innerhalb einer WordPress-Installation und einer Datenbankinstanz. Eigenständige Installationen besitzen getrennte WordPress-Dateien und können eigene Datenbanken und Datenbankbenutzer erhalten. Das erleichtert die Zuordnung von Zugangsdaten und Änderungen, schafft allein aber noch keine vollständige Betriebssystem-Isolation. Entscheidend ist auch, unter welchem Systemkonto PHP läuft und welche Dateien dieses Konto verändern darf.

Wie lassen sich Berechtigungen für mehrere WordPress-Websites auf einem Server aufteilen?

Erfassen Sie zunächst, welche Personen Administratorzugriff auf welche Websites benötigen, und vermeiden Sie gemeinsam genutzte Konten. Trennen Sie, wo es die Vertrauenslage verlangt, Installationen, Datenbankzugänge und Dateibäume. Prüfen Sie anschließend PHP-Ausführung, Dateieigentümer, Schreibrechte und Berechtigungen für Bereitstellungen. Wenn mehrere Websites weiterhin dasselbe weitreichende Systemkonto nutzen, bleibt ein gemeinsamer Risikobereich bestehen.

Braucht jede WordPress-Website eine eigene Datenbank und einen eigenen Datenbankbenutzer?

Nicht in jedem Fall: Multisite ist ausdrücklich auf eine gemeinsame WordPress-Installation mit einer Datenbankinstanz ausgelegt. Bei eigenständigen Installationen können separate Datenbanken und Datenbankbenutzer jedoch Zugangsdaten und Zuständigkeiten besser voneinander abgrenzen. Das ist eine sinnvolle Verwaltungsgrenze, aber kein vollständiger Schutz, wenn PHP-Prozesse oder Systemkonten weiterhin auf die Dateien und Datenbanken mehrerer Websites zugreifen können.

Wenn Ihre Bestandsaufnahme zeigt, dass Websites unterschiedliche Zuständigkeiten oder ein nicht akzeptables gemeinsames Ausfallrisiko haben, trennen Sie zunächst die Installationen und Zugänge, die tatsächlich geteilt werden. Für dauerhaft betriebene Websites kann ein unabhängiger AMD-Server von AmdMetal eine passende Grundlage sein, wenn Sie die Betriebssystem- und Dateigrenzen selbst konfigurieren möchten; der Server allein trennt Ihre WordPress-Websites nicht automatisch. AmdMetal bietet dafür eigenständige physische Server im japanischen Tokio. Prüfen Sie vor der Auswahl die Mietoptionen und Abrechnungsbedingungen und planen Sie die Website-Isolation weiterhin auf Ebene von WordPress, Datenbank, PHP und Betriebssystem.

Häufig gestellte Fragen