Theme und Plugin Editor mit DISALLOW_FILE_EDIT abschalten

In jeder Standard WordPress Installation gibt es zwei Seiten, die fast niemand absichtlich benutzt, die aber stillschweigend dafür sorgen, dass aus einem geklauten Admin Passwort ein kompletter Server Takeover wird. Design, Theme Datei Editor und Plugins, Plugin Datei Editor. Beide erlauben einem Admin, rohe PHP Dateien direkt im Browser innerhalb der Installation zu bearbeiten. Beide sind 2026 immer noch standardmäßig aktiv. Und beide sind komplett optional.

Diese Anleitung erklärt, warum das Abschalten der Editoren eine der wirkungsvollsten Hardening Änderungen ist, die du an einer WordPress Seite vornehmen kannst, wie die eine Zeile Config konkret aussieht und was danach passiert (inklusive ein paar Edge Cases, mit denen Leute überrascht werden).

Warum ist der eingebaute Editor ein Problem?

An einem normalen Tag benutzt ihn niemand. Theme Anpassungen laufen über ein Child Theme oder die Deploy Pipeline eines Entwicklers. Plugin Änderungen passieren auf Staging, nicht in Produktion. Der Editor sitzt einfach da, ungenutzt, erreichbar nur für Administratoren.

"Erreichbar nur für Administratoren" ist die Stelle, die im Angriffsfall bricht. Der typische WordPress Takeover hat überhaupt nichts mit Code Schwachstellen im Editor selbst zu tun. Er läuft so ab:

1. Ein Admin Passwort wird kompromittiert. Phishing, Passwort Wiederverwendung aus einem geleakten Dienst, ein Entwickler Laptop mit Malware, ein kompromittiertes Plugin, das Session Cookies abzieht. Such dir einen der üblichen Einstiegspunkte aus.
2. Der Angreifer loggt sich unter /wp-admin als echter Admin Benutzer ein. Aus Sicht von WordPress ist alles in Ordnung, das ist ein legitimer Login.
3. Der Angreifer geht direkt zu Design, Theme Datei Editor, öffnet die functions.php und kopiert sich oben einen kleinen PHP Backdoor rein.
4. Ab diesem Moment führt jeder Request auf die Startseite den Code des Angreifers aus. Er hat eine Remote Shell auf deinem Server.

Der Editor verwandelt "geklautes Admin Passwort" in "geklauten Webserver". Ohne ihn bleibt einem Angreifer mit Admin Passwort zwar immer noch Admin Zugriff (was schlimm genug ist), aber er muss den langsameren, lauteren Weg über den Upload eines bösartigen Plugin oder Theme Zips gehen, um Code Execution zu bekommen. Dieser zusätzliche Schritt ist eine zusätzliche Chance für ein Security Plugin, einen File Integrity Scanner oder eine WAF auf Server Ebene, den Upload zu bemerken und zu blockieren.

Das Aufwand Nutzen Verhältnis ist absurd. Den Editor benutzt eine winzige Minderheit der Admins ein paar mal pro Jahr. Das Risiko entsteht auf jeder Seite, auf der ein Credential Leak passiert. Den Editor abzuschalten ist eine dieser Änderungen, bei denen der Worst Case "jemand muss für eine fünfminütige Anpassung SFTP benutzen" ist, und der Best Case "der Takeover eskaliert nicht vom Passwort Leak zum Backdoor".

Der Fix: eine Zeile in der wp-config.php

WordPress bringt für genau diesen Fall eine eingebaute Konstante mit. Öffne die wp-config.php im WordPress Wurzelverzeichnis und füge folgende Zeile irgendwo oberhalb des Kommentars /* Das war's, Schluss mit dem Bearbeiten! Viel Spaß. */ ein:

define('DISALLOW_FILE_EDIT', true);

Speichern. Fertig. Der Theme Datei Editor unter Design und der Plugin Datei Editor unter Plugins verschwinden sofort für jeden Benutzer, auch für Administratoren. Die Seiten selbst geben einen Berechtigungsfehler aus, wenn man sie direkt per URL aufruft. Kein Plugin zu installieren, keine Einstellung zu pflegen, keine Kompatibilitäts Sorgen. Die Konstante ist seit WordPress 3.0 (veröffentlicht 2010) Teil des Cores und wird nicht verschwinden.

Was, wenn ich auch Plugin und Theme Uploads im Admin blockieren will?

WordPress hat eine strengere Schwester Konstante namens DISALLOW_FILE_MODS. Sie macht alles, was DISALLOW_FILE_EDIT macht, plus zusätzlich blockiert sie Plugin Uploads, Theme Uploads und Core Updates aus dem Admin Interface heraus. Sie wird genauso gesetzt:

define('DISALLOW_FILE_MODS', true);

Diese Konstante ist eine deutlich größere Verhaltensänderung. Mit aktivem DISALLOW_FILE_MODS kannst du Plugins, Themes und WordPress Core nicht mehr über das normale Admin Interface installieren oder aktualisieren. Alle Updates müssen von woanders kommen: WP CLI, eine Deploy Pipeline, ein SFTP Upload oder das zentrale Dashboard eines Managed Hosters.

Für die meisten Seiten ist das zu strikt. Updates sind die wichtigste einzelne Sicherheitsaufgabe auf einer WordPress Seite, und sie schwerer zu machen führt in der Praxis dazu, dass Leute sie ausfallen lassen. DISALLOW_FILE_MODS ergibt in zwei spezifischen Umgebungen Sinn: Deploy Pipelines, in denen die Produktionsinstallation read only sein soll, und Hochsicherheits Setups, in denen wirklich jemand dafür zuständig ist, Updates von außen einzuspielen. Für alles andere trifft das schlichte DISALLOW_FILE_EDIT den Sweet Spot aus "großer Sicherheitsgewinn, kein operativer Schmerz".

Was ändert sich nach dem Setzen für die Benutzer?

Für 99% der Admins auf 99% der Seiten: nichts Sichtbares. Die zwei Menüeinträge sind aus dem Dashboard verschwunden. Niemandem fällt es auf, weil niemand sie benutzt hat.

Die Fälle, in denen es jemandem auffällt:

• Ein Entwickler, der direkt in Produktion editiert. Wenn jemand im Team gewohnheitsmäßig Theme oder Plugin Dateien über den Browser bearbeitet, muss diese Person auf SFTP oder eine Deploy Pipeline umsteigen. Das ist eine Workflow Änderung, kein Blocker. Wenn überhaupt, ist das ein guter Anlass, mal zu hinterfragen, warum überhaupt Produktionscode live editiert wird.
• Plugins, die sich in den Editor einklinken. Eine Handvoll Plugins erweitern den eingebauten Editor um zusätzliche Features. Deren UI lädt einfach nicht mehr, wenn der Editor weg ist. Das Plugin selbst funktioniert in der Regel weiter, nur die Editor Integration bricht. Falls du auf so eines angewiesen bist, fällt es beim Testen auf.
• Custom Code, der die Capabilities edit_themes oder edit_plugins nutzt. Die Konstante zieht diese Capabilities jeder Rolle ab, auch dem Administrator. Code, der Features genau an diesen Capabilities festmacht, verhält sich so, als hätte sie niemand. Selten, aber gut zu wissen, wenn du ein eigenes Plugin pflegst, das solche Capability Checks nutzt.

Prüfen, ob es aktiv ist

1. Als Administrator in WordPress einloggen.
2. Das Menü Design in der Admin Sidebar öffnen. Der Eintrag "Theme Datei Editor" sollte fehlen.
3. Das Menü Plugins öffnen. Der Eintrag "Plugin Datei Editor" sollte fehlen.
4. Zur Sicherheit direkt https://deinedomain.de/wp-admin/theme-editor.php aufrufen. WordPress sollte auf eine Seite weiterleiten, die "Du verfügst nicht über ausreichende Rechte, um Theme Dateien zu bearbeiten" anzeigt.
5. Einen frischen InspectWP Scan starten. Der Check "Datei Editor aktiv" im Sicherheits Bereich sollte auf grün wechseln.

Wenn die Menüeinträge nach dem Speichern der wp-config.php trotzdem noch da sind, sind das die häufigsten Ursachen: Object Cache (leeren), Opcode Cache wie OPcache (kann einen Moment brauchen, um die neue Datei zu erfassen, oder PHP FPM neu starten), die Bearbeitung ist in einer falschen wp-config.php in einem übergeordneten Verzeichnis gelandet, oder die Konstante wird weiter unten in der Datei von etwas anderem überschrieben. Öffne die wp-config.php ganz von oben und such nach DISALLOW_FILE_EDIT; deine Zeile sollte da sein und nichts anderes danach sie nochmal setzen.

Was dieser Fix kann und was nicht

Es lohnt sich, klar zu sagen, welche Art von Angriff DISALLOW_FILE_EDIT verhindert und welche nicht. Er stoppt den spezifischen Pfad, in dem ein Angreifer mit geklautem Admin Login PHP per Browser in Theme oder Plugin Dateien schreibt. Er stoppt nicht:

• Einen Angreifer, der ein bösartiges Plugin oder Theme Zip aus dem Admin hochlädt (dafür DISALLOW_FILE_MODS nutzen, mit den oben beschriebenen Trade Offs, oder Capabilities für Plugin Uploads einschränken).
• Einen Angreifer, der eine Code Schwachstelle in einem Plugin ausnutzt, um Dateien zu schreiben. Dafür muss das Plugin selbst gepatcht sein.
• Einen Angreifer, der SFTP oder Shell Zugriff hat. An dem Punkt ist die WordPress Schicht ohnehin umgangen.

DISALLOW_FILE_EDIT ist eine Verteidigungsschicht, keine vollständige Strategie. Sie ergänzt sich naturgemäß mit starken Admin Passwörtern, Zwei Faktor Authentifizierung für Admin Accounts und einem Security Plugin, das auf unerwartete Datei Änderungen achtet. Die Kombination nimmt den einfachsten Takeover Pfad vom Tisch und macht die schwierigeren laut genug, dass sie auffallen.

Eine Zeile in der wp-config.php, kein Plugin, keine Wartung, keine Kompatibilitäts Sorgen. Wenn du diesen Monat sonst nichts an einer WordPress Seite anfasst: das hier.